Re: [Python-Dev] PEP 3000 and iterators
On 9/11/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: James Y Knight wrote: Just to be clear, I do not want nor expect this. I wish to be able to specifically modify code with full knowledge of what has changed in Py3.0 such that it will work with both Py2.X and Py3.0. If you want these things to work in 2.x and 3.0, just use iter(dict_instance) and list(dict_instance) as appropriate. Simpler still, just use di.keys() but make sure you're only using the result to iterate over once without modifying the dict's key set. Or if you *have* to avoid creating a list in Py2.x, write your code to iterate over the dict itself even if you'd like itervalues or iteritems; you can always get the value explicitly by indexing the dict. IOW use the API whose name will remain but don't rely on the functionality that will change. -- --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] PEP 3000 and iterators
On 9/10/05, James Y Knight [EMAIL PROTECTED] wrote: No, that cannot work. However, there is a very obvious and trivial solution. Do not remove dict.iteritems in Py 3.0. Py2.X programs wishing forward compat can avoid dict.items and use instead dict.iteritems. In Py3.0, dict.items becomes a synonym for dict.iteritems and programs that don't care about compat with 2.X can just use dict.items from then on. And everybody can be happy. A small number of redundant methods is a small price to pay for compatibility. But it breaks the desire to keep the Python 3.0 language clean from deprecated features. Given that I don't expect there will be much compatibility *anyway*, I don't want to promise this. I expect that we'll have to write a source-level translator -- which could replace all iteritems() calls to items(), for example. Such a source-level translator may not be able to reach perfection, but it should take care of the tedious tasks and leave the rest up to manual polishing. This doesn't mean that there's no point in trying to introduce certain 3.0 features in 2.x; it's always good to have early experience with a new feature, and in some cases it *will* improve forward compatibility. But just installing python3.0 as python and expecting nothing will break is not a goal -- it would be too constraining. -- --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] PEP 3000 and iterators
On Sep 11, 2005, at 11:24 AM, Guido van Rossum wrote: But it breaks the desire to keep the Python 3.0 language clean from deprecated features. That is a nice goal, another nice goal is to not unnecessarily break things. But just installing python3.0 as python and expecting nothing will break is not a goal -- it would be too constraining. Just to be clear, I do not want nor expect this. I wish to be able to specifically modify code with full knowledge of what has changed in Py3.0 such that it will work with both Py2.X and Py3.0. And, now is probably not really the right time to discuss such minor issues as whether to keep iteritems in Py3.0, but, if it is kept, it becomes easier to write such code. It is of course still possible to write compatible code without keeping iteritems, you just have to replace all the method calls with a function wrapper which calls one of items or iteritems depending on the version. 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] PEP 3000 and iterators
James Y Knight wrote: Just to be clear, I do not want nor expect this. I wish to be able to specifically modify code with full knowledge of what has changed in Py3.0 such that it will work with both Py2.X and Py3.0. If you want these things to work in 2.x and 3.0, just use iter(dict_instance) and list(dict_instance) as appropriate. 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] PEP 3000 and iterators
Nick Coghlan wrote: However, such a future_builtins module could still include modified versions of those standard objects - such future-proofed code would simply still need to deal with the fact that other libraries or clients may pass in the old-style components (e.g. just as unicode-aware code needs to deal with the fact that other libraries or clients may produce 8-bit strings rather than unicode text). And be careful not to pass them to old code which expects the traditional versions of these objects. Sounds far too tricky and error-prone to be worth the trouble to me. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On 9/9/05, Guido van Rossum [EMAIL PROTECTED] wrote: For the builtins, it would actually be possible to do this by simply importing an alternate builtins module. Something like from future_builtins import min, max, zip, range Yes. A straightforward solution... For methods on standard objects like dicts it's not really possible either way; the type of a dict is determined by the module containing the code creating it, not the module containing the code using it. I had that in mind when I wrote my post; changing types is not the way, that will not work. That is why I proposed __future__ (I really do not know very well the implementation details of that feature) because I think the parser/compiler can (magically) make the replacements, e.g. dict.items - dict.iteritems for Py2.X series in codes *using* dicts . Do you think something like this could be implemented in a safer way? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On Sep 10, 2005, at 6:07 PM, Lisandro Dalcin wrote: I had that in mind when I wrote my post; changing types is not the way, that will not work. That is why I proposed __future__ (I really do not know very well the implementation details of that feature) because I think the parser/compiler can (magically) make the replacements, e.g. dict.items - dict.iteritems for Py2.X series in codes *using* dicts . Do you think something like this could be implemented in a safer way? No, that cannot work. However, there is a very obvious and trivial solution. Do not remove dict.iteritems in Py 3.0. Py2.X programs wishing forward compat can avoid dict.items and use instead dict.iteritems. In Py3.0, dict.items becomes a synonym for dict.iteritems and programs that don't care about compat with 2.X can just use dict.items from then on. And everybody can be happy. A small number of redundant methods is a small price to pay for compatibility. 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] PEP 3000 and iterators
On 9/9/05, Lisandro Dalcin [EMAIL PROTECTED] wrote: PEP 3000 says (http://www.python.org/peps/pep-3000.html) : Core language - Return iterators instead of lists where appropriate for atomic type methods (e.g. dict.keys(), dict.values(), dict.items(), etc.) Built-in Namespace - Make built-ins return an iterator where appropriate (e.g. range(), zip(), etc.) - Relevant functions should consume iterators (e.g. min(), max()) To be removed: - xrange(): use range() instead [1] Any possibility to add one (or more) __future__ statement to implicitly get this behavior? Any suggestion about naming? For the builtins, it would actually be possible to do this by simply importing an alternate builtins module. Something like from future_builtins import min, max, zip, range For methods on standard objects like dicts it's not really possible either way; the type of a dict is determined by the module containing the code creating it, not the module containing the code using it. -- --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
