Re: [Python-Dev] The bytes type
"James Y Knight" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Everyone will continue to code in a | 2.5-compatible dialect for the immediate future, because their code | needs to continue to function in 2.5. ?? But once 2.6 and 3.0 come out, there will be some to many who don't have that need. Anyone who needs their code to function in x.y will have to restrict their code to x.y and not use future additions. And people who don't, may use new features. Nothing new here. I expect that if Guido survives and continues with the Py3 series, then in 10 years, at least half of Python programmers will be essentially Py3 only, either by switching and not looking back or by having learned on Py3. | As I keep pointing out, the | language cleanup doesn't have to be all at once: Of course, and gradual, continual cleanup was the original policy: deprecate, warn, and then remove. But several years ago, enough people complained that Guido said "Ok, we will put non-trivial removals off for several years and then do it all at once in a new 3.0 version." Under the old policy, apply(), old int division (1/2 ==0 instead of .5), and probably some others would have been long gone. Now several years is about here. Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 _Py prefix to names in 2.5.1?
On 1/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: http://python.org/sf/1637022 points out a problem caused by the lack of a _Py prefix on Ellipsis. Most (all?) of the new AST names are not prefixed. These are all meant to be internal names. Are there any issues with changing this? If we do so, it means that any module built with 2.5 that is using these names will fail to work in 2.5.1. No code outside the core *should* be using these names. It makes me terribly uncomfortable, as removing symbols is absolutely not something that should happen in a bugfix release, but I think that, in this case, it is the right thing to do. Well, the least-wrong thing to do. If only C had more visibility control, sigh ;-P -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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-3000] dict.items as attributes [Was: The bytes type]
On 1/16/07, Jim Jewett <[EMAIL PROTECTED]> wrote: Other than dict.items (and .keys and .values) returning a non-list, are there any other cases where the Py3K idiom can't already be used in (or at least backported to) Py 2.x? Well, there is that bit where strings are all unicode, including all string literals and attribute names and all that. And the bit where open() will be different, although how different hasn't been decided yet. (Or rather, it hasn't been written down in code yet, and to me that means it hasn't been decided yet :) What we need to do now is do the work on 3.0, and *then* (and a bit 'during', too) think about backward compatibility. As far as I can see, all the existing changes in the p3yk branch are upgrade-pathable: the int/long unification has long been done on the Python-visible side, 'except as' will make it into 2.6, print/exec as functions can be imported from the future, sys.intern/compile/etc can be made available in 2.6, classic slices are already on the way out, et cetera ad nauseam. The aim for 2.6 should be to have all the new features that 3.0 has, as well as full backward compatibility (albeit potentially with a few extra warnings, as any release might, but only for code that can be written sanely for 2.5-and-earlier as well.) The biggest hurdle will be the unicode/string unification and the I/O system (much bigger than the dict keys/values/items change), but since those haven't been implemented yet, it's rather pointless to talk about how to handle them in 2.6. Is there a chance that this special case could be handled by an import hook in py 2.6? I expect you don't mean an actual import hook, but just a future import? Then sure, there is a chance. We'll have to see. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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-3000] dict.items as attributes [Was: The bytes type]
On 1/17/07, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On 1/16/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > Other than dict.items (and .keys and .values) returning a non-list, > > are there any other cases where the Py3K idiom can't already be used > > in (or at least backported to) Py 2.x? > The aim for 2.6 should be to have all the new features that 3.0 has, > as well as full backward compatibility ... And I'm asking if there are any real barriers to this. Some people have suggested that they'll have to maintain separate code bases. So far, the closest I've seen[1] to something that can't use common-subset is wanting an iterator over a mapping. > Well, there is that bit where strings are all unicode, including all string > literals and attribute names and all that. (But note that attribute names will still be limited to ASCII.) I don't see any problems for python code there, unless you're going out of your way to care which stringlike type you get. I do see that C extensions could be trickier, though I haven't yet see anything that couldn't be handled with some relatively simple conditionally-defined macros. > And the bit where open() will be different, This I couldn't find, unless it was the security abilities. These wouldn't bother conservative code, and could probably be backported to 2.6, or at least 2.7. > The biggest hurdle will be the unicode/string unification and the I/O > system (much bigger than the dict keys/values/items change), but since those > haven't been implemented yet, it's rather pointless to talk about how to > handle them in 2.6. Fair enough. [1] I did miss some introspection names, but that can be handled in python, and anyone using, rather than reinventing, inspect should be fine. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pythn 2.5 buildbots do not build anymore?
Why don't the Python 2.5 buildbots build anymore? http://www.python.org/dev/buildbot/2.5/ Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Testers wanted: mailbox.py bugfix
http://www.python.org/sf/1599254 is a bug in the mailbox.py module that affects single-file mailbox formats (mbox, Babyl, MMDF) and can cause data loss. A proposed fix, mailbox-unified-patch, is attached to the bug. If you use mailbox.py for modifying mailboxes in the above formats, can you please test the patch and report if there are any problems? The bug is pretty complicated, and such bugs in the mailbox.py (and the necessary fixes) make me nervous. Some more testing would be very reassuring. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testers wanted: mailbox.py bugfix
A.M. Kuchling <[EMAIL PROTECTED]> wrote: > http://www.python.org/sf/1599254 is a bug in the mailbox.py module > that affects single-file mailbox formats (mbox, Babyl, MMDF) > and can cause data loss. I can't speak for MMDF or Babyl, but it's a well-known requirement that all programs on a system must use the same type of locking when mbox files are used; the administrator picks his favourite (fcntl, dotlocking, whatever) and then has to ensure all mbox-aware programs are compiled to use that locking style. > A proposed fix, mailbox-unified-patch, is attached to the bug. I'm not sure that this actually fixes the problem, but more to the point -- I'm not sure it should try. Any mail admin that deploys multiple mbox-aware programs with different locking methods is shooting themselves in the foot, regardless of whether Python tries to turn it into "just a flesh wound"... Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On Wednesday 17 January 2007 05:52, James Y Knight wrote: > Yes, this is it. As a refinement: if the New Way can easily be > backported to 2.5, Um - 2.5 is _done_. Released. In maintenance mode. New features will not be getting backported to a 2.5.x release. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On Jan 17, 2007, at 6:22 PM, Anthony Baxter wrote: > On Wednesday 17 January 2007 05:52, James Y Knight wrote: >> Yes, this is it. As a refinement: if the New Way can easily be >> backported to 2.5, > > Um - 2.5 is _done_. Released. In maintenance mode. New features will > not be getting backported to a 2.5.x release. Sorry if I was unclear there. I was not suggesting doing feature changes to 2.5, of course. I meant backported such that they will _run_ on 2.5. And distributed as a private module to go along with my code. This was doable for many advancements in the 2.X series. For example, I could update my code to use heapq and UserDict.DictMixin (which were added in py 2.3), even though it still ran on 2.2, by including a copy of those which were used if you're running 2.2. So code could be written to use a couple new features even though it runs on the old python. This is, of course, only useful if the things you want to backport are very small. Otherwise, you might as well just include a copy of all of Python. :) But this is moot, anyhow, as it has been decreed that it will not be a goal to enable people to write code that runs on both 2.5 and 3.0. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deletion order when leaving a scope?
I just ran a quickie experiment and determined: when leaving a scope, variables are deleted FIFO, aka in the same order they were created. This surprised me; I'd expected them to be deleted LIFO, aka last first. Why is it thus? Is this behavior an important feature or an irrelevant side-effect? Cheers, /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deletion order when leaving a scope?
Larry Hastings <[EMAIL PROTECTED]> wrote: > I just ran a quickie experiment and determined: when leaving a scope, > variables are deleted FIFO, aka in the same order they were created. > This surprised me; I'd expected them to be deleted LIFO, aka last > first. Why is it thus? Is this behavior an important feature or an > irrelevant side-effect? If you are talking about the locals in the scope of a function, it is an artifact of how the locals array is created. That is to say, the locals of a function are a flat array, and are decref'd in-order. That ordering is the original assignment ordering in the function, which is an artifact of how the compiler goes from local name -> FAST_LOCALS index. I don't believe it is an "important feature", but to decref in any other order would be silly and/or unintuitive. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythn 2.5 buildbots do not build anymore?
On 1/17/07, Thomas Heller <[EMAIL PROTECTED]> wrote: > Why don't the Python 2.5 buildbots build anymore? It looks like there were no checkins that caused a build. Changing doc or Misc/NEWS is excluded. I'm guessing that there is a bug in buildbot that causes it to miss any changes from svnmerge. Those should have been caught ISTM. I just checked in a change and the build looks like it's going. http://www.python.org/dev/buildbot/all/changes/521 Thomas, you might want to look at that, cause it's something I don't understand in cytpes. :-) In other buildbot news, I fixed the failures on windows through some lucky guessing. I'm not sure the fixes are optimal, so someone with more Windows knowledge should take a look at them. I also got the alpha tru64 buildbot running again. We still have a few down, but they generally look in decent shape. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
