Re: [Python-Dev] The bytes type
On Jan 12, 2007, at 7:26 PM, Ron Adam wrote: > For me, the thing that will make porting 2.x to 3.x code easy is to > make python > 3.0 as clean and organized as you can with excellent > documentation. Half-way > and duel-way approaches will probably not help me as much as this. > > Most of the difficulty I have in converting programs is in finding the > information I need. The actual editing is not a problem. Yes, the actual editing is not a problem, as long as you only need to do it once. The problem is when you have a module/program/whatever that you need to provide a release of for 2.5 and would also like to provide a release of for 3.0. Then, the editing becomes a problem, because you have to do it again for every change you make. James ___ 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] The bytes type
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: >> The benefit (to me, and to many others) of 3.x over 2.x is the >> promise >> of getting rid of cruft. >> If we're going to re-add cruft for the sake of temporary >> compatibility, we may as well just stick with 2.x. You have to >> take a >> quantum leap sometimes or you end up working around the same old >> mistakes. >> > There seems to be rather a lot of confusion. No one is suggesting > Python 3.0 be anything less for the sake of backward compatibility. > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > something *more* in order to provide for an easier upgrade path. No > compromises in Python 3.0. > True: nobody is suggesting python 3.0 be anything less. But, I am indeed suggesting that Python 3.0 be something *more*: I am suggesting that people keep in mind the ease of writing of a program which can run on both 2.5 and 3.0. And wherever possible, act so as to preserve that ease. That may indeed involve a "compromise" in 3.0. Given that Python 3.0 is supposed to be released in ~ 1.5 years (I guess), around the same time as the 2.6 release, I do think 3.0 ought to have a compatibility story that doesn't depend on 2.6. My goal here is not to get Py3.0 to be backwards compatible, it's to get the intersection of 2.5 and 3.0 to be large enough that I can explicitly write code to that intersection without having to tear my hair out and make the code incredibly gross (or worse yet, not be able to do it at all). See previous iteritems() example. I really don't see why there's such an urgency for removing things IMMEDIATELY in Python 3 that don't have a suitable replacement in an already released version. There's plenty to remove which already does have a suitable replacement. I think the major cruft all falls into this category (unicode strings already exist, newstyle classes already exist, non-string exceptions already exist. The 'bytes' type doesn't exist yet, but I expect can be introduced in such a way that it has a useful intersection of functionality with the current method of using 'str' to hold bytes.) I'd like to remind everyone that 3.0 won't be the last version of python ever released (at least, I hope!). Where Py 3.0 introduces a brand-new way to do something, the old can be removed at a future date. Mark it as deprecated, so that nobody will use it in new code, and remove it a few more versions down the line. Getting rid of cruft is great...but you can't properly call something "cruft" when it's the only way. Allowances for writing portable code could make a big difference in speed of adoption. I expect Python 3.0 will be a "quantum leap", even if people don't have to rewrite everything from scratch or fork their codebases to keep compatibility with both releases. There's plenty to look forward to, and I'd love to actually be able to actually use it. But I need to be able to run 3rd party libraries, and the 3rd party libraries must still remain compatible with earlier releases. If those requirements are incompatible with using Py 3.0, it'll be a shame. James ___ 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-3000] Warning for 2.6 and greater
On Mon, Jan 15, 2007 at 11:40:22PM +0100, "Martin v. L??wis" wrote: > > Do I just suffer from having an overactive imagination? Are all of > > these implementation strategies impossible for some reason, and there > > are no others? > > Yes, and yes. What about turning all references to obj.items into the equivalent bytecode for this: if isinstance(obj, dict): # XXX should this be 'type(obj) is dict'? if <2.x behaviour>: _temp = obj.items elif <3.x behaviour>: _temp = obj.iteritems else: _temp = obj.items Ugly; very ugly. --amk ___ 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] The bytes type
On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > There seems to be rather a lot of confusion. No one is suggesting > > Python 3.0 be anything less for the sake of backward compatibility. > > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > > something *more* in order to provide for an easier upgrade path. No > > compromises in Python 3.0. > > True: nobody is suggesting python 3.0 be anything less. But, I am > indeed suggesting that Python 3.0 be something *more*: I am > suggesting that people keep in mind the ease of writing of a program > which can run on both 2.5 and 3.0. And wherever possible, act so as > to preserve that ease. That may indeed involve a "compromise" in 3.0. I'm not keen on compromises in 3.0, but without specific proposals I don't see why we're arguing. So, please, what specific thing(s) are you proposing we do in 3.0? Please make a list of specifics rather than attempting at specifying a general rule to match things that could go into the list; you've tried the latter and I still don't know what you want. -- --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] The bytes type
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > > There seems to be rather a lot of confusion. No one is suggesting > > > Python 3.0 be anything less for the sake of backward compatibility. > > > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > > > something *more* in order to provide for an easier upgrade path. No > > > compromises in Python 3.0. > > > > True: nobody is suggesting python 3.0 be anything less. But, I am > > indeed suggesting that Python 3.0 be something *more*: I am > > suggesting that people keep in mind the ease of writing of a program > > which can run on both 2.5 and 3.0. And wherever possible, act so as > > to preserve that ease. That may indeed involve a "compromise" in 3.0. > >I'm not keen on compromises in 3.0, but without specific proposals I >don't see why we're arguing. So, please, what specific thing(s) are >you proposing we do in 3.0? Please make a list of specifics rather >than attempting at specifying a general rule to match things that >could go into the list; you've tried the latter and I still don't know >what you want. I think what he's saying boils down to two things: * Don't remove any feature for which an alternative doesn't already exist in 2.5 * Don't change APIs (e.g. items()) Now, I'm not sure these goals are achievable with respect to 2.5. I think we'd be better off adding compatibility features in 2.6. To be honest, the items() and keys() thing personally baffles me. If they're supposed to be *views* on the underlying dictionary, wouldn't it make more sense for them to be *attributes* instead of methods? I.e. dict.items and dict.keys. Then, we could provide that feature in 2.6, and drop the availability of the callable forms in 3.0. Then you could write code like: for k,v in somedict.items: ... And have it work in 2.6 and 3.0. Meanwhile, .items() would still return a list in 2.6 (but be warnable about with a -3 switch), but go away entirely in 3.0. It's not a panacea, but at least would make it *possible* to write code that runs on both 3.0 and some 2.x version. Without having at least *some* 2.x version that can run 3.x code, I think there is little chance of 3.0 becoming viable. You've been comparing this to Zope 2/Zope 3, but in that world there is something called "Five" that lets you do Zope 3 things inside of Zope 2, so you have some chance of porting your code in an incremental fashion, without having to leap everything over in one go. You've cited JoS on your decision not to do 3.0 as a ground-up rewrite, so perhaps you'll find this other JoS article relevant here: """It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn't want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you're the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can't switch until you can participate in the 123 ecology.""" http://www.joelonsoftware.com/articles/fog52.html The analogy isn't perfect, because we are not so much trying to provide backward compatibility in "Excel" as to add *forward* compatibility to "123", but you get the idea. ___ 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] The bytes type
On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: > >On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > > > There seems to be rather a lot of confusion. No one is suggesting > > > > Python 3.0 be anything less for the sake of backward compatibility. > > > > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > > > > something *more* in order to provide for an easier upgrade path. No > > > > compromises in Python 3.0. > > > > > > True: nobody is suggesting python 3.0 be anything less. But, I am > > > indeed suggesting that Python 3.0 be something *more*: I am > > > suggesting that people keep in mind the ease of writing of a program > > > which can run on both 2.5 and 3.0. And wherever possible, act so as > > > to preserve that ease. That may indeed involve a "compromise" in 3.0. > > > >I'm not keen on compromises in 3.0, but without specific proposals I > >don't see why we're arguing. So, please, what specific thing(s) are > >you proposing we do in 3.0? Please make a list of specifics rather > >than attempting at specifying a general rule to match things that > >could go into the list; you've tried the latter and I still don't know > >what you want. > > I think what he's saying boils down to two things: > > * Don't remove any feature for which an alternative doesn't already exist > in 2.5 Without specific features named I don't understand what this means. > * Don't change APIs (e.g. items()) That's a non-starter. "Don't change APIs" means essentially nothing can be changed. > Now, I'm not sure these goals are achievable with respect to 2.5. I think > we'd be better off adding compatibility features in 2.6. > > To be honest, the items() and keys() thing personally baffles me. If > they're supposed to be *views* on the underlying dictionary, wouldn't it > make more sense for them to be *attributes* instead of methods? I.e. > dict.items and dict.keys. Let's have that discussion on the py3k list. We went through that and I definitely don't want them to be just attributes (it was proposed several times before). I'd be happy to come up with a rationale, but not here. > Then, we could provide that feature in 2.6, and > drop the availability of the callable forms in 3.0. This is clearly an example of constraining 3.0 in order to provide better compatibility, which is a contradiction of 3.0's very existence. [...] > It's not a panacea, but at least would make it *possible* to write code > that runs on both 3.0 and some 2.x version. Actually it's very easy to write code using keys(), items() and values() that works as well in 2.2 as it works in 3.0: never use the iter* variants, and don't sweat the performance costs of creating a list so much. If you can't afford to create a list, iterate over the dict itself, which will give you the keys in both versions. > Without having at least *some* 2.x version that can run 3.x code, I think > there is little chance of 3.0 becoming viable. You've been comparing this > to Zope 2/Zope 3, but in that world there is something called "Five" that > lets you do Zope 3 things inside of Zope 2, so you have some chance of > porting your code in an incremental fashion, without having to leap > everything over in one go. I'm not aware of compromises to 3.0's architecture that were made in order to ease the transition though -- all of the burden was placed on Zope 2.x (though perhaps some optional compatibility packages were also added to Zope 3.0?). > You've cited JoS on your decision not to do 3.0 as a ground-up rewrite, so > perhaps you'll find this other JoS article relevant here: > > """It turns out that what was stopping people from switching to Excel was > that everybody else they worked with was still using Lotus 123. They didn't > want a product that would create spreadsheets that nobody else could read: > a classic Chicken and Egg problem. When you're the lone Excel fan in a > company where everyone else is using 123, even if you love Excel, you can't > switch until you can participate in the 123 ecology.""" > > http://www.joelonsoftware.com/articles/fog52.html > > The analogy isn't perfect, because we are not so much trying to provide > backward compatibility in "Excel" as to add *forward* compatibility to > "123", but you get the idea. Such analogies are hard to get right; in this case he's talking about file interchange formats. Perhaps the closest analogy is pickling. AFAIK pickles are exchangeable between the two now; if at some point they grow apart, it shouldn't be too hard to add a new default pickling protocol to 3.0 and add support for it to 2.6. -- --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/pytho
Re: [Python-Dev] dict.items as attributes [Was: The bytes type]
Phillip J. Eby wrote: > To be honest, the items() and keys() thing personally baffles me. If > they're supposed to be *views* on the underlying dictionary, wouldn't > it > make more sense for them to be *attributes* instead of methods? I.e. > dict.items and dict.keys. Then, we could provide that feature in > 2.6, and > drop the availability of the callable forms in 3.0. > > Then you could write code like: > > for k,v in somedict.items: > ... > > And have it work in 2.6 and 3.0. Meanwhile, .items() would still > return a > list in 2.6 (but be warnable about with a -3 switch), but go away > entirely > in 3.0. I think this comes down to whether or not the views returned have any independent state. There's something that tells me that attributes (even properties) should not return different objects with independent state - working on two views obtained from the same dictionary property should either work identically to working on one view bound to two names, or they should not be obtained from a property. But unless I'm mistaken, everything done to a view would pass through to the dict, or result in another object that has independent state (e.g. iter()) so the effect of working on two views of a dict *would* be identical to working on two names to the same view. The only case I can think of for which we might want to hold state in the view is for detecting concurrent modification - I know that iterators should throw exceptions in this case, but I can't remember what (if anything) was decided for views. Tim Delaney ___ 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] The bytes type
At 09:50 AM 1/16/2007 -0800, Guido van Rossum wrote: >Actually it's very easy to write code using keys(), items() and >values() that works as well in 2.2 as it works in 3.0: never use the >iter* variants, and don't sweat the performance costs of creating a >list so much. If you can't afford to create a list, iterate over the >dict itself, which will give you the keys in both versions. Actually, the main reason I use items() or keys() is because I want to mutate the dictionary, or because something else is going to mutate it while I'm looping over it. But yeah, that discussion should be on Py3K. >>Without having at least *some* 2.x version that can run 3.x code, I think >>there is little chance of 3.0 becoming viable. You've been comparing this >>to Zope 2/Zope 3, but in that world there is something called "Five" that >>lets you do Zope 3 things inside of Zope 2, so you have some chance of >>porting your code in an incremental fashion, without having to leap >>everything over in one go. > >I'm not aware of compromises to 3.0's architecture that were made in >order to ease the transition though -- all of the burden was placed on >Zope 2.x (though perhaps some optional compatibility packages were >also added to Zope 3.0?). Right, which is why I don't think we should worry about 2.5 as much as 2.6. >>The analogy isn't perfect, because we are not so much trying to provide >>backward compatibility in "Excel" as to add *forward* compatibility to >>"123", but you get the idea. > >Such analogies are hard to get right; in this case he's talking about >file interchange formats. Perhaps the closest analogy is pickling. Actually, I meant the analogy for *code*. If you can't write code that runs on some 2.x + 3.x combination, you have no way to cross the chasm. If you're writing "spreadsheets for Excel" (code that runs on 3.x), you need to be able to "share them with 1-2-3 users" (run that code on 2.x). ___ 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] The bytes type
On Jan 16, 2007, at 12:06 PM, Phillip J. Eby wrote: > At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: >> I'm not keen on compromises in 3.0, but without specific proposals I >> don't see why we're arguing. So, please, what specific thing(s) are >> you proposing we do in 3.0? Please make a list of specifics rather >> than attempting at specifying a general rule to match things that >> could go into the list; you've tried the latter and I still don't >> know >> what you want. > > I think what he's saying boils down to two things: > > * Don't remove any feature for which an alternative doesn't already > exist in 2.5 Yes, this is it. As a refinement: if the New Way can easily be backported to 2.5, that's somewhat acceptable as well (but not *as* good, as it requires everyone wanting to write the portable code to include the backport or depend on an external package providing it). > * Don't change APIs (e.g. items()) No: changing APIs is fine just so long as the API being changed can already be replaced by something better. E.g. changing d.items() is fine with me: it's trivially replaced in 2.5 with list(d.iteritems ()). But changing/removing d.iteritems() is not okay, as it's not easily replaced by anything that will work well in both versions. > Now, I'm not sure these goals are achievable with respect to 2.5. > I think we'd be better off adding compatibility features in 2.6. I don't like the proposals to only have the ability to be compatible with 2.6, because that significantly delays the ability to port to 3.0. If it's possible to be compatible between 2.5/3.0, I can start doing the work porting to 3.0 soon after it comes out, even while remaining compatible with a widely-deployed version of python. If the compatibility only works with 2.6/3.0, it will be another 2-3 years after 2.6 comes out before it's widely deployed enough to require it and thus that much longer before porting can start. Really I'm interested in 2.4/3.0 portability, but I quite expect that if I can get 2.5/3.0, I can easily enough deal with the changes between 2.4/2.5 myself, so I'm not going to bother python-dev about that. :) James ___ 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] buglet in long("123\0", 10)
Added a check in test_long.LongTest.test_misc() that long("123\0", 10)
fails properly and adapted the patch to int_new to long_new. I get
this weird feeling that if its impossible for the function
(PyLong_FromString) to know if its being given bad data, having know
way to know if the string is supposed to continue past the zero-byte,
then doesn't it make sense to say that the function by design is
broken? Anyway, here is the patch.
Index: Objects/longobject.c
===
--- Objects/longobject.c(revision 53406)
+++ Objects/longobject.c(working copy)
@@ -3287,10 +3287,27 @@
return PyLong_FromLong(0L);
if (base == -909)
return PyNumber_Long(x);
- else if (PyString_Check(x))
+ if (PyString_Check(x)) {
+ /* Since PyLong_FromString doesn't have a length parameter,
+* check here for possible NULs in the string. */
+ char *string = PyString_AS_STRING(x);
+ if (strlen(string) != PyString_Size(x)) {
+ /* create a repr() of the input string,
+* just like PyLong_FromString does. */
+ PyObject *srepr;
+ srepr = PyObject_Repr(x);
+ if (srepr == NULL)
+ return NULL;
+ PyErr_Format(PyExc_ValueError,
+"Invalid literal for long() with base %d: %s",
+base, PyString_AS_STRING(srepr));
+ Py_DECREF(srepr);
+ return NULL;
+ }
return PyLong_FromString(PyString_AS_STRING(x), NULL, base);
+ }
#ifdef Py_USING_UNICODE
- else if (PyUnicode_Check(x))
+ if (PyUnicode_Check(x))
return PyLong_FromUnicode(PyUnicode_AS_UNICODE(x),
PyUnicode_GET_SIZE(x),
base);
@@ -3439,3 +3456,4 @@
long_new, /* tp_new */
PyObject_Del, /* tp_free */
};
+
Index: Lib/test/test_long.py
===
--- Lib/test/test_long.py (revision 53406)
+++ Lib/test/test_long.py (working copy)
@@ -299,6 +299,8 @@
slicemin, slicemax = X()[-2L**100:2L**100]
self.assertEqual(X()[slicemin:slicemax], (slicemin, slicemax))
+self.assertRaises(ValueError, long, "123\0", 10)
+
# --- tests of auto int->long conversion
def test_auto_overflow(self):
### END PATCH
On 1/15/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Calvin,
>
> Was Guido's answer enough or did you want some more? If you take a
> look at the svn rev I sent, I think it should be pretty easy to come
> up with a patch for long too.
>
> Getting the size won't help (exactly), since the problem is the diff
> between strlen() and the size. You can see this in the int() fix.
>
> Let me know if you have any questions. It would be great if you could
> produce a patch.
>
> Cheers,
> n
> --
> On 1/14/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > Is it a more general problem that null-terminated strings are used
> > with data from strings we specifically allow to contain null bytes?
> > Perhaps a migration of *FromString() to *FromStringAndSize()
> > functions, or taking Python string object pointers, would be a more
> > general solution to set as a goal, so this sort of thing can't crop up
> > down the road, again.
> >
> > I know I'm still very uninitiated in the internals of CPython, so
> > anyone please correct me if my thoughts here are against any on-going
> > policy or reasoning.
> >
> > On 1/14/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > > SVN rev 52305 resolved Bug #1545497: when given an explicit base,
> > > int() did ignore NULs embedded in the string to convert.
> > >
> > > However, the same fix wasn't applied for long().
> > >
> > > n
> > >
> > > On 1/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > What's wrong with this session? :-)
> > > >
> > > > Python 2.6a0 (trunk:53416, Jan 13 2007, 15:24:17)
> > > > [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> > > > Type "help", "copyright", "credits" or "license" for more information.
> > > > >>> int('123\0')
> > > > Traceback (most recent call last):
> > > > File "", line 1, in
> > > > ValueError: null byte in argument for int()
> > > > >>> int('123\0', 10)
> > > > Traceback (most recent call last):
> > > > File "", line 1, in
> > > > ValueError: invalid literal for int() with base 10: '123\x00'
> > > > >>> long('123\0')
> > > > Traceback (most recent call last):
> > > > File "", line 1, in
> > > > ValueError: null byte in argument for long()
> > > > >>> long('123\0', 10)
> > > > 123L
> > > > >>>
> > > >
> > > > --
> > > > --Guido van Rossum (h
Re: [Python-Dev] The bytes type
On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote: > I'm not keen on compromises in 3.0, but without specific proposals I > don't see why we're arguing. So, please, what specific thing(s) are > you proposing we do in 3.0? Please make a list of specifics rather > than attempting at specifying a general rule to match things that > could go into the list; you've tried the latter and I still don't know > what you want. I can't come up with a full list, as I don't know everything that's changed or is being planned to change. But here's some stuff I do know about: 1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys 2) For the bytes type, keep enough of an overlap with the current use of str-as-raw-bytes that common operations work with either one (so that I can, f.e. read from a socket or a file and process that data). Without seeing the details for how bytes is going to be implemented, it's hard to say exactly what this means. 3) Preferably continue to allow old syntax when adding new syntax (e.g. exception catching syntax). Alternatively, a completely reliable automated conversion script to convert the syntax would also be acceptable if not quite as convenient. Mainly I'd just like to see "allowing the ability to write code which is portable between 2.5 and 3.0" as an explicit goal of the python 3.0 release. I trust that if the developers agree upon that as being a goal, the right things would happen, whatever they may be for the specific change in question. James ___ 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] The bytes type
On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote: > I'm not keen on compromises in 3.0, but without specific proposals I > don't see why we're arguing. So, please, what specific thing(s) are > you proposing we do in 3.0? Please make a list of specifics rather > than attempting at specifying a general rule to match things that > could go into the list; you've tried the latter and I still don't know > what you want. I can't come up with a full list, as I don't know everything that's changed or is being planned to change. But here's some stuff I do know about: 1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys 2) For the bytes type, keep enough of an overlap with the current use of str-as-raw-bytes that common operations work with either one (so that I can, f.e. read from a socket or a file and process that data). Without seeing the details for how bytes is going to be implemented, it's hard to say exactly what this means. 3) Preferably continue to allow old syntax when adding new syntax (e.g. exception catching syntax). Alternatively, a completely reliable automated conversion script to convert the syntax would also be acceptable if not quite as convenient. Mainly I'd just like to see "allowing the ability to write code which is portable between 2.5 and 3.0" as an explicit goal of the python 3.0 release. Actually, you missed the part where that is explicitly *not* the goal of Python 3.0. The main goal of Python 3.0 is explicitly to *break* the things you don't want broken. If you really not want them broken, Python 3.0 is a non-starter for you. You can basically stop worrying about it, and just never switch any of your Python 2.5 projects to Python 3.0. If you want to talk about an upgrade-path, you will have to accept that it means waiting for Python 2.6, and also that it means not using some features that will be removed, like the iter* methods of dicts. We (or at least some of us ;-) will do our best to provide a viable upgrade path from 2.6 even for complicated cases like the changing dict methods, but an upgrade path directly from 2.5-or-earlier to 3.0 is just plain impossible; you would have to change your code to avoid the things that will change in Python 3.0, which may lead to inefficient or complicated code. Python 3.0 is there to break backward compatibility, and do it cleanly. Any work done to ease the upgrade path should be done in 2.x (and separate tools), not 3.0. 3.0 is not a transitional release. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] The bytes type
On 1/16/07, James Y Knight <[EMAIL PROTECTED]> wrote: > On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote: > > I'm not keen on compromises in 3.0, but without specific proposals I > > don't see why we're arguing. So, please, what specific thing(s) are > > you proposing we do in 3.0? Please make a list of specifics rather > > than attempting at specifying a general rule to match things that > > could go into the list; you've tried the latter and I still don't know > > what you want. > > I can't come up with a full list, as I don't know everything that's > changed or is being planned to change. But here's some stuff I do > know about: > > 1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys > 2) For the bytes type, keep enough of an overlap with the current use > of str-as-raw-bytes that common operations work with either one (so > that I can, f.e. read from a socket or a file and process that data). > Without seeing the details for how bytes is going to be implemented, > it's hard to say exactly what this means. > 3) Preferably continue to allow old syntax when adding new syntax > (e.g. exception catching syntax). Alternatively, a completely > reliable automated conversion script to convert the syntax would also > be acceptable if not quite as convenient. > > Mainly I'd just like to see "allowing the ability to write code which > is portable between 2.5 and 3.0" as an explicit goal of the python > 3.0 release. I trust that if the developers agree upon that as being > a goal, the right things would happen, whatever they may be for the > specific change in question. Well, there's the crux. That is an explicit NON-goal. It always has been. It would add tons of constraints to Python 3000, and the net effect would be that everybody would continue to code in the 2.5 dialect, making the intended cleanup of the language ineffective. We are planning various other ways of providing conversion help. The most promising at this point is to make the following an explicit goal of Python 2.6 and Python 3000: make it possible to write code that runs under 2.6, and that, after automatic conversion using the 2to3 refactoring tool (see sandbox/2to3), runs under 3.0, *without* requiring manual patching up of the output of the refactoring tool. The latter clause makes it easy (if not trivial) for developers to maintain parallel versions. All you need is a sufficiently good test suite, so that you can automatically verify that the conversion result actually works as intended under 3.0. Since you'd have to do that testing anyway, there is not much of an added effort except for maintaining separate tarballs. There are still certain things you can't do, because the conversion tool doesn't handle them well (e.g. don't use variables named 'long' and don't create classes with methods named 'keys'); but I expect that the subset of 2.6 that you can use will be much larger using this approach than what you would get using the identical-source approach you are supporting. Oh, and the same approach will also work (with only a few more constraints) for 2.5 and even earlier versions. -- --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] Proposed 3.0 compatiblity module
Guido van Rossum wrote: > On 1/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [...] >> Outside of a compatibility module, we can decide to leave Py2.6 unmolested by >> Py3.0, so I can stop being cranky. > > If you're feeling cranky this early in the new year, maybe you should > look for reasons outside this list. :-) > What, we're supposed to reset our crankometers on January 1? Nobody told me that. > I'm all for striving for minimal impact. I don't think we can attain > zero impact. > > BTW, a possible alternative would be to strive for code that runs > under 2.x, and *after automatic transformation using the 2to3 tool* > runs under 3.x, *without mannual patch-up*. That's probably a much > lower bar, and it would still mean that developers wishing to maintain > code that works with both 2.x/3.x only need to maintain a single > version -- the other version could be automatically generated. > > Since you need to do a lot of testing anyways to make sure you haven't > accidentally broken compatibility, the effort would be roughly > equivalent to the "identical source" approach that people are > advocating so far, and it would probably lift some restrictions. > > For example, working around print becoming a function would mean no > use of print at all when using "identical source"; but that's a > transformation that the 2to3 tool can do trivially and perfectly, so > the "automatic conversion" approach would enable freely using print > statements. > > A mixture of the two approaches would perhaps work best. > I foresee that many people would be happy restricting their 2.X source slightly to ensure perfect translation into (working, no necessarily optimal) 3.0. Under those circumstances the 2to3 tool wouldn't necessarily have to translate all valid 2.X to 3.0. cranki-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com ___ 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-3000] dict.items as attributes [Was: The bytes type]
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? Is there a chance that this special case could be handled by an import hook in py 2.6? For example 2.6 could have an additional LOAD_ATTR_PY3 opcode that just handles the special cases before delegating to the normal LOAD_ATTR. It would be generated instead of LOAD_ATTR whenever >>> from __future__ import py3 was in effect. Supporting 2.5 (and 2.2) would be a bit harder, but I think the new exception syntax would already require a py3->py2 translator, and these three names still seem like a fairly simple transform. So long as the "real" source is kept in py3 format, autogenerating python 2 code shouldn't be much worse than autogenerating pyc files. -jJ ___ 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] Proposed 3.0 compatiblity module
At 08:52 PM 1/16/2007 +, Steve Holden wrote: >I foresee that many people would be happy restricting their 2.X source >slightly to ensure perfect translation into (working, no necessarily >optimal) 3.0. Under those circumstances the 2to3 tool wouldn't >necessarily have to translate all valid 2.X to 3.0. Actually, it would be several times more preferable to either have that restricted subset of code run on 3.0 without translation, or for translated code to still be usable in 2.X. I have often been in the habit of running test suites back-to-back on multiple versions of Python while doing test-driven development, so having a repeated translation step would interfere with that. Ideally, a translation should be necessary one time only -- in which case requiring manual cleanup steps isn't as big of a problem. The idea here being that, once 2.6 is widely-enough deployed that it can be assumed as a base for one's users, you can simply run the translator once, do any cleanup, and then have 3.0-clean code that also still runs for your installed base. That way, there's no chasm to leap; just a code cleanup. ___ 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] The bytes type
On Jan 16, 2007, at 2:35 PM, Guido van Rossum wrote: >> Mainly I'd just like to see "allowing the ability to write code which >> is portable between 2.5 and 3.0" as an explicit goal of the python >> 3.0 release. I trust that if the developers agree upon that as being >> a goal, the right things would happen, whatever they may be for the >> specific change in question. > > Well, there's the crux. That is an explicit NON-goal. It always has > been. It would add tons of constraints to Python 3000, and the net > effect would be that everybody would continue to code in the 2.5 > dialect, making the intended cleanup of the language ineffective. Okay. I think this is a mistake. 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. As I keep pointing out, the language cleanup doesn't have to be all at once: remove all the already-replaced features now, and deprecate a bunch more things for removal a few releases later. That'd allow transition to 3.0 to occur during the time when people have to write in a 2.5-compatible dialect, anyhow. Otherwise, they'll be writing to 2.5-ONLY that won't run on 3.0 at all. > We are planning various other ways of providing conversion help. The > most promising at this point is to make the following an explicit goal > of Python 2.6 and Python 3000: make it possible to write code that > runs under 2.6, and that, after automatic conversion using the 2to3 > refactoring tool (see sandbox/2to3), runs under 3.0, *without* > requiring manual patching up of the output of the refactoring tool. Given that my ideal is not going to happen, I guess I'll have to be content with this. It WILL allow code to be converted incrementally to be compatible with Python 3.X (which is very important!), but, unfortunately, not for many years after Py3.0's release. (since the code can't be made portable until Python 2.6 has been out long enough for that to become a reasonable minimum requirement). But, a delayed migration strategy is certainly much much better than *no* migration strategy, so it's not all doom and gloom. But, anyhow, that's enough from me. My opinion has been made known, and disagreed with by (I think) all the prominent python developers. So now, I'll let it drop and go get some work done. Thanks for listening, James ___ 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] Proposed 3.0 compatiblity module
Phillip J. Eby wrote: > At 08:52 PM 1/16/2007 +, Steve Holden wrote: >> I foresee that many people would be happy restricting their 2.X source >> slightly to ensure perfect translation into (working, no necessarily >> optimal) 3.0. Under those circumstances the 2to3 tool wouldn't >> necessarily have to translate all valid 2.X to 3.0. > > Actually, it would be several times more preferable to either have that > restricted subset of code run on 3.0 without translation, or for > translated code to still be usable in 2.X. > > I have often been in the habit of running test suites back-to-back on > multiple versions of Python while doing test-driven development, so > having a repeated translation step would interfere with that. Ideally, > a translation should be necessary one time only -- in which case > requiring manual cleanup steps isn't as big of a problem. > > The idea here being that, once 2.6 is widely-enough deployed that it can > be assumed as a base for one's users, you can simply run the translator > once, do any cleanup, and then have 3.0-clean code that also still runs > for your installed base. > > That way, there's no chasm to leap; just a code cleanup. > That assumes that once you convert to 3.0 you are no longer interested in back-porting further functionality changes to your 2.X code, surely, or am I missing something? It seems to me preferable to allow repeated translation of 2.X code to working no-fixes-required 3.0. Then the cleanup step is required only when withdrawing support (or development) for 2.X and making the final translation. At that point it would be a one-time task. Or are you suggesting that users make the change to 3.0 and then backport changes to 2.X where necessary using the older semantics? In either case you end up with two different code bases. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com ___ 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-3000] dict.items as attributes [Was: The bytes type]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 16, 2007, at 5:04 PM, Jim Jewett 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? I know Guido is against attribute syntax for dict.items and friends, and I agree with him for reasons I can't quite put my finger on. But, would it be possible to support both the py3k way and the Python 2 way if you accepted attribute syntax for returning the view thingie? Couldn't that view thingie have an __call__ that returned the backward compatible list object? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRa1V9nEjvBPtnXfVAQIODQQAlCI4iykl93zKJeIW/3QuuOm4jCRrhffV BOkuu+mM4N/1Rqc2TCBHUIi995TkYo/6Wuzb7LrXweG5kLm2cdWTNm+aSgZq35HL XxPVP9qwCElKbZjl84udx/dbLdl9AfVasT2iVUiEVZN3Kq5j+UbyK+oaQdVjBc+5 j51iDW+vhcc= =Qq7c -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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
A.M. Kuchling schrieb:
> What about turning all references to obj.items into the equivalent
> bytecode for this:
>
> if isinstance(obj, dict): # XXX should this be 'type(obj) is dict'?
>if <2.x behaviour>: _temp = obj.items
>elif <3.x behaviour>: _temp = obj.iteritems
> else:
>_temp = obj.items
>
> Ugly; very ugly.
This would "work", I think, although I'd rather add a tp_getattr3 slot
to types, as somebody else proposed: getattr3 would default to getattr
if not defined, and would look up iteritems when asked for iter on dict
objects.
It would still "suffer" from the cross-module issue:
# a.py
from __future__ import items_is_iterator
def f(d):
return d.items
# b.py
import a
d = d{}
print a.f(d)()
For compatibility with 2.x, a.f should really return a bound
method that returns lists; for compatibility with 3.x, it will return
a method that produces an iterator.
Of course, one might say "don't do that, then".
Regards,
Martin
___
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] Proposed 3.0 compatiblity module
On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 08:52 PM 1/16/2007 +, Steve Holden wrote: > >I foresee that many people would be happy restricting their 2.X source > >slightly to ensure perfect translation into (working, no necessarily > >optimal) 3.0. Under those circumstances the 2to3 tool wouldn't > >necessarily have to translate all valid 2.X to 3.0. > > Actually, it would be several times more preferable to either have that > restricted subset of code run on 3.0 without translation, or for translated > code to still be usable in 2.X. > > I have often been in the habit of running test suites back-to-back on > multiple versions of Python while doing test-driven development, so having > a repeated translation step would interfere with that. Ideally, a > translation should be necessary one time only -- in which case requiring > manual cleanup steps isn't as big of a problem. > > The idea here being that, once 2.6 is widely-enough deployed that it can be > assumed as a base for one's users, you can simply run the translator once, > do any cleanup, and then have 3.0-clean code that also still runs for your > installed base. > > That way, there's no chasm to leap; just a code cleanup. I understand; I would rather have that too, everything else being the same. But everything else wouldn't be the same -- it would place many more restrictions on 3.0, and the common subset would still be much smaller. For me personally, the weight of the added restrictions to 3.0 is the killer. -- --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] Proposed 3.0 compatiblity module
At 03:18 PM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > The idea here being that, once 2.6 is widely-enough deployed that it can be > > assumed as a base for one's users, you can simply run the translator once, > > do any cleanup, and then have 3.0-clean code that also still runs for your > > installed base. > > > > That way, there's no chasm to leap; just a code cleanup. > >I understand; I would rather have that too, everything else being the >same. But everything else wouldn't be the same -- it would place many >more restrictions on 3.0, and the common subset would still be much >smaller. For me personally, the weight of the added restrictions to >3.0 is the killer. I don't understand; how would adding features to 2.6 restrict what you could add to 3.0? ___ 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] Proposed 3.0 compatiblity module
On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 03:18 PM 1/16/2007 -0800, Guido van Rossum wrote: > >On 1/16/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > The idea here being that, once 2.6 is widely-enough deployed that it can > > > be > > > assumed as a base for one's users, you can simply run the translator once, > > > do any cleanup, and then have 3.0-clean code that also still runs for your > > > installed base. > > > > > > That way, there's no chasm to leap; just a code cleanup. > > > >I understand; I would rather have that too, everything else being the > >same. But everything else wouldn't be the same -- it would place many > >more restrictions on 3.0, and the common subset would still be much > >smaller. For me personally, the weight of the added restrictions to > >3.0 is the killer. > > I don't understand; how would adding features to 2.6 restrict what you > could add to 3.0? Oh, as long as we're talking adding features to 2.6 I'm fine. I thought you were proposing changes to the plans for 3.0, as in your proposal" regarding the dict view API. -- --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] Proposed 3.0 compatiblity module
At 10:23 PM 1/16/2007 +, Steve Holden wrote: >Phillip J. Eby wrote: >>At 08:52 PM 1/16/2007 +, Steve Holden wrote: >>>I foresee that many people would be happy restricting their 2.X source >>>slightly to ensure perfect translation into (working, no necessarily >>>optimal) 3.0. Under those circumstances the 2to3 tool wouldn't >>>necessarily have to translate all valid 2.X to 3.0. >>Actually, it would be several times more preferable to either have that >>restricted subset of code run on 3.0 without translation, or for >>translated code to still be usable in 2.X. >>I have often been in the habit of running test suites back-to-back on >>multiple versions of Python while doing test-driven development, so >>having a repeated translation step would interfere with that. Ideally, a >>translation should be necessary one time only -- in which case requiring >>manual cleanup steps isn't as big of a problem. >>The idea here being that, once 2.6 is widely-enough deployed that it can >>be assumed as a base for one's users, you can simply run the translator >>once, do any cleanup, and then have 3.0-clean code that also still runs >>for your installed base. >>That way, there's no chasm to leap; just a code cleanup. >That assumes that once you convert to 3.0 you are no longer interested in >back-porting further functionality changes to your 2.X code, surely, or am >I missing something? I'm saying that the 3.0 code would have to be usable in 2.x. That is, any new features added to 3.0 need to be backported to a 2.x release. For example, a "from __future__ import print" would need to be added to 2.6 to allow the use of print-as-function syntax. Otherwise, there is no way to write code that works in 2.x *and* 3.x, because print is a reserved word in 2.x, and can't be a statement in 3.x. >It seems to me preferable to allow repeated translation of 2.X code to >working no-fixes-required 3.0. Then the cleanup step is required only when >withdrawing support (or development) for 2.X and making the final >translation. At that point it would be a one-time task. > >Or are you suggesting that users make the change to 3.0 and then backport >changes to 2.X where necessary using the older semantics? In either case >you end up with two different code bases. No, I'm saying one code base that runs on both. The main difference between me and James Knight on this is that I'm saying 2.6 or 2.7, he wanted 2.5. I agree with Guido that a 2.5 backward target is unreasonably restrictive for 3.0. ___ 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-3000] Warning for 2.6 and greater
Martin v. Löwis wrote:
> It would still "suffer" from the cross-module issue:
>
> # a.py
> from __future__ import items_is_iterator
> def f(d):
> return d.items
> # b.py
> import a
> d = {}
> print a.f(d)
>
> For compatibility with 2.x, a.f should really return a bound
> method that returns lists; for compatibility with 3.x, it will return
> a method that produces an iterator.
>
> Of course, one might say "don't do that, then".
>
This seems like a perfectly reasonable thing to say. If I am writing
something for 2.X and want to use a 3.X feature switch, then I am
responsible for maintaining the external API, be it the 2.X version of
d.items if that is what is expected by the user.
Your complaint only works if a.f was pre-defined to return a list, which
the developer of "a" would know about when he decided to flip on
items_is_iterator. As a part of that refactoring, he would patch up the
return to be list(d.items) to maintain the API he has already defined.
It is not clear by your example that "b" wasn't in fact expecting to get
an iterator, which is now a great deal simpler thanks to the future
statement.
My point is simply that this argument doesn't work unless you assume the
developer of "a" has failed to do his job (which is to maintain the
external API by also testing the external API).
BTW, I patched your code because both versions you have presented didn't
actually work.
--
Scott Dial
[EMAIL PROTECTED]
[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] Proposed 3.0 compatiblity module
At 03:47 PM 1/16/2007 -0800, Guido van Rossum wrote: >Oh, as long as we're talking adding features to 2.6 I'm fine. I >thought you were proposing changes to the plans for 3.0, as in your >proposal" regarding the dict view API. Nah, that was a side tangent, combined with a partial lack of understanding of how the view thing was supposed to work. Having to wrap 'em with list() calls is annoying but doable. I was just throwing out an idea I didn't realize had already been shot down. ___ 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 _Py prefix to names in 2.5.1?
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. Assuming there is no dissent, does some budding Python developer want to take on a patch? This should be pretty straightforward. Feel free to mail me off list if you prefer. Cheers, 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
