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.
>
>
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 a
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_instanc
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
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 become
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
On 9/10/05, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > 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
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
Guido van Rossum wrote:
> On 9/9/05, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
>>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 alt
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
> -
10 matches
Mail list logo
