Re: [Python-Dev] Doc suggestion for Elementtree (for 2.5? a bitlate, I know...)
Steve Holden wrote: Standards, apparently, are for *other* people :-) ET was written years before the certain modules should use camelcase stuff was removed from PEP 8. as a refresher for those of you who have trouble remembering how things were back in early 2004, here's GvR's original style guide: http://www.python.org/doc/essays/styleguide/ Modules that export a single class (or a number of closely related classes, plus some additional support) are often named in MixedCase, with the module name being the same as the class name (e.g. the standard StringIO module). Modules that export a bunch of functions are usually named in all lowercase. /.../ There is an emerging convention that when an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the Python module's name CapWords, while the C/C++ module is named in all lowercase and has a leading underscore (e.g. Tkinter/_tkinter). /F ___ 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] Doc suggestion for Elementtree (for 2.5? a bitlate, I know...)
Fredrik Lundh wrote: ET was written years before the certain modules should use camelcase stuff was removed from PEP 8. Maybe so, but I was hoping that additions to the stdlib in this day and age might be adapted to follow modern conventions instead of just being plonked in as-is. -- Greg ___ 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] Adding an rslice() builtin?
A discussion on the py3k list reminded me that translating a forward slice into a reversed slice is significantly less than obvious to many people. Not only do you have to negate the step value and swap the start and stop values, but you also need to subtract one from each of the step values, and ensure the new start value was actually in the original slice: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Doc suggestion for Elementtree (for 2.5? a bitlate, I know...)
Greg Ewing wrote: Fredrik Lundh wrote: ET was written years before the certain modules should use camelcase stuff was removed from PEP 8. Maybe so, but I was hoping that additions to the stdlib in this day and age might be adapted to follow modern conventions instead of just being plonked in as-is. Unfortunately this doesn't work if you want to encourage existing users to migrate to the built-in version. However, let's hope that Python 3000 will have enforcers patrolling the perimeter of the library with shotguns. It does make us look rather dumb when we set rules that our own code doesn't obey - or change the rules after we've already encouraged contributions under other terms. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Adding an rslice() builtin?
Nick Coghlan wrote: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] How would this deal with omitted start and/or stop values? -- Greg ___ 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] Adding an rslice() builtin?
On 8/29/06, Greg Ewing [EMAIL PROTECTED] wrote: Nick Coghlan wrote: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] How would this deal with omitted start and/or stop values? More generally, given start/stop/step don't have to be numbers, how can this work in general? I don't actually see a need for this, given that reversed(seq[start:stop:step]) covers all of the real use cases I can think of... Paul. ___ 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] Adding an rslice() builtin?
That discussion on py3k is far from finished. We've also had a similar discussion in the past and ended up with reversed(), which solves the problem on the other end (using a forward slice but iterating backwards). Also, when I saw your subject I thought rslice() was related to rfind(), so the name is at best questuinable. Let's drop this until we've got clarity on what Py3k actually will do. --Guido On 8/29/06, Nick Coghlan [EMAIL PROTECTED] wrote: A discussion on the py3k list reminded me that translating a forward slice into a reversed slice is significantly less than obvious to many people. Not only do you have to negate the step value and swap the start and stop values, but you also need to subtract one from each of the step values, and ensure the new start value was actually in the original slice: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Doc suggestion for Elementtree (for 2.5? a bitlate, I know...)
On Tue, Aug 29, 2006, Greg Ewing wrote: Fredrik Lundh wrote: ET was written years before the certain modules should use camelcase stuff was removed from PEP 8. Maybe so, but I was hoping that additions to the stdlib in this day and age might be adapted to follow modern conventions instead of just being plonked in as-is. You have a point, but I think that for external libraries with a large following the best we can do is set things up so that it's both PEP8 compliant *and* has aliases to the existing setup. From my POV, it's critical to encourage people to switch to the stdlib version if possible (but often writing code that works with the external library is the only way to support multiple Python versions). That parenthetical bit is the real killer, and I don't think even Py3K can completely overcome it if PEP8 continues to evolve. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ 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] Adding an rslice() builtin?
Greg Ewing wrote: Nick Coghlan wrote: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] How would this deal with omitted start and/or stop values? Badly! (negative indices are screwed, too) This would be an awful lot easier if we could just subclass slice, and do the calculation in the indices() method where we have access to len(seq) in order to deal with an omitted stop value and negative indices. Ah well, never mind. I'll take it back to the Py3k list, and see if I can find some small changes we can make so that slice() doesn't feel like a bolted-on hack that exists solely to avoid the need for a new special method :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Interest in a Python 2.3.6?
I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be the release manager for 2.3.6, but I'm hoping you all will be able to help identify the most important bugs that need fixing. First, is there interest in getting a 2.3.6 release out? I'd propose keeping things simple, by picking a date and releasing what we've got at that date (assuming of course all the unit tests pass). It's probably a good idea to add a wiki page tracking the fixes we want to get in there. 2.5 final is slated for 12-Sep-2006 and I know that Anthony is planning for a 2.4.4 soon after that. I'm thinking that we'd try to do a 2.3.6 a couple of weeks after 2.4.4 so that people who care about it aren't stacked up with fixing too many branches at once. My first thought was to shoot for Monday October 9th. What are the potential 2.3.6 fixes? Nothing on this page: http://www.python.org/download/releases/2.3.5/bugs/ seems critical to me. I know that I've added some important email package fixes that are already in Subversion. There are tons of bugs and patches reported against 2.3 in SF (lament: why won't SF just /tell/ me how many there are?), but I have no idea atm which, if any, are important enough to go into a 2.3.6. I haven't yet done an svn diff to see what changes are already in there. I don't have the cycles to fix things myself, so it would be up to everyone to help commit fixes. I'll ride herd a bit if necessary.Thoughts? I don't want to waste my time if nobody thinks a 2.3.6 would be useful, but I'm happy to do it if there's community support. I'll also need the usual help with Windows installers and documentation updates.Cheers,-Barry PGP.sig 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] Interest in a Python 2.3.6?
Barry Warsaw wrote: I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be the release manager for 2.3.6, but I'm hoping you all will be able to help identify the most important bugs that need fixing. First, is there interest in getting a 2.3.6 release out? I'd propose keeping things simple, by picking a date and releasing what we've got at that date (assuming of course all the unit tests pass). It's probably a good idea to add a wiki page tracking the fixes we want to get in there. 2.5 final is slated for 12-Sep-2006 and I know that Anthony is planning for a 2.4.4 soon after that. I'm thinking that we'd try to do a 2.3.6 a couple of weeks after 2.4.4 so that people who care about it aren't stacked up with fixing too many branches at once. My first thought was to shoot for Monday October 9th. What are the potential 2.3.6 fixes? Nothing on this page: http://www.python.org/download/releases/2.3.5/bugs/ seems critical to me. I know that I've added some important email package fixes that are already in Subversion. There are tons of bugs and patches reported against 2.3 in SF (lament: why won't SF just /tell/ me how many there are?), but I have no idea atm which, if any, are important enough to go into a 2.3.6. Most of them are also in the 2.4 releases... I haven't yet done an svn diff to see what changes are already in there. There's one problem: it was thought for a long time that there wouldn't be any more 2.3 releases, so bug fixes were applied only in the head and 2.4 branch. If there will be a 2.3.6, it might be necessary to look at all 2.4 branch fixes and decide which of them are worth backporting. Georg ___ 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] Interest in a Python 2.3.6?
Barry Warsaw [EMAIL PROTECTED] wrote: I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be the release manager for 2.3.6, but I'm hoping you all will be able to help identify the most important bugs that need fixing. What are the potential 2.3.6 fixes? Nothing on this page: These are both issues in 2.3 and 2.4: http://www.python.org/sf/780714 http://www.python.org/sf/1548687 Those are all I have off the top of my head. - Josiah ___ 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] Adding an rslice() builtin?
Nick Coghlan wrote: A discussion on the py3k list reminded me that translating a forward slice into a reversed slice is significantly less than obvious to many people. Not only do you have to negate the step value and swap the start and stop values, but you also need to subtract one from each of the step values, and ensure the new start value was actually in the original slice: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] Or slice.reversed(). -- David Hopwood [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] Adding an rslice() builtin?
On Tue, 29 Aug 2006 17:44:40 +0100, David Hopwood [EMAIL PROTECTED] wrote: Nick Coghlan wrote: A discussion on the py3k list reminded me that translating a forward slice into a reversed slice is significantly less than obvious to many people. Not only do you have to negate the step value and swap the start and stop values, but you also need to subtract one from each of the step values, and ensure the new start value was actually in the original slice: reversed(seq[start:stop:step]) becomes seq[(stop-1)%abs(step):start-1:-step] An rslice builtin would make the latter version significantly easier to read: seq[rslice(start, stop, step)] Or slice.reversed(). Better, slice.reversed(length). Jean-Paul ___ 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] draft for bug guidelines
On 8/28/06, Steve Holden [EMAIL PROTECTED] wrote: Brett Cannon wrote: Made it the first step.=) -Brett On 8/24/06, *Oleg Broytmann* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: On Thu, Aug 24, 2006 at 12:21:06PM -0700, Brett Cannon wrote: Start a new bugBefore starting a new bug please try to search if the bug has already been reported. It it has - do not start a new report, add your comments to the existing report.You probably want to include some advice about how. Isn't this rather an inappropriate time to be writing SF user notes, given that you areplanning to provide us with an alternative to SF by the end of the year?No because we have people reporting bugs between now and the end of the year which is four months away. The last thing we need is a how to submit a bug article that sends people to the wrong repository ...But the whole point is for these things to end up on www.python.org/dev/ where I will update them as soon as we have a new tracker selected and before the new tracker is even used. -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] gcc 4.2 exposes signed integer overflows
Hi Tim, On Sat, Aug 26, 2006 at 08:37:46PM -0400, Tim Peters wrote: [Thomas Wouters] Why not just ... x == LONG_MIN? it's better (when possible) not to tie the code to that `x` was specifically declared as type long (e.g., just more stuff that will break if Python decides to make its short int of type PY_LONG_LONG instead). The proposed correct fix breaks this goal too: if (y == -1 x 0 (unsigned long)x == -(unsigned long)x). ^^ A bientot, Armin ___ 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] Interest in a Python 2.3.6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 29, 2006, at 11:29 AM, Georg Brandl wrote: There's one problem: it was thought for a long time that there wouldn't be any more 2.3 releases, so bug fixes were applied only in the head and 2.4 branch. If there will be a 2.3.6, it might be necessary to look at all 2.4 branch fixes and decide which of them are worth backporting. Right, we'll definitely have to do that, and maybe not much more. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRPSmuXEjvBPtnXfVAQKyegQAgpzLpPddKE03wg3orKvlHPJXFKpbaLvd 4gIRIgvqwGjKwjxY4s8Gn55axHJM8YBwJ+IbCzYg3nmBB3JvljuKNxTZtz4w781Y BS/apc8Ng+2wv/W8Eo2zVbbRformZa24H/d8Gq5Mdst1yTrcAwwcO7k1hHjAl9w8 HFIWjechAVg= =4wXb -END PGP SIGNATURE- ___ 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] 32-bit and 64-bit python on Solaris
Hi, I work in the team that delivers python on Solaris. Recently we've been getting requests for delivering python in 64-bit as well as in 32-bit. As you probably know, Solaris can run 64-bit and 32-bit binaries on the same system, but of course you can't mix and match shared objects with different ISAs. This seems to apply to python bytecode as well: the pyc files generated by a 64-bit build of python are incompatible with those generated by the 32-bit python. Note the caveat at http://aspn.activestate.com/ASPN/docs/ActivePython/2.3/python/lib/module-marshal.html I guess my first question is if there are any plans to make the bytecodes for different ISAs compatible. That would make most of our problems magically go away (; If not, then the issue we have is how to separate the 32-bit and 64-bit pyc's on the same system so that: - loading the right pyc is transparent to the user - you can't accidentally load a pyc with the wrong ISA (by setting PYTHONPATH, for example) So duplicating the libdir is not an option. The usual technique used for Solaris shared objects is placing the 64-bit objects in a 64/ subdirectory, while the 32-bit objects stay where they are. We considered various solutions. Our current proposal is this: .../some/dir/foo.py - python source .../some/dir/foo.pyc - 32-bit bytecode .../some/dir/foo.pyc64 - 64-bit bytecode .../some/dir/foo.pyo - optimised 32-bit bytecode .../some/dir/foo.pyo64 - optimised 64-bit bytecode The 64-bit python would always look for pyc64/pyo64, so this would take care of accidentally loading the wrong ISA. PYTHONPATH could be the same for the 32-bit and the 64-bit python. Shared objects: .../some/dir/foo.so - 32-bit shared object .../some/dir/64/foo.so- 64-bit shared object This is kinda inconsistent, but simple enough. The 64-bit python would automatically look for shared objects in the 64/ subdir. ld.so.1 makes sure that the wrong share object is never loaded. So I'm looking for advice and wondering if it would be possible to support multiple ISAs out of the box. Would you be willing to accept patches that implement the above (or whatever solution we agree to) on Solaris? Thanks, Laca ___ 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] Small Py3k task: fix modulefinder.py
Is anyone familiar enough with modulefinder.py to fix its breakage in Py3k? It chokes in a nasty way (exceeding the recursion limit) on the relative import syntax. I suspect this is also a problem for 2.5, when people use that syntax; hence the cross-post. There's no unittest for modulefinder.py, but I believe py2exe depends on it (and of course freeze.py, but who uses that still?) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] 32-bit and 64-bit python on Solaris
[Laszlo (Laca) Peter] I work in the team that delivers python on Solaris. Recently we've been getting requests for delivering python in 64-bit as well as in 32-bit. As you probably know, Solaris can run 64-bit and 32-bit binaries on the same system, but of course you can't mix and match shared objects with different ISAs. This seems to apply to python bytecode as well: the pyc files generated by a 64-bit build of python are incompatible with those generated by the 32-bit python. Note the caveat at http://aspn.activestate.com/ASPN/docs/ActivePython/2.3/python/lib/module-marshal.html Which caveat, specifically? As it says there, the only known problem was fixed in Python 2.2: This behavior is new in Python 2.2. In earlier versions, all but the least- significant 32 bits of the value were lost, and a warning message was printed I guess my first question is if there are any plans to make the bytecodes for different ISAs compatible. That would make most of our problems magically go away (; I suspect they already have ;-) There are no plans to make marshal store a Python long object on a 64-bit box for integers that fit in 64 points but not in 32 bits, and there would be very little point to doing so. As the referenced page says, you get the same numeric value regardless. It's /possible/ to write Python code to detect the difference in type, but real code wouldn't do that. ... ___ 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
I would like to see the changes to the decimal module reverted for the Py2.5 release. Currently, the code in the decimal module implements the context manager as a separate class instead of incorporating it directly in decimal.Context. This makes the API unnecessarily complex and is not pretty compared to the code it was intended to replace. Worse still, the implementation saves a reference to the context instead of making a copy of it. Remember decimal.Context objects are mutable -- the current implementation does not fulfill its contract to restore the context to its original state at the conclusion of the with-statement. The right way to do it was presented in PEP343. The implementation was correct and the API was simple. Additionally: * The examples in WhatsNew don't work because the implementation uses a different method name to fetch to context (this is a shallow error except that the name in WhatsNew is better and we don't really want to have a new method for this). It doesn't bode well that none of the release candidate end users noticed this discrepancy -- it means they are not trying out the examples. * The implementation's doc string examples were not tested and don't work (this is a deep error). One reads: with decimal.getcontext() as ctx: ctx.prec += 2 s = ... return +s To get this to work with the current implementation, it should read with decimal.getcontext().copy().get_manager() as ctx: ctx.prec += 2 s = ... return +s This is horrid. Please either revert the patch or fix it to match PEP-343. 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote: * The implementation's doc string examples were not tested and don't work (this is a deep error). One reads: with decimal.getcontext() as ctx: ctx.prec += 2 s = ... return +s To get this to work with the current implementation, it should read with decimal.getcontext().copy().get_manager() as ctx: ctx.prec += 2 s = ... return +s This is horrid. Please either revert the patch or fix it to match PEP-343. Actually, as I read the code, that would be: with decimal.getcontext().get_manager() as ctx: Which is still horrible, but unfortunately Guido has already pronounced that __context__ must be removed from PEP 343, which is what caused this abomination to come about. The PEP currently offers the idea of a 'localcontext()' API that provides a nicer spelling, but it appears nobody implemented it. ___ 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] 32-bit and 64-bit python on Solaris
On Tue, 2006-08-29 at 19:07 -0400, Tim Peters wrote: I work in the team that delivers python on Solaris. Recently we've been getting requests for delivering python in 64-bit as well as in 32-bit. As you probably know, Solaris can run 64-bit and 32-bit binaries on the same system, but of course you can't mix and match shared objects with different ISAs. This seems to apply to python bytecode as well: the pyc files generated by a 64-bit build of python are incompatible with those generated by the 32-bit python. Note the caveat at http://aspn.activestate.com/ASPN/docs/ActivePython/2.3/python/lib/module-marshal.html Which caveat, specifically? As it says there, the only known problem was fixed in Python 2.2: This behavior is new in Python 2.2. In earlier versions, all but the least- significant 32 bits of the value were lost, and a warning message was printed Hmm... I must be going blind reading that wrong. So it's expected to Just Work and if not, that's a bug. That's cool, thanks. Now all that is left is taking care of the 64-bit shared objects. Thanks, Laca ___ 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
Raymond Hettinger wrote: I would like to see the changes to the decimal module reverted for the Py2.5 release. Currently, the code in the decimal module implements the context manager as a separate class instead of incorporating it directly in decimal.Context. That should read ... as a separate class instantiated by a brand-new Context method instead of implementing it as a module level function as shown in section 9 of PEP343. The API in PEP343 is much cleaner. Also, it doesn't have the copy vs reference bug. 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
Phillip J. Eby wrote: At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote: * The implementation's doc string examples were not tested and don't work (this is a deep error). One reads: with decimal.getcontext() as ctx: ctx.prec += 2 s = ... return +s To get this to work with the current implementation, it should read with decimal.getcontext().copy().get_manager() as ctx: ctx.prec += 2 s = ... return +s This is horrid. Please either revert the patch or fix it to match PEP-343. Actually, as I read the code, that would be: with decimal.getcontext().get_manager() as ctx: Given the current mis-implementation, the copy() step is absolutely necessary. Since context objects are mutable, the current context would never get it precision and flags restored. Try running the example and printing out the current context precision before and after the with-suite. You'll see that the context has changed (which defeats the whole purpose). Which is still horrible, but unfortunately Guido has already pronounced that __context__ must be removed from PEP 343, which is what caused this abomination to come about. The PEP currently offers the idea of a 'localcontext()' API that provides a nicer spelling, but it appears nobody implemented it. Right. The PEP version was correct and desirable. But at this point, it is better to have nothing at all. Users can still write their own (a la example 8 in the PEP). I do not want the decimal API to be forever mucked-up; hence, we should revert the change. Since it is buggy, that makes the decision an easy one to swallow. 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] gcc 4.2 exposes signed integer overflows
On Wednesday 30 August 2006 08:57, Tim Peters wrote: Speaking of which, I saw no feedback on the proposed patch in http://mail.python.org/pipermail/python-dev/2006-August/068502.html so I'll just check that in tomorrow. Fine with me! thanks, Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] gcc 4.2 exposes signed integer overflows
On Wednesday 30 August 2006 08:57, Tim Peters wrote: Speaking of which, I saw no feedback on the proposed patch in http://mail.python.org/pipermail/python-dev/2006-August/068502.html so I'll just check that in tomorrow. This should also be backported to release24-maint and release23-maint. Let me know if you can't do the backport... -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
At 05:57 PM 8/29/2006 -0700, Raymond Hettinger wrote: Phillip J. Eby wrote: At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote: * The implementation's doc string examples were not tested and don't work (this is a deep error). One reads: with decimal.getcontext() as ctx: ctx.prec += 2 s = ... return +s To get this to work with the current implementation, it should read with decimal.getcontext().copy().get_manager() as ctx: ctx.prec += 2 s = ... return +s This is horrid. Please either revert the patch or fix it to match PEP-343. Actually, as I read the code, that would be: with decimal.getcontext().get_manager() as ctx: Given the current mis-implementation, the copy() step is absolutely necessary. Since context objects are mutable, the current context would never get it precision and flags restored. Try running the example and printing out the current context precision before and after the with-suite. You'll see that the context has changed (which defeats the whole purpose). No need; now that you've explained the problem I see why the code is wrong. This is definitely a bug in the decimal module. It looks like the code is correct at first glance, but the .copy() definitely needs to be in the ContextManager class, not the get_manager() method. Yuck. ___ 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
