Re: [Python-Dev] python optimization
[Neal Becker] > >>I don't know to what extent these kind of optimizations are available to > >>cpython. For example, are constant calculations removed from loops? [Brett Cannon] > > If you mean ``2+3``, then yes. [Greg Ewing] > Actually, no. Constant folding *could* be done, but it currently isn't: > > >>> def f(): > ... return 2+3 > ... > >>> import dis > >>> dis.dis(f) >2 0 LOAD_CONST 1 (2) >3 LOAD_CONST 2 (3) >6 BINARY_ADD >7 RETURN_VALUE >8 LOAD_CONST 0 (None) > 11 RETURN_VALUE That looks like a disassembly from the ancient and primitive Py2.3 ;-) It looks a little different in the ahead-of-its-time Py2.5 alpha: Python 2.5a0 (#46, Sep 15 2005, 00:51:34) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> def f(): return 2+3 >>> import dis >>> dis.dis(f) 2 0 LOAD_CONST 3 (5) 3 RETURN_VALUE Raymond ___ 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 optimization
Brett Cannon wrote: >>I don't know to what extent these kind of optimizations are available to >>cpython. For example, are constant calculations removed from loops? > > If you mean ``2+3``, then yes. Actually, no. Constant folding *could* be done, but it currently isn't: >>> def f(): ... return 2+3 ... >>> import dis >>> dis.dis(f) 2 0 LOAD_CONST 1 (2) 3 LOAD_CONST 2 (3) 6 BINARY_ADD 7 RETURN_VALUE 8 LOAD_CONST 0 (None) 11 RETURN_VALUE >>> -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] os.path.diff(path1, path2)
Trent Mick wrote: > If this *does* get added (I'm +0) then let's call it "relpath" or > "relpathto" as in the various implementations out there: +1 on that, too. Preferably just "relpath". -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] IMPORTANT: 2.4.2c1 Wednesday, 21st September - branch will be closed for a week.
On 9/15/05, Anthony Baxter <[EMAIL PROTECTED]> wrote: > So we'll be cutting the 2.4.2 release candidate on Wednesday the 21st > (next week). Can people please make sure they are running the test > suite fully for any checkins between now and then? Also, please > consider the release24-maint branch closed from UTC/GMT on the > 21st - this will remain closed for all but critical brown-paper-bag > bugs for a week, until we (hopefully) cut 2.4.2 final on the 28th. Has anyone run valgrind on either 2.4.x or 2.5 recently? I have not, but I'll try to if no one else has run it. n ___ 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] IMPORTANT: 2.4.2c1 Wednesday, 21st September - branch will be closed for a week.
So we'll be cutting the 2.4.2 release candidate on Wednesday the 21st (next week). Can people please make sure they are running the test suite fully for any checkins between now and then? Also, please consider the release24-maint branch closed from UTC/GMT on the 21st - this will remain closed for all but critical brown-paper-bag bugs for a week, until we (hopefully) cut 2.4.2 final on the 28th. I'll send a reminder email about 12 hours out from the branch close. Anthony ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
Hi Neal, Ray, Neal wrote: > The binary versions (.pyc and .pyo) are not compatible, their magic > number is different. I don't know the details, but if you want to > investigate yourself. Get a CVS version, cd python/dist/src ; cvs > diff -r r23 -r r24 Python/import.c > > That shows the magic number changing. You will need to read CVS logs > to figure out why. It's possible the numbers don't really *need* to > change. I see two comments in the logs are: > > * Bump the magic number to avoid sharing bytecode between 2.3 and 2.4. > Revise the long comment that explained details of the magic number > in gory detail. > > * With Guido's okay, bumped up the magic number so that this patch gets > widely exercised before the alpha goes out. > > There are other patches which may have bumped the magic number for > other reasons. Thanks! >>Can somebody point me at this information please? > And I forgot to give you this link: > http://docs.python.org/whatsnew/whatsnew24.html That lists the changes. It's not clear (at least to me) whether these changes are incompatible. > BTW, this list probably isn't the best place to post this question. > comp.lang.python (python-list@python.org) is generally preferred for > details about implementation. Understood. I'll try there tomorrow. > If you are really interested in finding out more about Python, perhaps > you can come to the BayPIGGIES (Python Users Group) meeting at Google > tonight (7.30pm) in Mt. View. Contact me off-list if you want more > info. Thanks for the pointer. Unfortunately I have other plans for tonight. Raymond wrote: > The new LIST_APPEND opcode won't run on Py2.3. It was more a case of wondering whether Python 2.3.x .py, .pyo, .pyc files should "just work" with the Python 2.4.x run-time environment. We are not too concerned with 2.4.x files working with the Python 2.3.x runtime. This sort of binary incompatibly is common. ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
At 05:44 PM 9/15/2005 -0400, Raymond Hettinger wrote: >[Neal Norwitz] > > That shows the magic number changing. You will need to read CVS logs > > to figure out why. It's possible the numbers don't really *need* to > > change. > >The new LIST_APPEND opcode won't run on Py2.3. The OP asked about upgrading existing 2.3 .pyc/.pyo files to 2.4, not downgrading to 2.3, so this doesn't affect them, except insofar as it means the magic number is different. ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
[Neal Norwitz] > That shows the magic number changing. You will need to read CVS logs > to figure out why. It's possible the numbers don't really *need* to > change. The new LIST_APPEND opcode won't run on Py2.3. Raymond ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
(oops. trying again) Rich Burridge wrote: > I'm involved with the team that's working towards installing Python 2.4.x > as part of a future release of the Solaris O/S. > > We currently have Python 2.3.x installed. We are trying to determine just > how compatible these two release are (at both the binary and source levels). > > In other words, with Python 2.3.x .py, .pyc and .pyo files work correctly > with Python 2.4.x ? short answer: no longer answer: most PY files work. the exception is code that (accidentally or intentionally) depends on implementation artifacts, undocumented behaviour or bugs (see the changes documents for things that may affect your applications). PYC and PYO files contain bytecode, and are not guaranteed to be portable between different 2.X releases. to check the bytecode revision used by a given Python interpreter, you can use imp.get_magic(): Python 2.3.5 >>> import imp >>> imp.get_magic() ';\xf2\r\n' Python 2.4.1 >>> import imp >>> imp.get_magic() 'm\xf2\r\n' ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
On 9/15/05, Rich Burridge <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm involved with the team that's working towards installing Python 2.4.x > as part of a future release of the Solaris O/S. Cool. I would like to hear more about what you are doing. > We currently have Python 2.3.x installed. We are trying to determine just > how compatible these two release are (at both the binary and source levels). > > In other words, with Python 2.3.x .py, .pyc and .pyo files work correctly > with Python 2.4.x ? The binary versions (.pyc and .pyo) are not compatible, their magic number is different. I don't know the details, but if you want to investigate yourself. Get a CVS version, cd python/dist/src ; cvs diff -r r23 -r r24 Python/import.c That shows the magic number changing. You will need to read CVS logs to figure out why. It's possible the numbers don't really *need* to change. I see two comments in the logs are: * Bump the magic number to avoid sharing bytecode between 2.3 and 2.4. Revise the long comment that explained details of the magic number in gory detail. * With Guido's okay, bumped up the magic number so that this patch gets widely exercised before the alpha goes out. There are other patches which may have bumped the magic number for other reasons. > Can somebody point me at this information please? BTW, this list probably isn't the best place to post this question. comp.lang.python (python-list@python.org) is generally preferred for details about implementation. If you are really interested in finding out more about Python, perhaps you can come to the BayPIGGIES (Python Users Group) meeting at Google tonight (7.30pm) in Mt. View. Contact me off-list if you want more info. HTH, n ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
Rich Burridge wrote: > I'm involved with the team that's working towards installing Python 2.4.x > as part of a future release of the Solaris O/S. > > We currently have Python 2.3.x installed. We are trying to determine just > how compatible these two release are (at both the binary and source levels). > > In other words, with Python 2.3.x .py, .pyc and .pyo files work correctly > with Python 2.4.x ? no. most PY files may work (see the changes documents for things that have changed ___ 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] Compatibility between Python 2.3.x and Python 2.4.x
Hi, I'm involved with the team that's working towards installing Python 2.4.x as part of a future release of the Solaris O/S. We currently have Python 2.3.x installed. We are trying to determine just how compatible these two release are (at both the binary and source levels). In other words, with Python 2.3.x .py, .pyc and .pyo files work correctly with Python 2.4.x ? Can somebody point me at this information please? Thanks. -- Rich Burridge Email: [EMAIL PROTECTED] Sun Microsystems Inc. (MPK14-260), Phone: +1.650.786.5188 4150 Network Circle,AIM/YAHOO: RicBurridge Santa Clara, CA 95054 Blog: http://blogs.sun.com/richb ___ 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 optimization
On 9/15/05, Neal Becker <[EMAIL PROTECTED]> wrote: > I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is > highly readable, making the assumption that the compiler will do good > things to optimize the code despite the style in which it's written. For > example, I assume constants are removed from loops. In general, an entity > is defined as close to the point of usage as possible. > > I don't know to what extent these kind of optimizations are available to > cpython. For example, are constant calculations removed from loops? If you mean ``2+3``, then yes. If you mean ``2 + a`` where is a loop invariant, then no. > How > about functions? No optimization there. > Is there a significant cost to putting a function def > inside a loop rather than outside? > If you put it in a loop then the function must be reconstructed every time through the loop. I have never benchmarked the cost of function construction but I doubt it's cheap. The problem with all of these optimizations that you can do in more static languages is you get to assume most things do not change from underneath you. In Python, thanks to threading, access to frames, global namespaces of modules, etc., most things cannot be naively optimized without a lot of checking up front to make sure the optimization is valid every time it is run. If you want some gruesome detail, you can read my thesis (http://www.drifty.org/thesis.pdf) and the section on problems with introducing type inference into Python. -Brett ___ 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 optimization
Hi Neal, I don't believe that cpython currently does any of the optimizations you refer to below. That said, it is very reasonable to adopt "a style of coding that is highly readable, making the assumption that the compiler will do good things" when coding in Python. Python is one of the most highly optimised languages in the world along the Programmer Productivity metric. Line for line, you can pack more readable, obvious, and maintainable meaning into Python than pretty much any other language. The upshot is that then you can profile the final running code and see if it really matters that the compiler is using an extra .034 microseconds. That's my $0.028 US (damn inflation!) On 15/09/05, Neal Becker <[EMAIL PROTECTED]> wrote: I use cpython. I'm accustomed (from c++/gcc) to a style of coding that ishighly readable, making the assumption that the compiler will do good things to optimize the code despite the style in which it's written. Forexample, I assume constants are removed from loops. In general, an entityis defined as close to the point of usage as possible. I don't know to what extent these kind of optimizations are available tocpython. For example, are constant calculations removed from loops? Howabout functions? Is there a significant cost to putting a function def inside a loop rather than outside?--http://mail.python.org/mailman/listinfo/python-list-- "A little government and a little luck are necessary in life, but only a fool trusts either of them." -- P. J. O'Rourke ___ 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] python-checkins reply-to
Raymond requested, and Guido concurred, that the python-checkins mailing list Reply-To header munging be turned off. I've now done this. Previously, follow-ups to checkins would be addressed to python-dev. Now, follow-ups will stay on the python-checkins list and will not appear here, unless the poster explicitly redirects it. -Barry signature.asc Description: This is a digitally signed message part ___ 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] os.path.diff(path1, path2)
[Greg Ewing wrote] > Nathan Bullock wrote: > > I find that I quite often want a > > function that will give me a relative path from path A > > to path B. I have created such a function, but it > > would be nice if it was in the standard library. > > +1 from me. It's a fairly common thing to want to do. If this *does* get added (I'm +0) then let's call it "relpath" or "relpathto" as in the various implementations out there: http://www.jorendorff.com/articles/python/path/ http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302594 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/208993 Trent -- Trent Mick [EMAIL PROTECTED] ___ 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 optimization
On Thu, Sep 15, 2005, Neal Becker wrote: > > I use cpython. I'm accustomed (from c++/gcc) to a style of coding > that is highly readable, making the assumption that the compiler will > do good things to optimize the code despite the style in which it's > written. For example, I assume constants are removed from loops. > In general, an entity is defined as close to the point of usage as > possible. > > I don't know to what extent these kind of optimizations are available > to cpython. For example, are constant calculations removed from > loops? How about functions? Is there a significant cost to putting a > function def inside a loop rather than outside? This question is about using Python, not improving/fixing Python; please use comp.lang.python (python-list) for these kinds of questions and do not cc python-dev. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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] python optimization
I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is highly readable, making the assumption that the compiler will do good things to optimize the code despite the style in which it's written. For example, I assume constants are removed from loops. In general, an entity is defined as close to the point of usage as possible. I don't know to what extent these kind of optimizations are available to cpython. For example, are constant calculations removed from loops? How about functions? Is there a significant cost to putting a function def inside a loop rather than outside? ___ 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] Variant of removing GIL.
Corrections: Now, every thread keeps one n queue of objects to incref and second queue to decref. Both can be implemented as array, cause they will be freed at once. Initially, every thread acquires GIL for "read". Py_INCREF places a ref into a incref queue of a thread, Py_DECREF places a ref into a decref queue of a thread. When queue has became full or "100" instruction left ( :-) , it usefull), thread releases GIL for "read" and acquires for "write", when first process acquire it he: walk throw all incref queues in all threads, incref all thouse refs, and clear queues. then walk throw all decref queues in all threads, decref all thouse refs, and clear queues After all he acquires GIL for "read". Other processes could stupidly repeat it founding clear queues. Since there only one thread works as a "garbage collector", we will not loose any incref and decref. ___ 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] Variant of removing GIL.
Excuse my English.
I think I know how to remove GIL Obviously I am an idiot.
First about Py_INCREF and Py_DECREF.
We should not remove GIL at all. We should change it.
It must be "one writer-many reader" in a following semantic:
Lock has a "read-counter" and a "write-counter". Initially both are 0.
When "reader" tries to acquire lock for "read" it sleeps until
"write-counter" is 0.
When he "reader" acquires lock, he increase "read-counter".
When "reader" releases lock, he decreases "read-counter".
One reader will not block other, since he not increases "write-counter".
Reader will sleep, if there is any waiting writers, since they are
increase "write-counter".
When "writer" tries to acquire lock for "write", he increase
"write-counter" and
sleeps until "read-counter" happens 0. For "writers" lock for "write" -
simple lock.
when "writer" release lock, he decrease "write-counter".
When there is no waiting writers, readers arise.
Excuse me for telling obviouse things. I am really reinvent wheel in my
head,
since I was a bad studient.
I think this kind of lock is native for linux (i saw it in a kernel
source, but do not know
is waiting writer locks new readers or not?).
Now, every thread keep an queue of objects to decref. It can be
implemented as array, cause
it will be freed at once.
Initially, every object acquires GIL for "read".
Py_INCREF works as usually,
Py_DECREF places a ref into a queue.
When queue has became full or "100" instruction left ( :-) , it usefull),
thread releases GIL for "read" and acquires for "write",
when he acquire it, he decrefs all objects stored in a queue and clear
queue.
After all he acquires GIL for "read".
But what could we do with changing objects (dicts,lists and another)?
There should be a secondary "one-writer-many-reader" "public-write" GIL
- PWGIL.
SGIL ought to be more complicated, since it should work in RLOCK
semantic for "write" lock.
Lets call this lock ROWMR(reentreed one writer - many reader)
So semantic for ROWMR can be:
When a thread acquires ROWMR lock, it acquires it at a "read" level.
Lets name it "write-level"=0.
While threads "write-level"=0 it is a "reader".
Thread can increase "write-level".
When he turns "write-level" from 0 to 1, he becomes "writer".
while "write-level">0, thread is writer.
Thread can decrease "write-level".
When "write-level" turns from 1 to 0, thread becomes "reader".
With PWGIL :
We can mark every _mutable_ object with a creator thread number.
If mark match current thread number, object is "private" for the thread.
If mark is 0 (or another imposible thread number) object is "public".
If mark !=0 and !=current thread number, object is "alien".
When we access _mutable_ object, we check is it "private"?
If it is, we can do anything without locking.
If it is not and we access for read, we check is it "public".
If yes ("read" of "public"), then we can read it without locking.
If no, we increase "write-level",
if object is "alien", make it "public",
if we need to change object, change it,
decrease "write-level".
Of couse, when we append object to "public" collection, we chould make
it "public",
"write-level" is already increased so we do not make many separate
locks, but
when we then will access thouse object for read, we will not lock for
make it "public".
I don't know, how nested scopes are implemented, but i think it should
be considered as a mutable object.
So there is a small overhead for a single threaded application
( only for comparing 2 numbers)
and in a big part of multithreaded, since we are locking only writting on
_mutable_ _public_ objects. Most part of "public" objects is not
accessed to write
often: they are numbers, classes and mostly-read collections.
And one can optimize a program by accumulating results in a "private"
collection
and then flush it to "public" one.
Also, there may be a statement for explicit increasing "write-level"
around big update
of "public" object and decreasing after it.
PWGIL also must be released and reacquired with every "100" instructions
left,but only if "write-level=0",
it conforms to current GIL semantic.
I think, it must be not released with flushing decref queue, since it
can happen while we are in C code.
And there must be strong think about blocking IO.
Mostly awful situation (at my point of view):
object O is "private" for a thread A.
thread B accesses O and try to mark it "public", so it locks in attempt
of increasing "write-level"
thread A starts to change O (it is in "write-level 0"), and in a C code
it releases PWGIL
(around blocking IO, for example).
thread B becomes "writer", changes object to "public", becomes "reader"
and starts to read O,
returning thread A continue to change O , remaining in a "write-level=0".
But, I think, well written C code should not attemt to make blocking IO
inside of changing non-local objects
(and it does not attempt at the moment, as I guess. Am I
Re: [Python-Dev] Skiping searching throw dictionaries of mro() members.
Phillip J. Eby wrote: > At 09:12 PM 9/14/2005 +0400, Sokolov Yura wrote: > >> We could cash looks by this way: >> Store with a class its version. Every time after creation when we change >> a class >> (add,remove or chage class member, including __base__, __bases__ and >> mro) , >> we increase the version number. Lets call it VERSION > > > FYI, there is already a mechanism for new-style classes that notifies > subclasses of changes to the base class; this mechanism could be used > to push cache flushes downward, rather than doing version checking > upward. > > > I didn't know it. So, if this thing works, it should be used. Another think. I do not really know, how emplemented scopes, but could this caching be applied to a scope realisation? So we "derive" current scope from his outer and cache all lookups, that goes out of this scope. Top scope is "derived" from a module and module it self "derived" from builtins. I think, there not many different deep upper lookups in current programs, but many reapeating, and not often we change outer scope, so cache will be fine. ___ 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/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> This last patch includes a new exception, are you sure that this can
> be
>> safely backported?
>
> Not too worried about it. Better to have the exception reported than
> the silent failure that confused the heck out of everyone who tried to
> figure-out what caused the OP's problem.
>
>
>
>> If so, the documentation changes must be backported, too.
>
> Maybe. My thought is the new message is akin to an improved error
> message. However, adding it to the Py2.4 docs suggests that you could
> catch and handle the exception, but that cannot be done portably across
> Py2.4 versions. If you really feel the need, go ahead and add to the
> docs with \versionadded{2.4.2}. My preference is to leave it be.
Makes sense. It'll be best to leave it be.
Reinhold
--
Mail address is perfectly valid!
___
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
