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
2013/8/12 Victor Stinner victor.stin...@gmail.com:
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
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
2013/8/6 Victor Stinner victor.stin...@gmail.com:
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
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
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
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
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:
On Thu, Mar 22, 2012 at 00:39, Huan Do dob...@gmail.com 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,
*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
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
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
@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
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
On Thu, Mar 22, 2012 at 10:28 AM, Huan Do dob...@gmail.com 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
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
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
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
On Fri, Jan 9, 2009 at 09:50, Benjamin Peterson benja...@python.org 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
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 on 64-bit
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
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 should
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 going to
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,
make
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
me
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 interpretation
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
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
extension
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
[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
never
[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 lose
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 is
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 approach:
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
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
Created:
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 casts
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, yes.
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
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
+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 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
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 stems
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_MAX
[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_CLEAN
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
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.
---
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 convinced that
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/)
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?
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 provide a
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, because
[Aahz]
Go ahead and make PEP 6 a Process PEP.
Done!
--
David Goodger http://python.net/~goodger
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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,
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 a
54 matches
Mail list logo
