Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 confidence in the direction that the BDFL and python-dev as a group has chosen. Now I could be wrong and there could actually be a large number of active contributors who want to keep the 2.x series going, but based on the discussion that occurred the last time this came up I believe the guys who are keeping Python running are ready to move on. I think this is mostly just a branding issue. Once the folks who have historically kept Python 2 running really *do* move on, there will be other folks who will step up and become maintainers out of necessity: those stuck on old platforms, permanent stragglers, people who for whatever reason actually like Python 2 better, etc. It's just going to happen, there's really nothing anybody can do about it. I don't think there's anything wrong with this. If such a group of folks wants to get together and create another Python 2.X release, there's nothing stopping them from doing so except the above branding declaration. I'd personally not close the door on allowing these folks to call such an effort "Python 2". - C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 who want to spend the time). I think *that* would give a very bad impression of Python. Depending whom you deal with, the new feature you want may or may not get added to the code base. Contributors would feel even more stranded than they do now, where it may take several years to get a patch reviewed, as you then could submit a patch, and pray that a comitter reviews it who believes in future 2.x releases. The point of setting policies is that it gives every user (contributors, committers, and "end-user" developers) a reliable foundation for expectations. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
after all these years, some people still run AmigaOS. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> 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 that? It is a fact: 2.x will not be supported, in some future. Should we lie to users? > After the Python 2.7 release, the focus of Python development > will be on Python 3. There will continue to be maintainance > releases of Python 2.x. It shouldn't say that, because it wouldn't be true. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> 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 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. This has nothing to do with pushing 3.x, but all with managing available manpower and still providing quality software. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 this discussion by changing that line in future releases to be: "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 get the pointless discussion over with. The current Python core team don't want to make a 2.8, so that will not happen. Someone else might, but as Chris points out, they won't step up until they have to, which is probably at least two years from now. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> "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 get the pointless discussion over with. 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 contributors :-). I like the wording as it is (although I find the promise of five years of bug fix releases a bit too strong). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 contributors :-). Hm. Yeah. That's right of course. I started with saying "official", but then I thought "official according to who?". :) So I changed it to mentioning PSF, but that doesn't work either. I guess the current writing as as good as it gets, unless we change "scheduled" to "expected" or something. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 people who want to spend the time). Note that there's also the time it takes to make a release (usually involving at least one beta release), plus the possibility of introducing bugs while adding new features or even while fixing agreed bugs. All of this takes time in addition to the time people might want to invest in 'real' development on the 2.x trunk. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 agree with. Well, I think it's *worse* than that, and I don't think you really mean "DOA", anyway. (Feel free to correct me, of course.) The problem I see with backporting lots of stuff, and/or adding new features that aren't in 3.0, to 2.x is that it will make 2.x even cruftier, when it was already crufty enough that Guido (and almost all of python-dev) bit the bullet and said "backward compatibility is no excuse for keeping something in 3.0". That surely means that a lot of python-dev denizens will declare non-support 2.x for x > 7. It's not going to be the gradual migration we've seen over the past few months as active people start to spend more and more time on 3 vs. 2; it will be a watershed. Especially if these are new features merged from outside that the "small active segment" doesn't know anything about. From the users' point of view, that amounts to a *fork*, even if it's internal and "friendly". > I think we have got to the heart of our disagreement. Assume that > some superhuman takes all the backwards compatible goodies from 3.x > and merges them into 2.x. Isn't that a bit ridiculous? I just don't see any evidence that anything like that is going to happen. Worse, if we *assume* it will happen, I don't see any way to assess whether (1) Python 3 goes belly up, (2) there's an effective fork confusing the users and draining the energy of python-dev, or (3) everybody goes "wow!" because it's so cool that everybody wants to keep maintaining an extra 3 branches indefinitely. My opinion is that given the clear direction the "small active segment" is going, telling the users anything but what Brett proposed is disinformation. > 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. It's not for Python 3, which you, I, and I'm pretty sure Brett-in-his- heart-of-hearts agree can take care of itself because it is *better* than Python 2. It's for Python, and for the Python community. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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
>> TextIOWrapper. IMHO the best approach would to the implement a *real*
>> codec named "BOM" (or "sniff"). This doesn't require *any* changes to
>> the IO library. It could even be developed as a standalone project and
>> published in the Cheeseshop.
>
> Why not, this is another solution to the point (2) (Check for a BOM while
> reading or detect it before?). Which encoding would be used if there is not
> BOM? UTF-8 sounds like a good choice.
UTF-8 might be a good choice, are the failback could be specified in the
encoding name, i.e.
open("file.txt", encoding="BOM-UTF-8")
falls back to UTF-8, if there's no BOM at the start.
This could be implemented via a custom codec search function (see
http://docs.python.org/library/codecs.html#codecs.register for more info).
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 with encoding special information in the codecs names? codec='BOM else UTF-16 else locale'? :-) BOM is not a locale, and should not be a locale. Having a locale called BOM is wrong per se. It should either be default to look for a BOM when codec=None, or a special parameter. If none of these are desired, then we need a special function that takes a filename or file handle, and looks for a BOM and returns the codec found or None. But I find that much less natural and obvious than checking the BOM when codec=None. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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. > > Yes - however, Victor currently apparently *doesn't* want it to be the > default, but wants the user to specify encoding="BOM". If so, it isn't > the default, and it is easy to implement as a codec. > >>> FWIW, I agree with Walter that if it is provided through the encoding= >>> argument, it should be a codec. If it is built into the open function >>> (for whatever reason), it must be provided by some other parameter. >> >> Why not simply encoding=None? > > I don't mind. Please re-read Walter's message - it only said that > *if* this is activated through encoding="BOM", *then* it must be > a codec, and could be on PyPI. I don't think Walter was talking about > the case "it is not activated through encoding='BOM'" *at all*. 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. >> The default value should provide the most useful >> behaviour possible. Forcing users to choose between two different >> autodetection >> strategies (encoding=None and another one) is a little insane IMO. And encoding="mbcs" is a third option on Windows. > That wouldn't disturb me much. There are a lot of things in that area > that are a little insane, starting with Microsoft Windows :-) ;) Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 indefinite != infinite). This was shortly after > him proposing that perhaps we shouldn't make a 2.7 release at all, and > stop at 2.6. IMO, the focus for Python 2.7 (and beyond) must be on helping people transition to Python 3. That should be the reason why a 2.7 is released and, what should dictate whether a 2.8 is necessary. Maybe everything people need (except manpower and round tuits) is already there. I was pleasantly surprised to find that Distribute supports automatically running 2to3 at install time for Python packages. This allowed me to "port" a recent (admittedly small) package to Python 3 by making it "python2.6 -3" clean and adding a couple of attributes to my setup.py[1]. I don't know how widely that feature's known, but I think it's *huge*, and exactly what we need to be doing. The more we can make it easy for people to port their Python 2 code to Python 3, and to support that with one code base, the quicker we'll get to a predominantly Python 3 world. So the question we should be asking is: what's missing from Python 2.7 to help with this transition? If we can't get it into 2.7, then why, and would pushing it back to 2.8 help at all? -Barry [1] modulo a bug in Distribute that caused doctest in separate files to not be used when running under Python 3. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
> 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 reusable, but making it a codec seems to be a weird hack to me. And how would you reuse it if it was a codec? A reusable autodetect feature would be useable to detect what codec it is. A autodetect codec would not be useful for that, as it would simply just decode. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 autodetect feature is not a codec. Sure it should be reusable,
> but making it a codec seems to be a weird hack to me.
I think we already had this discussion two years ago in the context of
XML decoding ;):
http://mail.python.org/pipermail/python-dev/2007-November/075138.html
> And how would
> you reuse it if it was a codec? A reusable autodetect feature would be
> useable to detect what codec it is. A autodetect codec would not be
> useful for that, as it would simply just decode.
I have implemented an XML codec (as part of XIST:
http://pypi.python.org/pypi/ll-xist), that can do that:
>>> from ll import xml_codec
>>> import codecs
>>> c = codecs.getincrementaldecoder("xml")()
>>> c.encoding
>>> c.decode(">> c.encoding
>>> c.decode(" version='1.0'")
u''
>>> c.encoding
>>> c.decode(" encoding='iso-8859-1'?>")
u""
>>> c.encoding
'iso-8859-1'
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 so. This functionality just *isn't* a codec - there is no encoding. Instead, it is an algorithm for *detecting* an encoding." The conclusion was that a method do autodetect encodings would be good. I think the same conclusion applies here. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 consider it a weird hack. So the BOM codec should raise a UnicodeDecodeError if there is no BOM? Because that's what it would have to do, in that case, because it can't fall back on anything, it has to handle and implement all encodings that have a BOM. And is it then actually very useful? You would have to do a try/except first with encoding='BOM' and then encoding=None to get the fallback to the standard. I must say that I find this whole thing pretty obvious. 'BOM' is not an encoding. Either there should be a method to get the encoding from the BOM, returning None of there isn't one, or open() should look at the BOM when you pass in encoding=None. Or both. 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') has any benefit over this, covers any extra usecase and is clearer in any way. Instead it adds something confusing: An encoding that isn't an encoding. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 else? How far will we go with encoding special information in the codecs names? codec='BOM else UTF-16 else locale'? :-) BOM is not a locale, and should not be a locale. Having a locale called BOM is wrong per se. It should either be default to look for a BOM when codec=None, or a special parameter. If none of these are desired, then we need a special function that takes a filename or file handle, and looks for a BOM and returns the codec found or None. But I find that much less natural and obvious than checking the BOM when codec=None. Or pass a function that accepts a byte stream or the first few bytes and returns the encoding and any unused bytes (because the byte stream might not be seekable)? def guess_encoding(byte_stream): data = byte_stream.read(2) if data == b"\xFE\xFF": return "UTF-16BE", b"" return "UTF-8", data text_file = open(filename, encoding=guess_encoding) ... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 and his contributors :-). Hm. Yeah. That's right of course. I started with saying "official", but then I thought "official according to who?". :) "Official" is whatever the BDFL says it is! :-) So I changed it to mentioning PSF, but that doesn't work either. I guess the current writing as as good as it gets, unless we change "scheduled" to "expected" or something. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
> 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') has any benefit over this, Well, it would have the advantage that Walter pointed out: you can implement it independent of the open() implementation, and even provide it in older versions of Python. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
> 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 whereas the
>> BOM should be "ignored".
>>
[...]
>
I had similar issues too (please read below ;o) ...
On Thu, Jan 7, 2010 at 7:52 PM, Guido van Rossum wrote:
> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
> talk. And for the other two, perhaps it would make more sense to have
> a separate encoding-guessing function that takes a binary stream and
> returns a text stream wrapping it with the proper encoding?
>
About guessing the encoding, I experienced this issue while I was
developing a Trac plugin. What I was doing is as follows :
- I guessed the MIME type + charset encoding using Trac MIME API (it
was a CSV file encoded using UTF-16)
- I read the file using `open`
- Then wrapped the file using `codecs.EncodedFile`
- Then used `csv.reader`
... and still get the BOM in the first value of the first row in the CSV file.
{{{
#!python
>>> mimetype
'utf-16-le'
>>> ef = EncodedFile(f, 'utf-8', mimetype)
}}}
IMO I think I am +1 for leaving `open` just like it is, and use module
`codecs` to deal with encodings, but I am strongly -1 for returning
the BOM while using `EncodedFile` (mainly because encoding is
explicitly supplied in ;o)
> --Guido
>
CMIIW anyway ...
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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() returns also the BOM whereas the
>>> BOM should be "ignored".
>>>
> [...]
>>
>
> I had similar issues too (please read below ;o) ...
>
> On Thu, Jan 7, 2010 at 7:52 PM, Guido van Rossum wrote:
>> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
>> talk. And for the other two, perhaps it would make more sense to have
>> a separate encoding-guessing function that takes a binary stream and
>> returns a text stream wrapping it with the proper encoding?
>>
>
> About guessing the encoding, I experienced this issue while I was
> developing a Trac plugin. What I was doing is as follows :
>
> - I guessed the MIME type + charset encoding using Trac MIME API (it
> was a CSV file encoded using UTF-16)
> - I read the file using `open`
> - Then wrapped the file using `codecs.EncodedFile`
> - Then used `csv.reader`
>
> ... and still get the BOM in the first value of the first row in the CSV file.
You didn't say, but I presume that the charset guessing logic
returned either 'utf-16-le' or 'utf-16-be' - those encodings don't
remove the leading BOM. The 'utf-16' codec will remove the BOM.
> {{{
> #!python
>
mimetype
> 'utf-16-le'
ef = EncodedFile(f, 'utf-8', mimetype)
> }}}
Same here: the UTF-8 codec will not remove the BOM, you have
to use the 'utf-8-sig' codec for that.
> IMO I think I am +1 for leaving `open` just like it is, and use module
> `codecs` to deal with encodings, but I am strongly -1 for returning
> the BOM while using `EncodedFile` (mainly because encoding is
> explicitly supplied in ;o)
Note that EncodedFile() doesn't do any fancy BOM detection or
filtering. This is the job of the codecs.
Also note that BOM removal is only valid at the beginning of
a file. All subsequent BOM-bytes have to be read as-is (they
map to a zero-width non-breaking space) - without removing them.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 11 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Data descriptor doc/implementation inconsistency
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
> ability to "cache" a value in the instance dictionary.
>
> [1] http://docs.python.org/reference/datamodel#invoking-descriptors
I would call it a documentation bug: by leaving out the __get__ you're
telling Python to override *just* the setting of the attribute, while
still using the normal lookup process for retrieving the attribute (i.e.
allowing the attribute to be shadowed in the instance dictionary).
Adding a "print('Descriptor Invoked')" to the __set__ method in your
example:
>>> x = X()
>>> print(x.attr)
<__main__.Descr object at 0x7f283b51ac50>
>>> x.attr = 42
Descriptor invoked
>>> print(x.attr)
42
>>> x.attr = 6*9
Descriptor invoked
>>> print(x.attr)
54
Note that the behaviour here is still different from that of a data
descriptor: with a data descriptor, once it gets shadowed in the
instance dictionary, the descriptor is ignored *completely*. The only
way to get the descriptor involved again is to eliminate the shadowing.
The non-data descriptor with only __set__ is just choosing not to
override the attribute lookup process.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM
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 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 whereas
the
BOM should be "ignored".
>> [...]
>>>
>>
>> I had similar issues too (please read below ;o) ...
>>
>> On Thu, Jan 7, 2010 at 7:52 PM, Guido van Rossum wrote:
>>> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
>>> talk. And for the other two, perhaps it would make more sense to have
>>> a separate encoding-guessing function that takes a binary stream and
>>> returns a text stream wrapping it with the proper encoding?
>>>
>>
>> About guessing the encoding, I experienced this issue while I was
>> developing a Trac plugin. What I was doing is as follows :
>>
>> - I guessed the MIME type + charset encoding using Trac MIME API (it
>> was a CSV file encoded using UTF-16)
>> - I read the file using `open`
>> - Then wrapped the file using `codecs.EncodedFile`
>> - Then used `csv.reader`
>>
>> ... and still get the BOM in the first value of the first row in the CSV
>> file.
>
> You didn't say, but I presume that the charset guessing logic
> returned either 'utf-16-le' or 'utf-16-be'
Yes. In fact they return the full mimetype 'text/csv; charset=utf-16-le' ... ;o)
> - those encodings don't
> remove the leading BOM.
... and they should ?
> The 'utf-16' codec will remove the BOM.
>
In this particular case there's nothing I can do, I have to process
whatever charset is detected in the input ;o)
>> {{{
>> #!python
>>
> mimetype
>> 'utf-16-le'
> ef = EncodedFile(f, 'utf-8', mimetype)
>> }}}
>
> Same here: the UTF-8 codec will not remove the BOM, you have
> to use the 'utf-8-sig' codec for that.
>
>> IMO I think I am +1 for leaving `open` just like it is, and use module
>> `codecs` to deal with encodings, but I am strongly -1 for returning
>> the BOM while using `EncodedFile` (mainly because encoding is
>> explicitly supplied in ;o)
>
> Note that EncodedFile() doesn't do any fancy BOM detection or
> filtering.
... directly.
> This is the job of the codecs.
>
OK ... to come back to the scope of the subject, in the general case,
I think that BOM (if any) should be handled by codecs, and therefore
indirectly by EncodedFile . If that's a explicit way of working with
encodings I'd prefer to use that wrapper explicitly in order to
(encode | decode) the file and let the codec detect whether there's a
BOM or not and «adjust» `tell`, `read` and everything else in that
wrapper (instead of `open`).
> Also note that BOM removal is only valid at the beginning of
> a file. All subsequent BOM-bytes have to be read as-is (they
> map to a zero-width non-breaking space) - without removing them.
>
;o)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Test cases for custom query (i.e report 9) ... PASS (1.0.0) -
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-gviz/rev/d276011e7297
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> 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 promoting it ever since, but it's taking up only slowly, partially because it has competition in the approaches "burn the bridges" (i.e. convert to 3.x once, and then have two code bases, or abandon 2.x), and "avoid 2to3" (i.e. try to write code that works in both 2.x and 3.x unmodified). > If we can't get it into 2.7, then > why, and would pushing it back to 2.8 help at all? I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing: a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had *always* dropped old versions before supporting new ones. b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to). c) whatever 2.7 does (except perhaps for the warnings), it won't be useful to applications, because they couldn't use it, anyway: they need to support 2.4 and 2.5, and it won't have any of the gimmicks people come up with for 2.7. Adding gimmicks to 2.7 might actually hurt porting: people may have to special-case 2.7 because their work-arounds for older versions may break in 2.7 (e.g. testing whether a name is *not* defined, when it becomes defined in 2.7), plus it gives them an incentive to not port yet until they can drop support for anything before 2.7. Inherently, 2.8 can't improve on that. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> 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 announcements. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Data descriptor doc/implementation inconsistency
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, the fix may break some programs relying on the ability to "cache" a value in the instance dictionary. [1] http://docs.python.org/reference/datamodel#invoking-descriptors [snip...] Note that the behaviour here is still different from that of a data descriptor: with a data descriptor, once it gets shadowed in the instance dictionary, the descriptor is ignored *completely*. The only way to get the descriptor involved again is to eliminate the shadowing. The non-data descriptor with only __set__ is just choosing not to override the attribute lookup process. Does that mean we need a third class of descriptors that are neither data descriptors nor non-data descriptors? What should we call them: really-not-data-descriptors? All the best, Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
+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 personally. Are there other experiences? --Guido On Mon, Jan 11, 2010 at 1:44 PM, "Martin v. Löwis" wrote: >> 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 announcements. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 even attempted to use it. Instead, the software would fall flat on its own when running the test suite in 3.x. IOW, I don't need 2.6 to tell me what might break when I can see 3.x actually breaking. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 as an end-developer I'd say that python 2.x series from a programming perspective is quite good. It doesn't need the addition of a lot of new features imho. So for me, I think too much time spent there would be not yield great benefits. > This has nothing to do with pushing 3.x, but all with managing > available manpower and still providing quality software. Well, we all know your work is super quality. :-) That's not being contested. However, Quality can be measured different ways and it can be assessed in different ways. Quality itself is a subjective thing. The point I'm only making is that if a piece of software doesn't have "new" things added over time, then users can get a reverse impression of a lack of quality. We've all seen where 'internal' quality can increase and user perceptions can decrease. It could be things like improved graphics and things readily apparent to the user. At the moment, I would say that the "internal" quality of the python 2.x series is super high. "external" quality issues such as the packaging dilemma give the user the opposite quality experience. But people are working on that as best they can elsewhere. I'll leave it at that. > 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. >From an ordinary (perphaps ignorant) user perspective there is nothing. Yes, we know if we actually will start programming then we will like it more. But my wishes to Santa Claus would be allow the free flow of PEPs for Python 3 packaging. Even encourage it. As an end developer, here's what I'd like from Santa in 2010 to get me to swap to python 3: * get all the packages on pypi tested for python 3 * put a web based package manager in python 3. This would perhaps be based around PIP (keep many people happy) and would look much like the built in web-console that you get with a $200 router. * Incorporate SCM based end-user software installs by adding to python3-stdlib the SCM support packages (cvs,bzr,svn,hg). This would *really* help in the scientific community. * put a web interface on distutils also so that we don't have to use a command line interface. (I want a pic of a smiley girl to great me when I build something - "Are you ready to build now Honey?"). ok - I joke. But the point is made. So, ok, maybe these things aren't about 'code' quality. But rather user experience. Things like these do count also as "quality" via the technical term "perception of quality". If the PEP process is as unblocked as the documentation implies, implying that anybody can contribute to Python 3. Then there shouldn't be any issue. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 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 is a huge improvement. And that's only a small part of the picture. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> 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 also on Python 3. And that depresses me to think about. I need Medusa ReportLab PyLucene Email Vobject Mutagen Pyglet Hachoir Win32 I'm on the mailing lists for a lot of these, and the only one that I know is thinking about Python 3 is Email. I'd expect Win32 and PIL to also be thinking about it, but I haven't heard anything. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 is a huge improvement. And > that's > only a small part of the picture. In no way could I disagree with you. Ascii works fine for us here - but I guess we're lucky. Just keep pushing python 3 and have a nice day.. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 slowly, partially because it has >competition in the approaches "burn the bridges" (i.e. convert to 3.x >once, and then have two code bases, or abandon 2.x), and "avoid 2to3" >(i.e. try to write code that works in both 2.x and 3.x unmodified). Interesting. The only reason I never used it before is because I didn't know about it. Am I alone? Maybe I'm projecting my own preferences, but it seems to me that supporting both Python 2 and 3 from the same code base would be a very powerful way to enable a large amount of existing code to support Python 3. I'm certainly going to do this from now on with all the libraries I maintain. I don't have any cycles to write code twice and I can't abandon Python 2 yet. I'm skeptical that code can work unmodified in both 2 and 3 without 2to3. 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: class Foo(metaclass=Meta): 2to3 made that pain go away. >I've done a fair bit of 3.x porting, and I'm firmly convinced that >2.x can do nothing: > >a) telling people that they have to move to 2.6 first actually > hurts migration, instead of helping, because it implies to them > that they have to drop old versions (e.g. 2.3.) - just because > they had *always* dropped old versions before supporting new ones. Is it just an implication, or is it reality? I have yet to try to support older versions of Python and also support Python 3. (The one package I've done this with so far only supports Python 2.6.) >b) IMO, people also don't gain much by first migrating to 2.6. > In principle, it gives them the opportunity to get py3k warnings. > However, I haven't heard a single positive report where these > warnings have actually helped people in porting. Yours is the > first report saying that you followed the official guideline, > but you didn't state whether doing so actually helped (or whether > you just ported to 2.6 because the guideline told you to). Python 2.6 has other useful features, which I want to take advantage of, so getting py3k warnings is a bonus. Running 'python2.6 -3 setup.py test' over my code did in fact help clean up a couple of problems. Seems like a good first step when considering Python 3 support to me. >c) whatever 2.7 does (except perhaps for the warnings), it won't > be useful to applications, because they couldn't use it, anyway: > they need to support 2.4 and 2.5, and it won't have any of the > gimmicks people come up with for 2.7. Adding gimmicks to 2.7 > might actually hurt porting: people may have to special-case > 2.7 because their work-arounds for older versions may break in 2.7 > (e.g. testing whether a name is *not* defined, when it becomes > defined in 2.7), plus it gives them an incentive to not port > yet until they can drop support for anything before 2.7. > >Inherently, 2.8 can't improve on that. I'm not so sure. Yes, as a package maintainer there are older versions to think about, but time moves on for everyone (hopefully :). By the time 2.8 is released, what will be the minimum version of Python provided by most OS vendors (where the majority of Python users probably get their 'python')? I guess some people will have to support everything from Python 2.3 to 2.8 but you're talking supporting something like a spread of 7 years of Python versions. What other platform do you support for 7 years? Even Ubuntu long term support (LTS) releases only live for 5 years and even then, newer Pythons are often back ported. Or if not, then who cares? You're not going to use a newer version of a library on an LTS anyway. I'm not necessarily saying that justifies a 2.8 release. I'm just asking how we can make it easier for people to port to Python 3. The automatic 2to3 has already made it easier for me to port one library to Python 3 because I barely had to even think about it. Maybe that's enough. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 me. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
"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 as hard to move to 2.8 (using the py3k backports not available in say 2.5) as it is to 3.x? 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. Then, when all of your dependencies (or viable alternatives to those dependencies) are available for 3.x, you'll have an easier transition if you can start from a 2.x with fewer differences in features. Fundamentally the more 2.x can converge on 3.x, the easier it will be for users to make the leap, because it will be a smaller leap. The longer the 2.x series lives, the more these newer 2.x versions like 2.7 and maybe even 2.8 will be available on common platforms for people to depend upon as minimum versions, which means that as time goes by they can depend on a version that's closer to 3.x. And so again, the leap becomes easier to make. So to me it's pretty clear that 2.8 *can* improve the transition path to 3.x. It may or may not be a worthwhile use of effort for python-dev to make 2.8, but that's different to saying it's inherently pointless. -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 think a 2.8 could make you much closer to 3.x. AFAICT, every possible way to ease transition to 3.x will already be in 2.7, or almost. But perhaps I'm lacking imagination. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] topics I plan to discuss at the language summit
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 to see how people are using the tracker, or how they want to be using it. For example, there are currently over 1500 open issues with no stage set, some of which seemingly haven't been read by anyone at all. Would a properly set stage field save issues from falling into a black hole? Food for thought: according to the last tracker summary, there are over 1000 open issues with a patch, and issues stay open an average of 700 days (median 450). Brian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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: > > class Foo(metaclass=Meta): > > 2to3 made that pain go away. [sidebar] 1) the metaclass fixer was a PITA to implement. 2) 95% of __metaclass__ definitions searchable via google code were of the "__metaclass__ = type" variety. The 2to3 patch exists only because of the few other uses. 3) 100% of the module level assignments in public projects were the "__metaclass__ = type" variety which is why there isn't a fixer for that. Also, a fixer would have been really, really ugly (munge every class definition in this module because there is a top level assignment). -Jack ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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: >> __metaclass__ = Meta >> >> and in Python 3 it's: >> >> class Foo(metaclass=Meta): >> >> 2to3 made that pain go away. > > [sidebar] > 1) the metaclass fixer was a PITA to implement. Does this make it any less useful, though? :) -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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:
>
> class Foo(metaclass=Meta):
>
> 2to3 made that pain go away.
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {})
class Foo(FooBase):
...
That should work in Python 2.X and 3.X.
I've got argparse running on Python 2.3-3.1, and the changes were
pretty easy. You can see them all in the revision here:
http://code.google.com/p/argparse/source/detail?r=12
I have aspirations of putting all of the tricks I learned up up on the
Wiki somewhere, but I just haven't had the time.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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. But I trust he has ported a lot more code to 3.x than I have > personally. Are there other experiences? It doesn't warn for that many of the unportable problems, but I'm not sure it can warn for them either. It's certainly helpful, just not very much. :) I think the biggest help was added in 2.6.2, and that's warning for old integer division. It will also warn for modules that aren't supported anymore, if I remember correctly, and that's often helpful. But it won't warn for real tricky problems, like binary vs text in strings, and I don't see how it can either. And, I just realized, it doesn't warn for you using cmp or __cmp__ either, and 2to3 won't fix that, so it should actually warn for it. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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 own distutils extensions, in practice, and they are not trivial. Distribute has simply done it for you. :) > I'm skeptical that code can work unmodified in both 2 and 3 without 2to3. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
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.x. When 2.7 was discussed several people agreed that 2.7 should include as much 3.x stuff as possible to ease transition. That turned out to not be very much, so I'm not sure there is more. :) Unless of course, 2.8 starts including more of the refactored libraries, but that's a very minor issue in porting, so it won't help much. To really help, it needs to start implement things that break backwards compatibility. That would be weird. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
