Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

2013/8/12 Victor Stinner : > I fixed various bugs in the implementation of the (new) PEP 446: > http://hg.python.org/features/pep-446 > > At revision da685bd67524, the full test suite pass on: (...) I also checked the usage of atomic flags. There was a minor bug on Linux, it is now fixed (remove a

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

Hi, I fixed various bugs in the implementation of the (new) PEP 446: http://hg.python.org/features/pep-446 At revision da685bd67524, the full test suite pass on: - Fedora 18 (Linux 3.9), x86_64 - FreeBSD 9.1, x86_64 - Windows 7 SP1, x86_64 - OpenIndiana (close to Solaris 11), x86_64 Some tests

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

> Also the socket library creates sockets with inheritable handles by default. Apparently there isn't a reliable way to make sockets non-inheritable because anti-virus/firewall software can interfere: > > http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable Re

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

2013/8/6 Victor Stinner : > Oh, the summary table is wrong for the "subprocess, default" line: all > inheritable handles are inherited if at least one standard stream is > replaced. I updated the PEP: - add a new section "Performances of Closing All File Descriptors" - mention a previous attempt

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

> On Windows, the ``subprocess`` closes all handles and file descriptors > in the child process by default. If at least one standard stream (stdin, > stdout or stderr) is replaced (ex: redirected into a pipe), all > inheritable handles are inherited in the child process. > > Summary: > > ==

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

On 06/08/2013 1:23am, Victor Stinner wrote: Each operating system handles the inheritance of file descriptors differently. Windows creates non-inheritable file descriptors by default, whereas UNIX creates inheritable file descriptors by default. The Windows API creates non-inheritable *handles*

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

On 06/08/2013 1:23am, Victor Stinner wrote: Each operating system handles the inheritance of file descriptors differently. Windows creates non-inheritable file descriptors by default, whereas UNIX creates inheritable file descriptors by default. The Windows API creates non-inheritable *handles*

[Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

Hi, My second try (old PEP 446) to change how the inheritance of file descriptors was somehow rejected. Here is a third try (new PEP 446) which should include all information of the recent discussions on python-dev, especially how file descriptors and handles are inherited on Windows. I added tab

Re: [Python-Dev] New PEP

On Thu, Mar 22, 2012 at 00:39, Huan Do wrote: > Tell me what you guys think. I don't really want to add more things to the language, so I hate to say this: It makes sense to me. However, the syntax is very close to the syntax for function annotations. But that's when defining, and this is when

Re: [Python-Dev] New PEP

On Thu, Mar 22, 2012 at 10:28 AM, Huan Do wrote: > I was not completely familiar with itertools but itertools.islice() seems to > have the functionality that I propose. It is great that  there already exist > a solution that does not change python's syntax. Unless anyone wants to > pursue this pro

Re: [Python-Dev] New PEP

Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterat

Re: [Python-Dev] New PEP

@Ethan Furman each call to x(:) would return a different iterator, so both sides will have their own information about where they are. Also it is the case that checking for equality of generators does not make the generators to expand out, so checking for equality becomes to checking if they are t

Re: [Python-Dev] New PEP

> My proposed syntax is x(:) Change the Python syntax is not a good start. You can already experiment your idea using the slice() type. > We would have to do something like this. > sum(x[:-20:2]) Do you know the itertools module? It looks like itertools.islice(). Victor

Re: [Python-Dev] New PEP

On 03/21/2012 07:39 PM, Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers

[Python-Dev] New PEP

*Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterate over a slice of x,

Re: [Python-Dev] New PEP numbering scheme

On Mar 12, 2012, at 07:33 PM, Brett Cannon wrote: >It came up at the sprints about how to choose new PEP numbers. It was >agreed that the newest, *lowest* number should be used (e.g. 418) and not >the next highest number (e.g. 3156). I have already updated PEP 1 to >reflect this. +1 -Barry _

[Python-Dev] New PEP numbering scheme

It came up at the sprints about how to choose new PEP numbers. It was agreed that the newest, *lowest* number should be used (e.g. 418) and not the next highest number (e.g. 3156). I have already updated PEP 1 to reflect this. ___ Python-Dev mailing list

Re: [Python-Dev] new pep index

On Fri, Jan 9, 2009 at 09:50, Benjamin Peterson wrote: > This is just a note that the PEP index (PEP 0) is now automatically > generated, so you need not bother to update any more. Thanks for getting this done! -Brett ___ Python-Dev mailing list Python

[Python-Dev] new pep index

This is just a note that the PEP index (PEP 0) is now automatically generated, so you need not bother to update any more. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscri

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Neal Norwitz wrote: > Other ideas? We could rename essential function symbols, like PyInitModule4 (to, say, PyInitModule4b). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Neal Norwitz wrote: > On 1/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> We'd also have to make sure that old extensions don't >> just import with a warning, since the change will introduce >> buffer overflows and seg faults in extensions that are not >> aware of the change. > > I agree that

Re: [Python-Dev] New PEP: Using ssize_t as the index type

On 1/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > We'd also have to make sure that old extensions don't > just import with a warning, since the change will introduce > buffer overflows and seg faults in extensions that are not > aware of the change. I agree that on 64-bit platforms we shoul

Re: [Python-Dev] New PEP: Using ssize_t as the index type

M.-A. Lemburg wrote: >>Sure. However, most users will compile it on 32-bit >>systems. If they find they cannot get it to work on >>a 64-bit system, they should ask the author for help, >>or just use it in 32-bit mode (as 64-bit mode won't >>gain them anything, anyway). > > > I wonder how you are

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> If it were this easy, I wouldn't have objections. But it's >> not. > > It is so easy. Can you should me an example where it isn't? > >> The variables you use with these APIs tend to propagate >> through the extension, you use them in other calls, >

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Tim Peters wrote: > This reminded me that I still owe you a reply about s# and t# format > codes. It occurred to me that I've never used them, and probably > never will, so I really don't care how they work: I'm only really > worried about widespread ugliness, meaning wide enough that it touches

Re: [Python-Dev] New PEP: Using ssize_t as the index type

[Martin v. Löwis] > ... > I am talking about the entirety of these functions, > and claim that they are rarely used (including the > Unicode and buffer APIs). This reminded me that I still owe you a reply about s# and t# format codes. It occurred to me that I've never used them, and probably neve

Re: [Python-Dev] New PEP: Using ssize_t as the index type

M.-A. Lemburg wrote: > If it were this easy, I wouldn't have objections. But it's > not. It is so easy. Can you should me an example where it isn't? > The variables you use with these APIs tend to propagate > through the extension, you use them in other calls, > make assignments, etc. They only

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> I don't see a good solution for these other than introducing >> a set of new APIs (and maybe doing some macro magic as Martin >> did for PyArg_ParseTuple()). Due to the fact that changes in >> the types of output parameters require changes in the >>

Re: [Python-Dev] New PEP: Using ssize_t as the index type

M.-A. Lemburg wrote: > I don't see a good solution for these other than introducing > a set of new APIs (and maybe doing some macro magic as Martin > did for PyArg_ParseTuple()). Due to the fact that changes in > the types of output parameters require changes in the > extension variable type layout

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > Armin Rigo wrote: >> This would do the right thing for <= 2.4, using ints everywhere; and the >> Python.h version 2.5 would detect the #define and assume it's a >> 2.5-compatible module, so it would override the #define with the real >> thing *and* turn on the ssize_t inter

Re: [Python-Dev] New PEP: Using ssize_t as the index type

On 1/6/06, Michael Urman <[EMAIL PROTECTED]> wrote: > > I put together a non-parsing checker last month to help me feel more > secure after http://python.org/sf/1365916. It's awful code, but the > simple things are easy to change or extend. Fixing the false positives > and other misinterpretations

Re: [Python-Dev] New PEP: Using ssize_t as the index type

[I just noticed that I sent this mail to just Martin when I meant it for the list. Sorry Martin!] On 1/5/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > More precisely, the printf style of function calling, and varargs > functions. ISO C is pretty type safe, but with varargs functions, > you lo

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Armin Rigo wrote: > This would do the right thing for <= 2.4, using ints everywhere; and the > Python.h version 2.5 would detect the #define and assume it's a > 2.5-compatible module, so it would override the #define with the real > thing *and* turn on the ssize_t interpretation of the '#' format >

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Hi Martin, On Fri, Dec 30, 2005 at 11:26:44AM +0100, "Martin v. L?wis" wrote: > > Hum. It would be much cleaner to introduce a new format character to > > replace '#' and deprecate '#'... > > That would certainly be clearer. What character would you suggest? > > I see two drawbacks with that ap

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Tim Peters wrote: > Better to use a new gibberish character and deprecate the old one? > Otherwise I'm afraid we'll be stuck supporting PY_SIZE_T_CLEAN > forever, and it's not good to have the meaning of a format string > depend on the presence or absence of a #define far away in the file. See my

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Armin Rigo wrote: > I guess you mean LONG_MAX instead of MAX_INT, in the event that ssize_t > is larger than a long. Right, changed. > Also, distinguishing between PyInt_AsSsize_t() > and PyLong_AsSsize_t() doesn't seem to be useful (a quick look in your > branch makes me guess that they both acc

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Travis E. Oliphant wrote: > Sounds wonderful. Would love to see this in Python 2.5. This will fix > important 64-bit issues. Perhaps someone could explain to me what the > difference between Py_ssize_t and Py_intptr_t would be? Is this not a > satisfactory Py_ssize_t already? Practically, y

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Fredrik Lundh wrote: > well, one thing seems to missing from your PEP: in several modules, you've > changed the cast used in the type table. e.g. ... > is this change backwards compatible ? See the section "Conversion guidelines". I prefer the approach taken in the patch below, i.e. remove the cas

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > Please let me know what you think. > > Regards, > Martin > > PEP: XXX > Title: Using ssize_t as the index type > Version: $Revision$ > Last-Modified: $Date$ > Author: Martin v. Löwis <[EMAIL PROTECTED]> > Status: Draft > Type: Standards Track > Content-Type: text/x-rst >

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > Please let me know what you think. +1. in honor of the Bike Shed Effect, I'm going to assume that you've thought of everything. ::: well, one thing seems to missing from your PEP: in several modules, you've changed the cast used in the type table. e.g. --- python/bran

Re: [Python-Dev] New PEP: Using ssize_t as the index type

On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Please let me know what you think. > > Regards, > Martin > > PEP: XXX > Title: Using ssize_t as the index type [SNIP] +1 from me. As everyone else is saying, this has to happen at some point and 2.5 is as good as any. -Brett ___

Re: [Python-Dev] New PEP: Using ssize_t as the index type

[Martin v. Löwis] ... > PEP: XXX > Title: Using ssize_t as the index type +1, and for Python 2.5, and the sooner done the less painful for all. Same concerns as Armin, where this is especially unattractive: > The conversion codes 's#' and 't#' will output Py_ssize_t > if the macro PY_SIZE_T_CLEA

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Hi Martin, On Thu, Dec 29, 2005 at 03:04:30PM +0100, "Martin v. L?wis" wrote: > New conversion functions PyInt_FromSsize_t, PyInt_AsSsize_t, > PyLong_AsSsize_t are introduced. PyInt_FromSsize_t will transparently > return a long int object if the value exceeds the MAX_INT. I guess you mean LONG_M

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Aahz wrote: > However, I think this PEP should be held up as an example of how to write > a good PEP. Aside from my inability to follow some of the arcane points > due to lack of C programming skill, this PEP was extremely readable and > well-organized. Nice job! Thanks! Part of it probably stem

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Not sure what I think of the proposal (though I guess I'm overall +0 -- needs to be done sometime and no time like the present). However, I think this PEP should be held up as an example of how to write a good PEP. Aside from my inability to follow some of the arcane points due to lack of C progr

Re: [Python-Dev] New PEP: Using ssize_t as the index type

+1. I think this is long overdue. While I can't judge the amount of code breakage, 2.5 is as good an opportunity as any. --Guido On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Please let me know what you think. > > Regards, > Martin > > PEP: XXX > Title: Using ssize_t as the index ty

[Python-Dev] New PEP: Using ssize_t as the index type

Please let me know what you think. Regards, Martin PEP: XXX Title: Using ssize_t as the index type Version: $Revision$ Last-Modified: $Date$ Author: Martin v. Löwis <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 18-Dec-2005 Post-History: Abstract =

Re: [Python-Dev] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)

On 10/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I'm starting to think we want to let PEP 342 bake for at least one release > cycle before deciding what (if any) additional behaviour should be added to > generators. Yes please! -- --Guido van Rossum (home page: http://www.python.org/~guido/

Re: [Python-Dev] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)

Greg Ewing wrote: > Nick Coghlan wrote: > > >>Sometimes I miss the obvious. There's a *much*, *much* better place to store >>the return value of a generator than on the StopIteration exception that it >>raises when it finishes. Just save the return value in the *generator*. > > > I'm not conv

Re: [Python-Dev] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)

