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
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
>>
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
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
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 compa
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
>
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 tha
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 crea
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
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 supp
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 g
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 lis
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
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 reaso
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 addi
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
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 wo
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
-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 again
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
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 2
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 hav
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
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 c
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 lis
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 understan
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 us
27 matches
Mail list logo
