Re: [Python-Dev] PEP 3151 accepted
2011/10/12 Antoine Pitrou : > On Tue, 11 Oct 2011 18:22:43 -0400 > Barry Warsaw wrote: >> As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3. >> >> Congratulations to Antoine for producing a great PEP that has broad >> acceptance >> in the Python development community, with buy-in from all the major >> implementations of Python. Antoine's branch is ready to go and it should now >> be merged into the default branch. >> >> PEP 3151 will bring some much needed sanity to this part of the standard >> exception hierarchy, and I for one look forward to being able to write code >> directly using it, one day finally eliminating most of my `import errno`s! > > Thanks Barry! > I expect to merge the PEP 3151 into default soon (it's basically ready). > > cheers > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > Thank you for having worked on this, it was a pretty huge amount of work. We'll probabily have to wait a long time before seeing libs/apps freely depending on this change without caring about backward compatibility constraints, but with this Python is a better language now. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation strategy for PEP 3151
Hello, I'd like some advice on what the best path is in cases such as: A :exc:`socket.error` is raised for errors from the call to :func:`inet_ntop`. Should I replace "socket.error" with "OSError" (knowing that the former is now an alias of the latter), or leave "socket.error" so that people have less surprises when running their code with a previous Python version? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation strategy for PEP 3151
2011/10/12 Antoine Pitrou : > > Hello, > > I'd like some advice on what the best path is in cases such as: > > A :exc:`socket.error` is raised for errors from the call > to :func:`inet_ntop`. > > Should I replace "socket.error" with "OSError" (knowing that the > former is now an alias of the latter), or leave "socket.error" so that > people have less surprises when running their code with a previous > Python version? I think you should say OSError but leave a historical note with a versionchanged on it. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation strategy for PEP 3151
On Wed, Oct 12, 2011 at 09:17, Antoine Pitrou wrote: > > Hello, > > I'd like some advice on what the best path is in cases such as: > > A :exc:`socket.error` is raised for errors from the call > to :func:`inet_ntop`. > > Should I replace "socket.error" with "OSError" (knowing that the > former is now an alias of the latter), or leave "socket.error" so that > people have less surprises when running their code with a previous > Python version? I would expect the 3.3 documentation shows the best way to write 3.3 code, so I'd prefer to see OSError there. A good "What's New" entry as well as explanation/example of how the hierarchy has changed in library/exceptions.rst should cover anyone questioning the departure from socket.error. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation strategy for PEP 3151
On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote: >2011/10/12 Antoine Pitrou : >> I'd like some advice on what the best path is in cases such as: >> >> A :exc:`socket.error` is raised for errors from the call >> to :func:`inet_ntop`. >> >> Should I replace "socket.error" with "OSError" (knowing that the >> former is now an alias of the latter), or leave "socket.error" so that >> people have less surprises when running their code with a previous >> Python version? > >I think you should say OSError but leave a historical note with a >versionchanged on it. +1 -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3151 accepted
Le 12/10/2011 00:22, Barry Warsaw a écrit : > As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3. Congratulations Antoine, and thanks! Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
Le 11/10/2011 09:59, Vinay Sajip a écrit : > To me it does, and it would be useful to have some validation from > the packaging folks. I’m trying to catch up, but the wi-fi here is horrible and there are so many messages! I’ll compose a reply for tomorrow. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native
Le mercredi 12 octobre 2011 21:07:33, charles-francois.natali a écrit : > changeset: 72897:ee4fe16d9b48 > branch: 2.7 > parent: 69635:f6feed6ec3f9 > user:Charles-François Natali > date:Wed Oct 12 21:07:54 2011 +0200 > summary: > Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for > native TLS implementations, and fails with the ad-hoc TLS implementation > when a thread doesn't have an auto thread state (e.g. a thread created > outside of Python calling into a subinterpreter). > > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -61,10 +61,6 @@ > Library > --- > > -- Issue #10517: After fork(), reinitialize the TLS used by the > PyGILState_* - APIs, to avoid a crash with the pthread implementation in > RHEL 5. Patch - by Charles-François Natali. You should restore this NEWS entry and add a new one to say that the patch has been reverted. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation strategy for PEP 3151
On 10/12/2011 10:58 AM, Barry Warsaw wrote: On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote: 2011/10/12 Antoine Pitrou: I'd like some advice on what the best path is in cases such as: A :exc:`socket.error` is raised for errors from the call to :func:`inet_ntop`. Should I replace "socket.error" with "OSError" (knowing that the former is now an alias of the latter), or leave "socket.error" so that people have less surprises when running their code with a previous Python version? I think you should say OSError but leave a historical note with a versionchanged on it. +1 Given that tracebacks for uncaught socket errors will end with OSError, the doc should say that is what is raised. The edits and notes I have seen so far today look fine. I also liked the What's New example. The new version looks *much* better, and not just because of the deleted import, but because the changes allow a much clearer structure that is more pleasant to read. So my thanks also for carrying out this project. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Identifier API
Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :
> In benchmarking PEP 393, I noticed that many UTF-8 decode
> calls originate from C code with static strings, in particular
> PyObject_CallMethod. Many of such calls already have been optimized
> to cache a string object, however, PyObject_CallMethod remains
> unoptimized since it requires a char*.
Because all identifiers are ASCII (in the C code base), another idea is to use
a structure similar to PyASCIIObject but with an additional pointer to the
constant char* string:
typedef struct {
PyASCIIObject _base;
const char *ascii;
} PyConstASCIIObject;
Characters don't have to be copied, just the pointer, but you still have to
allocate a structure. Because the size of the structure is also constant, we
can have an efficient free list. Pseudo-code to create such object:
PyObject*
create_const_ascii(const char *str)
{
PyConstASCIIObject *obj;
/* ensure maybe that str is ASCII only? */
obj = get_from_freelist(); # reset the object (e.g. hash)
if (!obj) {
obj = allocate_new_const_ascii();
if (!obj) return NULL;
}
obj->ascii = str;
return obj;
}
Except PyUnicode_DATA, such structure should be fully compatible with other
PEP 383 structures.
We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string. Later
we can add new functions like _PyDict_GetASCII().
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrchr
On Thu, 13 Oct 2011 01:17:29 +0200 victor.stinner wrote: > http://hg.python.org/cpython/rev/e5bd48b43a58 > changeset: 72903:e5bd48b43a58 > user:Victor Stinner > date:Thu Oct 13 00:18:12 2011 +0200 > summary: > Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrchr Can't we simply reuse the stringlib here? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Mark PEP accepted.
Isn't now final? 2011/10/12 antoine.pitrou : > http://hg.python.org/peps/rev/f50f0e14c774 > changeset: 3962:f50f0e14c774 > parent: 3959:2e1f0462a847 > user: Antoine Pitrou > date: Thu Oct 13 02:01:21 2011 +0200 > summary: > Mark PEP accepted. > > files: > pep-3151.txt | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) > > > diff --git a/pep-3151.txt b/pep-3151.txt > --- a/pep-3151.txt > +++ b/pep-3151.txt > @@ -3,13 +3,12 @@ > Version: $Revision$ > Last-Modified: $Date$ > Author: Antoine Pitrou > -Status: Draft > +Status: Accepted > Type: Standards Track > Content-Type: text/x-rst > Created: 2010-07-21 > Python-Version: 3.3 > Post-History: > -Resolution: TBD > > > Abstract > @@ -507,9 +506,10 @@ > Implementation > == > > -A reference implementation is available in > -http://hg.python.org/features/pep-3151/ in branch ``pep-3151``. It is > -also tracked on the bug tracker at http://bugs.python.org/issue12555. > +The reference implementation has been integrated into Python 3.3. > +It was formerly developed in http://hg.python.org/features/pep-3151/ in > +branch ``pep-3151``, and also tracked on the bug tracker at > +http://bugs.python.org/issue12555. > It has been successfully tested on a variety of systems: Linux, Windows, > OpenIndiana and FreeBSD buildbots. > > > -- > Repository URL: http://hg.python.org/peps > > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > > -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrchr
Le jeudi 13 octobre 2011 01:27:32, Antoine Pitrou a écrit : > On Thu, 13 Oct 2011 01:17:29 +0200 > > victor.stinner wrote: > > http://hg.python.org/cpython/rev/e5bd48b43a58 > > changeset: 72903:e5bd48b43a58 > > user:Victor Stinner > > date:Thu Oct 13 00:18:12 2011 +0200 > > > > summary: > > Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrchr > > Can't we simply reuse the stringlib here? Hum, maybe, but not easily: functions have different prototypes and manipulate different types. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Identifier API
Le jeudi 13 octobre 2011 00:44:33, Victor Stinner a écrit : > Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit : > > In benchmarking PEP 393, I noticed that many UTF-8 decode > > calls originate from C code with static strings, in particular > > PyObject_CallMethod. Many of such calls already have been optimized > > to cache a string object, however, PyObject_CallMethod remains > > unoptimized since it requires a char*. > > Because all identifiers are ASCII (in the C code base), another idea is to > use a structure similar to PyASCIIObject but with an additional pointer to > the constant char* string: Oh, I realized that Martin did already commit its PyIdentifier API, it's maybe too late :-) > We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string. > Later we can add new functions like _PyDict_GetASCII(). The main difference between my new "const ASCII" string idea and PyIdentifier is the lifetime of objects. Using "const ASCII" strings, the strings are destroyed quickly (to not waste memory), whereas PyIdentifiers are intern strings and so they are only destroyed at Python exit. I don't know if "const ASCII" strings solve a real issue. I implemented my idea. I will do some benchmarks to check if it's useful or not :-) Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
