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
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
people
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
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
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
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
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 mainly just to
On Mon, Jan 11, 2010 at 10:06, Martin v. Löwis mar...@v.loewis.de 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
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 by
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
don't
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 in
On Mon, Jan 11, 2010 at 11:37, Walter Dörwald wal...@livinglogic.de 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 12:12, Lennart Regebro rege...@gmail.com 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 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
codec to do that.
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
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 Mon, Jan 11, 2010 at 13:29, Walter Dörwald wal...@livinglogic.de 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.
On 11.01.10 13:45, Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 13:29, Walter Dörwald wal...@livinglogic.de 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.
On Mon, Jan 11, 2010 at 14:21, Walter Dörwald wal...@livinglogic.de 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
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 18:16, Martin v. Löwis mar...@v.loewis.de 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
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 11:37, Walter Dörwald wal...@livinglogic.de 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
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 10:06, Martin v. Löwis mar...@v.loewis.de
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
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')
On Mon, Jan 11, 2010 at 18:46, MRAB pyt...@mrabarnett.plus.com 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
On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
victor.stin...@haypocalc.com 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
Olemis Lang wrote:
On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
victor.stin...@haypocalc.com 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,
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 the
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 m...@egenix.com wrote:
Olemis Lang wrote:
On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Hi,
Builtin open() function is
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
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
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,
+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
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 haven't
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. Actually
David Lyon david.lyon at 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
David Lyon david.lyon at 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
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 logic
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
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 to
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 just
Andrew Bennetts andrew at 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
On Sun, Jan 10, 2010 at 14:25, Brett Cannon br...@python.org 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
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw ba...@python.org 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
2010/1/11 Jack Diederich jackd...@gmail.com:
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw ba...@python.org 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:
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw ba...@python.org 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
On Mon, Jan 11, 2010 at 23:55, Guido van Rossum gu...@python.org 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
On Tue, Jan 12, 2010 at 01:11, Barry Warsaw ba...@python.org 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
On Tue, Jan 12, 2010 at 01:07, Andrew Bennetts and...@bemusement.org 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
49 matches
Mail list logo