Nick Coghlan wrote: > Sometimes I miss the obvious. There's a *much*, *much* better place to store > the return value of a generator than on the StopIteration exception that it > raises when it finishes. Just save the return value in the *generator*. I'm not convinced that this is better, becau

Re: [Python-Dev] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)

On 10/9/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Sometimes I miss the obvious. There's a *much*, *much* better place to store > the return value of a generator than on the StopIteration exception that it > raises when it finishes. Just save the return value in the *generator*. > > And then pro

[Python-Dev] New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods)

Nick Coghlan wrote: > Although, if StopIteration.result was a read-only property with the above > definition, wouldn't that give us the benefit of "one obvious way" to return > a > value from a coroutine without imposing any runtime cost on normal use of > StopIteration to finish an iterator?

Re: [Python-Dev] new PEP type: Process

[Aahz] > Go ahead and make PEP 6 a Process PEP. Done! -- David Goodger signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] new PEP type: Process

On Fri, Aug 12, 2005, David Goodger wrote: > > Barry Warsaw and I, the PEP editors, have been discussing the > need for a new PEP type lately. Martin von L?wis' PEP 347 was > a prime example of a PEP that didn't fit into the existing > Standards Track and Informational categories. We agreed upon

[Python-Dev] new PEP type: Process

Barry Warsaw and I, the PEP editors, have been discussing the need for a new PEP type lately. Martin von Löwis' PEP 347 was a prime example of a PEP that didn't fit into the existing Standards Track and Informational categories. We agreed upon a new "Process" PEP type. For more information, plea