On Tue, Jan 12, 2010 at 01:07, Andrew Bennetts wrote:
> But a hypothetical 2.8 would also give people a way to move closer to
> py3k without giving up on using all their 2.x-only dependencies. I
> think it's much more likely that libraries like Twisted can support 2.8
> in the near future than 3.
On Tue, Jan 12, 2010 at 01:11, Barry Warsaw wrote:
> Interesting. The only reason I never used it before is because I didn't know
> about it. Am I alone?
Maybe not, but the Distribute feature is there because IMO the
distutils feature by itself isn't particularily useful. You need to
write your
On Mon, Jan 11, 2010 at 23:55, Guido van Rossum wrote:
> +1 from me. (With the caveat that "time will tell" is definitely the
> ultimate answer. Plans may change unexpectedly, even though we don't
> expect them to.)
>
> PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
> helpful.
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw wrote:
> As an example, the one library I've already ported used a metaclass. I don't
> see any way to specify that the metaclass should be used in a portable way.
> In Python 2.6 it's:
>
> class Foo:
> __metaclass__ = Meta
>
> and in Python 3 it's
2010/1/11 Jack Diederich :
> On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw wrote:
>> As an example, the one library I've already ported used a metaclass. I don't
>> see any way to specify that the metaclass should be used in a portable way.
>> In Python 2.6 it's:
>>
>> class Foo:
>> __metaclas
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw wrote:
> As an example, the one library I've already ported used a metaclass. I don't
> see any way to specify that the metaclass should be used in a portable way.
> In Python 2.6 it's:
>
> class Foo:
> __metaclass__ = Meta
>
> and in Python 3 it's
On Sun, Jan 10, 2010 at 14:25, Brett Cannon wrote:
> * any changes needed to the issue tracker to help with the workflow? (stage
> field seems like a failed experiment and we now have several effective
> triage people who can help w/ guiding changes)
>
> -Brett
>
I think it would be interesting t
Andrew Bennetts bemusement.org> writes:
>
> But a hypothetical 2.8 would also give people a way to move closer to
> py3k without giving up on using all their 2.x-only dependencies. I
> think it's much more likely that libraries like Twisted can support 2.8
> in the near future than 3.x.
I don't
"Martin v. Löwis" wrote:
[...]
> I've done a fair bit of 3.x porting, and I'm firmly convinced that
> 2.x can do nothing:
[...]
> Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I
disagree with your conclusion. Maybe you assume that it's
On Jan 11, 2010, at 02:55 PM, Guido van Rossum wrote:
>PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
>helpful. But I trust he has ported a lot more code to 3.x than I have
>personally. Are there other experiences?
I've only done one small library so far, but it was helpful t
On Jan 11, 2010, at 10:42 PM, Martin v. Löwis wrote:
>Wrt. the distribute feature you've noticed: Python 3.0 already supports
>that in distutils. So from day one of Python 3.x, you could have used
>that approach for porting Python code. I had been promoting it ever
>since, but it's taking up only
Antoine writes:
> As someone who experiences the difference almost every day, I can say 3.x
> definitely has enough carrots for me. The simple fact that I will be able
> to
> raise exceptions with non-ASCII error messages without having to
> workaround a
> hopelessly broken conversion/reporting lo
> David Lyon preisshare.net> writes:
> >
> > > This has nothing to do with pushing 3.x, but all with managing
> > > available manpower and still providing quality software.
> >
> > Python 3.x needs more carrots.
I'd be happy to move UpLib to Python 3, when the various packages that I
need are a
David Lyon preisshare.net> writes:
>
> > This has nothing to do with pushing 3.x, but all with managing
> > available manpower and still providing quality software.
>
> Python 3.x needs more carrots.
As someone who experiences the difference almost every day, I can say 3.x
definitely has enough
Hi Martin,
> Of course, the less active fraction of Python contributors may not
> notice, since they just chose to not contribute (which, of course,
> is fine). However, asking me to work twice as much as I want to
> on the project to keep two branches alive is just unfair.
Totally true. Actuall
Guido van Rossum wrote:
> +1 from me. (With the caveat that "time will tell" is definitely the
> ultimate answer. Plans may change unexpectedly, even though we don't
> expect them to.)
>
> PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
> helpful.
That's really because I have
+1 from me. (With the caveat that "time will tell" is definitely the
ultimate answer. Plans may change unexpectedly, even though we don't
expect them to.)
PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
helpful. But I trust he has ported a lot more code to 3.x than I have
perso
On 11/01/2010 21:12, Nick Coghlan wrote:
Benjamin Peterson wrote:
> My question is: Is this a doc bug or a implementation bug? If the
former, it will be the description of a data descriptor much less
consistent, since it will require that a __get__ method be present,
too. If the latter, t
> So, it should say "Guido wants 2.7 to be the last main version of
> Python 2, so it probably will be. We promise to release bugfixes it
> for, like, ages".
>
> No need to be needlessly formal. :-D
That summarizes my understanding of what Guido said fairly well :-)
+1 for putting it into the an
> So the question we should be asking is: what's missing from Python
> 2.7 to help with this transition?
Wrt. the distribute feature you've noticed: Python 3.0 already supports
that in distutils. So from day one of Python 3.x, you could have used
that approach for porting Python code. I had been p
Probably one part of this is OT , but I think it could complement the
discussion ;o)
On Mon, Jan 11, 2010 at 3:44 PM, M.-A. Lemburg wrote:
> Olemis Lang wrote:
>>> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
>>> wrote:
Hi,
Builtin open() function is unable to open an UTF-16/32
Benjamin Peterson wrote:
> My question is: Is this a doc bug or a implementation bug? If the
> former, it will be the description of a data descriptor much less
> consistent, since it will require that a __get__ method be present,
> too. If the latter, the fix may break some programs relying on th
Olemis Lang wrote:
>> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
>> wrote:
>>> Hi,
>>>
>>> Builtin open() function is unable to open an UTF-16/32 file starting with a
>>> BOM if the encoding is not specified (raise an unicode error). For an UTF-8
>>> file starting with a BOM, read()/readline()
> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
> wrote:
>> Hi,
>>
>> Builtin open() function is unable to open an UTF-16/32 file starting with a
>> BOM if the encoding is not specified (raise an unicode error). For an UTF-8
>> file starting with a BOM, read()/readline() returns also the BOM wher
On Mon, Jan 11, 2010 at 18:46, MRAB wrote:
> "Official" is whatever the BDFL says it is! :-)
Heh, right.
So, it should say "Guido wants 2.7 to be the last main version of
Python 2, so it probably will be. We promise to release bugfixes it
for, like, ages".
No need to be needlessly formal. :-D
-
> I must say that I find this whole thing pretty obvious. 'BOM' is not
> an encoding.
That I certainly agree with.
> That covers all usecases, is easy and obvious. Either open(file=foo,
> encoding=None) or open(file, encoding=encoding_from_bom(file))
>
> I can't see that open(file, encoding='BOM
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis"
wrote:
I know you are just looking for a compromise, but this shouldn't be
it: the PSF has deliberately stayed out of the actual Python
engineering, so the release that Benjamin makes is not done by the
PSF (but by Benjamin
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 11:37, Walter Dörwald wrote:
UTF-8 might be a good choice
No, fallback if there is no BOM should be the local settings, just as
fallback is today if you don't specify a codec.
I mean, what if you want to look for a BOM but fall back to something
On Mon, Jan 11, 2010 at 18:16, "Martin v. Löwis" wrote:
>> But an autodetect feature is not a codec. Sure it should be reusable,
>> but making it a codec seems to be a weird hack to me.
>
> Well, the existing UTF-16 codec also is an autodetect feature (to
> detect the endianness), and I don't con
> But an autodetect feature is not a codec. Sure it should be reusable,
> but making it a codec seems to be a weird hack to me.
Well, the existing UTF-16 codec also is an autodetect feature (to
detect the endianness), and I don't consider it a weird hack.
Regards,
Martin
On Mon, Jan 11, 2010 at 14:21, Walter Dörwald wrote:
> I think we already had this discussion two years ago in the context of
> XML decoding ;):
Yup. Ans Martins answer then is my answer now:
"> So the code is good, if it is inside an XML parser, and it's bad if it
> is inside a codec?
Exactly
On 11.01.10 13:45, Lennart Regebro wrote:
> On Mon, Jan 11, 2010 at 13:29, Walter Dörwald wrote:
>> However if this autodetection feature is useful in other cases (no
>> matter how it's activated), it should be a codec, because as part of the
>> open() function it isn't reusable.
>
> But an auto
On Mon, Jan 11, 2010 at 13:29, Walter Dörwald wrote:
> However if this autodetection feature is useful in other cases (no
> matter how it's activated), it should be a codec, because as part of the
> open() function it isn't reusable.
But an autodetect feature is not a codec. Sure it should be reu
> However if this autodetection feature is useful in other cases (no
> matter how it's activated), it should be a codec, because as part of the
> open() function it isn't reusable.
It is reusable as part of io.TextIOWrapper, though.
Regards
Antoine.
___
On Jan 10, 2010, at 6:07 PM, Martin v. Löwis wrote:
> As for decisions: I don't think there was an official BDFL pronouncent,
> but I recall Guido posting a message close to that, proposing that 2.7
> will be a release that will see bug fix releases for an indefinite
> period of time (where indefi
On 10.01.10 00:40, "Martin v. Löwis" wrote:
>>> How does the requirement that it be implemented as a codec miss the
>>> point?
>>
>> If we want it to be the default, it must be able to fallback on the current
>> locale-based algorithm if no BOM is found. I don't think it would be easy
>> for a
>>
On Mon, Jan 11, 2010 at 12:12, Lennart Regebro wrote:
> BOM is not a locale, and should not be a locale. Having a locale
> called BOM is wrong per se.
D'oh! I mean codec here obviously.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_
On Mon, Jan 11, 2010 at 11:37, Walter Dörwald wrote:
> UTF-8 might be a good choice
No, fallback if there is no BOM should be the local settings, just as
fallback is today if you don't specify a codec.
I mean, what if you want to look for a BOM but fall back to something
else? How far will we go
On 09.01.10 14:38, Victor Stinner wrote:
> Le samedi 09 janvier 2010 12:18:33, Walter Dörwald a écrit :
>>> Good idea, I choosed open(filename, encoding="BOM").
>>
>> On the surface this looks like there's an encoding named "BOM", but
>> looking at your patch I found that the check is still done i
Neil Schemenauer writes:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benefits which I personally
> >
Neil Schemenauer, 11.01.2010 05:17:
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
[...] would it still be ok if I closed a 2.x feature request as
"won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis" wrote:
> I know you are just looking for a compromise, but this shouldn't be it:
> the PSF has deliberately stayed out of the actual Python engineering,
> so the release that Benjamin makes is not done by the PSF (but by
> Benjamin and his contribut
> "Python 2.7 is scheduled to be the last major version in the 2.x
> series released by the Python Software Foundation before it moves into
> 5 years of bugfix-only mode. "
>
> That doesn't exclude *others* making a Python 2.8 that could include
> all sorts of crazy features. :)
>
> This is mainl
This is what it says now:
"Python 2.7 is scheduled to be the last major version in the 2.x
series before it moves into 5 years of bugfix-only mode. "
And during this discussion it has been noted that others than the core
python team might pick up Python 2 and make releases. So maybe we can
and th
> I guess I have more confidence in Python 3 than you do. I don't see
> why Python 2.x needs to be artificially limited so that Python 3 can
> benefit.
Because it takes too much time. Too much of my time, but apparently
also too much of other people's time.
Of course, the less active fraction of
> I would guess over 99% of all Python code written doesn't run on
> Python 3. Given that, I think it is premature to close the door on
> new major versions of Python 2.x. Also, we as a project should be
> careful not to present the image that Python 2.x will not be
> supported in the future.
Why
after all these years, some people still run AmigaOS.
___
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
Neil Schemenauer wrote:
> On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
>> [...] would it still be ok if I closed a 2.x feature request as
>> "won't fix", or only committed the new feature to the 3.x branch?
>
> Yes. Non-bugfix development on 2.x would optional (i.e. done by
Brett Cannon wrote:
IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev
saying "Python 3 is the future, but we are keeping the old Python 2.x
around because we don't have *that* much faith in the future we have
laid out". That's poison to Python 3 by showing a lack of confide
49 matches
Mail list logo
