Re: [Python-Dev] email package status in 3.X
Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release.
Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment...
Declaring something to be a turd doesn't change the fact that it's a turd. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. That's not a problem, unless you drop the word "beta". And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as "experimental", and promised a phase of "disappointment". Why would you expect the Python world to react any differently?
Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think "half-baked" is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*?
I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
On 18/06/2010 18:22, lutz@rmi.net wrote:
Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release.
Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment...
Declaring something to be a turd doesn't change the fact that it's a turd.
Right - but *you're* the one calling it a turd, which is not a helpful approach or likely to achieve *anything* useful. I still have no idea what you are actually suggesting.
I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether.
Let's be honest here; 3.X was released to the community in part as an extended beta.
Correction - 3.0 was an experimental release. That is not true of 3.1 and future releases. All the best, Michael
That's not a problem, unless you drop the word "beta". And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as "experimental", and promised a phase of "disappointment". Why would you expect the Python world to react any differently?
Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think "half-baked" is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*?
I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind.
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that?
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
-- 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.
At 05:22 PM 6/18/2010 +0000, lutz@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that?
Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc. To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all. IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-) Since at the moment Python 3 offers me only cosmetic improvements over 2.x (apart from argument annotations), it's hard to get excited enough about it to want to muck about with porting anything to it, or even trying to learn about all the ramifications of the changes. :-(
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 05:22 PM 6/18/2010 +0000, lutz@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that?
Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc.
Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch. This is code we're talking about - nothing is set in stone, and if something is criminally broken it needs to be first identified, and then fixed.
To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all.
I guess tutorial welcome, rather than patch welcome then ;)
IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-)
What areas. We need specifics which can either be: 1> Shot down. 2> Turned into bugs, so they can be fixed 3> Documented in the core documentation. jesse
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote:
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 05:22 PM 6/18/2010 +0000, lutz@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc.
Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch.
Or walk away.
This is code we're talking about - nothing is set in stone, and if something is criminally broken it needs to be first identified, and then fixed.
To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all.
I guess tutorial welcome, rather than patch welcome then ;)
The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-)
What areas. We need specifics which can either be:
1> Shot down. 2> Turned into bugs, so they can be fixed 3> Documented in the core documentation.
That's bloody ironic in a thread which had pointed at reasons why people are not even considering Py3 for their projects: those folks won't even find the issues due to the lack of confidence in the suitability of the platform. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwc0I0ACgkQ+gerLs4ltQ6aDgCguYv+BXou0a42Yi7ERGCHOfIv 6REAnjejq4LDbE9c/gCqB+xs1yGfQ4KR =/9fw -----END PGP SIGNATURE-----
On Jun 19, 2010, at 10:13 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Noller wrote:
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby <pje@telecommunity.com> wrote:
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL
At 05:22 PM 6/18/2010 +0000, lutz@rmi.net wrote: parsing, joining, opening, etc.
Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch.
Or walk away.
Ok. If you want.
This is code we're talking about - nothing is set in stone, and if something is criminally broken it needs to be first identified, and then fixed.
To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all.
I guess tutorial welcome, rather than patch welcome then ;)
The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
Why can't you? Is it a bug? Let's file it and fix it. Is it that you need a dependency ported? Cool - let's bring it up to the maintainers, or this list, or ask the PSF to push resources into helping port. Anything but nothing. If what you're saying is that python 3 is a completely unsuitable platform, well, then yeah - we can all "fix" it or walk away.
IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-)
What areas. We need specifics which can either be:
1> Shot down. 2> Turned into bugs, so they can be fixed 3> Documented in the core documentation.
That's bloody ironic in a thread which had pointed at reasons why people are not even considering Py3 for their projects: those folks won't even find the issues due to the lack of confidence in the suitability of the platform.
What I saw was a thread about some issues in email, and cgi. We have some work being done to address the issue. This will help resolve some of the issues. I'd there are other issues, then we should step up and either help, or get out ofthe way. Arguing about the viability of a platform we knew would take a bit for adoption is silly and breeds ill will. It's not a turd, and it's not hopeless, in fact rumor has it NumPy will be ported soon which is a major stepping stone. The only way to counteract this meme that python 3 is horribly broken is to prove that it's not, fix bugs, and move on. There's no point debating relative turdiness here. Jesse
On Sat, Jun 19, 2010 at 10:59 AM, Jesse Noller <jnoller@gmail.com> wrote:
On Jun 19, 2010, at 10:13 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Noller wrote:
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 05:22 PM 6/18/2010 +0000, lutz@rmi.net wrote:
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that?
Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc.
Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch.
Or walk away.
Ok. If you want.
This is code we're talking about - nothing is set in stone, and if something is criminally broken it needs to be first identified, and then fixed.
To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all.
I guess tutorial welcome, rather than patch welcome then ;)
The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
Why can't you? Is it a bug? Let's file it and fix it. Is it that you need a dependency ported? Cool - let's bring it up to the maintainers, or this list, or ask the PSF to push resources into helping port. Anything but nothing.
If what you're saying is that python 3 is a completely unsuitable platform, well, then yeah - we can all "fix" it or walk away.
IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-)
What areas. We need specifics which can either be:
1> Shot down. 2> Turned into bugs, so they can be fixed 3> Documented in the core documentation.
That's bloody ironic in a thread which had pointed at reasons why people are not even considering Py3 for their projects: those folks won't even find the issues due to the lack of confidence in the suitability of the platform.
What I saw was a thread about some issues in email, and cgi. We have some work being done to address the issue. This will help resolve some of the issues.
I'd there are other issues, then we should step up and either help, or get out ofthe way. Arguing about the viability of a platform we knew would take a bit for adoption is silly and breeds ill will.
s/I'd/If - stupid phone.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote:
On Jun 19, 2010, at 10:13 AM, Tres Seaver <tseaver@palladion.com> wrote:
Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch. Or walk away.
Ok. If you want.
I specifically said I *didn't* want to walk away. I'm pointing out that in the general case, the ordinary user who finds something incredibly painful or broken is far more likely to walk away from the platform than try to fix it, especially if there are available alternatives (e.g., Ruby, Python 2) where the pain level for that user's application is lower.
I guess tutorial welcome, rather than patch welcome then ;) The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
Why can't you? Is it a bug?
It's not *a* bug, it is that I do my day to day work on very large applications which depend on a large number of not-yet-ported libraries. This barrier is the negative "network effect" which is the whole point of this thread: there is nothing wrong with Python3 except that, to use it, I have to stop doing the work which pays to do an indeterminately-large amount of "hobby" work (of which I already do quite a lot).
Let's file it and fix it. Is it that you need a dependency ported?
I need dozens of them ported, and am working on some of them in the aforementioned "copious spare time."
Cool - let's bring it up to the maintainers, or this list, or ask the PSF to push resources into helping port. Anything but nothing.
Nothing is the default: I am already successful with Python 2, and can't be successfulwith Python 3 (in the sense of delivering timely, cost-effective solutions to my customers) until *all* those dependencies are ported and stable there.
If what you're saying is that python 3 is a completely unsuitable platform, well, then yeah - we can all "fix" it or walk away.
I didn't say that: I said that Python 3 is unsuitable *today* for the work I'm doing, and that the relative wins it provides over Python 2 are dwarfed by the effort required to do all those ports myself.
IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, "that way may not be obvious at first unless you're Dutch". ;-)
OT: The Dutch smiley there doesn't actually help anything but undercut any point to having TOOOWTDI in the list at all.
What areas. We need specifics which can either be:
1> Shot down. 2> Turned into bugs, so they can be fixed 3> Documented in the core documentation.
That's bloody ironic in a thread which had pointed at reasons why people are not even considering Py3 for their projects: those folks won't even find the issues due to the lack of confidence in the suitability of the platform.
What I saw was a thread about some issues in email, and cgi. We have some work being done to address the issue. This will help resolve some of the issues.
If there are other issues, then we should step up and either help, or get out ofthe way. Arguing about the viability of a platform we knew would take a bit for adoption is silly and breeds ill will.
I'm not arguing about viability: there are obviously users for whom Python 3 is not only viable, but superior to Python 2. However, I am quite confident that many pro-Python 3 folks arguing here underestimate the scope of the issues which have generated the (self-fullfilling) "not yet" perception.
It's not a turd, and it's not hopeless, in fact rumor has it NumPy will be ported soon which is a major stepping stone.
Sure, for the (far from trivial) subset of the community doing numerical work.
The only way to counteract this meme that python 3 is horribly broken is to prove that it's not, fix bugs, and move on. There's no point debating relative turdiness here.
Any "turdiness" (which I am *not* arguing for) is a natural consequence of the kinds of backward incompatibilities which were *not* ruled out for Python 3, along with the (early, now waning) "build it and they will come" optimism about adoption rates. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwg5rIACgkQ+gerLs4ltQ6J7wCdFkQL7XeKtBM407Z5D2rSKk8n EWYAoJUfW+JgURUz7NJcWmqFw3PkNYde =WZEv -----END PGP SIGNATURE-----
On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver <tseaver@palladion.com> wrote:
Any "turdiness" (which I am *not* arguing for) is a natural consequence of the kinds of backward incompatibilities which were *not* ruled out for Python 3, along with the (early, now waning) "build it and they will come" optimism about adoption rates.
FWIW, my optimisim is *not* waning. I think it's good that we're having this discussion and I expect something useful will come out of it; I also expect in general that the (admittedly serious) problem of having to port all dependencies will be solved in the next few years. Not by magic, but because many people are taking small steps in the right direction, and there will be light eventually. In the mean time I don't blame anyone for sticking with 2.x or being too busy to help port stuff to 3.x. Python 3 has been a long time in the making -- it will be a bit longer still, which was expected. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver <tseaver@palladion.com> wrote:
Any "turdiness" (which I am *not* arguing for) is a natural consequence of the kinds of backward incompatibilities which were *not* ruled out for Python 3, along with the (early, now waning) "build it and they will come" optimism about adoption rates.
FWIW, my optimisim is *not* waning. I think it's good that we're having this discussion and I expect something useful will come out of it; I also expect in general that the (admittedly serious) problem of having to port all dependencies will be solved in the next few years. Not by magic, but because many people are taking small steps in the right direction, and there will be light eventually. In the mean time I don't blame anyone for sticking with 2.x or being too busy to help port stuff to 3.x. Python 3 has been a long time in the making -- it will be a bit longer still, which was expected.
+1 The important thing is to avoid bigotry and FUD, and deal with things the way they are. The #python IRC team have just helped us make a major step forward. This won't be a campaign with a victorious charge over some imaginary finish line. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000
On Jun 23, 2010, at 8:17 AM, Steve Holden wrote:
Guido van Rossum wrote:
On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver <tseaver@palladion.com> wrote:
Any "turdiness" (which I am *not* arguing for) is a natural consequence of the kinds of backward incompatibilities which were *not* ruled out for Python 3, along with the (early, now waning) "build it and they will come" optimism about adoption rates.
FWIW, my optimisim is *not* waning. I think it's good that we're having this discussion and I expect something useful will come out of it; I also expect in general that the (admittedly serious) problem of having to port all dependencies will be solved in the next few years. Not by magic, but because many people are taking small steps in the right direction, and there will be light eventually. In the mean time I don't blame anyone for sticking with 2.x or being too busy to help port stuff to 3.x. Python 3 has been a long time in the making -- it will be a bit longer still, which was expected.
+1
The important thing is to avoid bigotry and FUD, and deal with things the way they are. The #python IRC team have just helped us make a major step forward. This won't be a campaign with a victorious charge over some imaginary finish line.
For sure. I don't speak for Tres, but I don't think he wasn't talking about optimism about *adoption*, overall, but optimism about adoption *rates*. And I don't think he was talking about it coming from Guido :). There has definitely been some "irrational exuberance" from some quarters. The form it usually takes is someone making a blog post which assumes, because the author could port their smallish library or application without too much hassle, that Python 2.x is already dead and everyone should be off of it in a couple of weeks. I've never heard this position from the core team or any official communication or documentation. Far from it: the realistic attitude that the Python 3 migration is something that will take a while has significantly reduced my own concerns. Even the aforementioned blog posts have been encouraging in some ways, because a lot of people are reporting surprisingly easy transitions.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glyph Lefkowitz wrote:
I don't speak for Tres, but I don't think he wasn't talking about optimism about *adoption*, overall, but optimism about adoption *rates*. And I don't think he was talking about it coming from Guido :).
You channel me correctly here. In particular, the phrase "build it and they will come" was meant to address the idea that the only thing needed to drive adoption was the release of the new, shiny Python3. That particular bit of optimism is what I meant to describe as waning: the community on the whole seems to be more realistic now than two or three years ago about the kind of extra effort required from both core developers and from existing Python 2 folks to get to Python 3.
There has definitely been some "irrational exuberance" from some quarters. The form it usually takes is someone making a blog post which assumes, because the author could port their smallish library or application without too much hassle, that Python 2.x is already dead and everyone should be off of it in a couple of weeks.
I've never heard this position from the core team or any official communication or documentation. Far from it: the realistic attitude that the Python 3 migration is something that will take a while has significantly reduced my own concerns.
Even the aforementioned blog posts have been encouraging in some ways, because a lot of people are reporting surprisingly easy transitions.
Indeed. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwiVS8ACgkQ+gerLs4ltQ4kQgCeJ9nwU8XyiWzOTpHSbWg21bzU 0/IAnjVOj5SlgA9mnAsx4/wMad5lNkqq =HObh -----END PGP SIGNATURE-----
Tres, I am a Python3 enthusiast and realist. I did not expect major adoption for about 3 years (more optimistic than the 5 years of some). If you are feeling pressured to 'move' to Python3, it is not from me. I am sure you will do so on your own, perhaps even with enthusiasm, when it will be good for *you* to do so. If someone wants to contribute while sticking to Python2, its easy. The tracker has perhaps 2000 open 2.x issues, hundreds with no responses. If more Python2 people worked on making 2.7 as bug-free as possible, the developers would be freer to make 3.2 as good as possible (which is what *I* want). The porting of numpy (which I suspect has gotten some urging) will not just benefit 'nemerical' computing. For instance, there cannot be a 3.x version of pygame until there is a 3.x version of numpy, its main Python dependency. (The C Simple Directmedia Llibrary it also wraps and builds upon does not care.) -- Terry Jan Reedy
On Sun, 20 Jun 2010 12:13:34 am Tres Seaver wrote:
I guess tutorial welcome, rather than patch welcome then ;)
The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
You emphatically say you would "like" to use Python3, but describe those who already have as having drunk the Koolaid. Comparing those who can and have successfully moved to Python3 with the Jonestown cult mass-suicide doesn't really strike me as a sign that you want to join them. -- Steven D'Aprano
On Sun, 20 Jun 2010 12:05:46 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, 20 Jun 2010 12:13:34 am Tres Seaver wrote:
I guess tutorial welcome, rather than patch welcome then ;)
The only folks who can write the tutorial are the ones who have already drunk the koolaid. Note that I've been making my living with Python for about twelve years now, and would *like* to use Python3, but can't, yet, and therefore haven't taken the first sip.
You emphatically say you would "like" to use Python3, but describe those who already have as having drunk the Koolaid. Comparing those who can and have successfully moved to Python3 with the Jonestown cult mass-suicide doesn't really strike me as a sign that you want to join them.
I have read the expression "drinking the Koolaid" more than once but I didn't know it related to a mass-suicide at all. It changes my comprehension of it quite a bit... Regards Antoine.
Steven D'Aprano <steve@pearwood.info> writes:
Comparing those who can and have successfully moved to Python3 with the Jonestown cult mass-suicide doesn't really strike me as a sign that you want to join them.
In my experience, many who refer to “drinking the Kool-Aid” are not referring to the Jonestown suicide cult, but rather to the earlier Electric Kool-Aid Acid Test events of the psychedelic era <URL:http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test>. -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney
lutz@rmi.net writes:
I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind.
The fact is, though, that many of your "downwind" readers are not the audience for Python 3, not yet. If you want to do Python 3 a favor, make sure that they understand that Python 3 is *not* an "upgrade" of Python 2. It's a hard task for you, but IMO one strategy is to write in the style that we wrote the DVCS PEP (#374) in: here's how you do the same task in these similar languages. And just as git and Bazaar turned out to have fatal defects in terms of adoption *in that time frame*, Python 3 is not yet adoptable for many, many users. Python 3 is a Python-2-like language, but even though it's built on the same design principles, and uses nearly identical syntax, there are fundamental differences. And it is *very* young. So it's a new language and should be approached in the same way as any new language. Try it on non-mission critical projects, on projects where its library support has a good reputation, etc. Many of your readers have no time (or perhaps no approval "from upstairs") for that kind of thing. Too bad, but that's what happens to every great new language.
So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that?
Why should she make anything of that? Python 3 is a *new* language, possibly as different from Python 2 as C++ was from C (and *more* different in terms of fundamental incompatibilities). And as long as C++ was almost entirely dependent on C libraries, there were problems. (Not to mention that even today there are plenty of programmers who are proud to be C programmers, not C++ programmers.) Today, Python 3 is entirely dependent on Python 2 libraries. It's human to hope there will be no problems, but not realistic. BTW, I think what you're missing is that you're wrong about the money. Python 3 is still about the fun and the code. "Fun and code" are why the core developers spent about five years developing it, because doing that was fun, because the new code has high value as code, and because it promised *them* a more fun and more productive future. Library support, on the other hand, *is* about money. Your readers, down in the trenches of WWW, intraweb, and sysadmin implementation and support, depend on robust libraries to get their day jobs done. They really don't care that writing Python 3 was fun, and that programming in Python 3 is more fun than ever. That doesn't compensate for even one lingering str/bytes bogosity to most of them, and since they don't get paid for fixing Python library bugs, they don't, and they're in no mood to *forgive* any, either. So tell users who feel that way to use Python 2, for now, and check on Python 3 progress every 6 months or so. And users who are just a bit more adventurous to stick to applications where the libraries already have a good reputation *in Python 3*. It's as simple as that, I think. Regards,
At 10:55 PM 6/19/2010 +0900, Stephen J. Turnbull wrote:
They really don't care that writing Python 3 was fun, and that programming in Python 3 is more fun than ever. That doesn't compensate for even one lingering str/bytes bogosity to most of them, and since they don't get paid for fixing Python library bugs, they don't, and they're in no mood to *forgive* any, either.
This is pretty much where I'm at, except that the only potential fun increase Py3 appears to offer me are argument annotations and keyword-only args -- but these are partly balanced by the loss of argument tuple unpacking. The metaclass keyword argument is nice, but the loss of dynamically-settable __metaclass__ is just plain annoying. Really, just about everything that Py3 offers in the way of added fun, seems offset by a matching loss somewhere else. So it's hard to get excited about it - it seems like, "ho hum, a new language that's kind of like Python, but just different enough to be annoying." OTOH, I don't know what to do about that, besides adding some sort of "killer app" feature that makes Python 3 the One Obvious Way to do some specific application domain.
On Sat, 19 Jun 2010 11:55:29 pm Stephen J. Turnbull wrote:
If you want to do Python 3 a favor, make sure that they understand that Python 3 is *not* an "upgrade" of Python 2. [...] Python 3 is a Python-2-like language, but even though it's built on the same design principles, and uses nearly identical syntax, there are fundamental differences. And it is *very* young. So it's a new language and should be approached in the same way as any new language.
I haven't written any large projects in Python3, so take this with a grain of salt, but I just don't see that Python3 is a "new language" as most people understand the term. It might be splitting hairs, but I see it as a new dialect *at worst*, and probably not even that, in the sense that any half decent human coder who can read Python 2.x code should be able to make sense of Python 3.x code, and vice versa. As I see it, the changes to the language and syntax between 2.x and 3.x are much smaller than those between 1.x to 2.x: Python 2.x introduced a brand new object model (new style classes). Python 3.x does not. Python 2.x introduced radically new syntax, namely list comprehensions, while 3.x merely extends the same idea to set and dict comprehensions. Python 2.x introduced lexical scoping AND closures. Python 3.x does nothing as radical. Python 2.x introduced a new (to Python) programming model, namely iterators, complete with TWO extensions to syntax (generator functions including yield, generator expressions), *and* then went and made yield a function so as to introduce coroutines as well. Python 3.x merely uses iterators in more places. Python 2.x introduced Unicode strings. Python 3.x merely makes them the default. The only major difference is that Python 3 takes away as well as adding, but even there, Python 2 did the same, e.g. there is no provision to get the old scoping behaviour except to go back and use 2.1 or older. Frankly, I believe that pushing the meme that "Python 3 is different" is a strategic mistake. People hate and fear change. I should know this. I resisted Python 2.x and stuck with 1.5 until Python 2.3 was released, and then was amazed at how *easy* the transition was. Of course, I wasn't using third party libraries that hadn't been ported to 2.3, if I had my experience would have been different. It's bad enough to have to tell people "Python 3 is currently lacking some critical libraries, particularly third-party libraries" without also telling them (wrongly IMO) "oh, and it's a new language too". -- Steven D'Aprano
Steven D'Aprano writes:
Frankly, I believe that pushing the meme that "Python 3 is different" is a strategic mistake.
I agree that it's strategically undesirable. Unfortunately, the genuine backward incompatibility, as well as the huge mind-share already garnered by what I consider wrong-headed advice from certain quarters have made pushing the meme that "Python 3 is very nearly the same" untenable. It's hard to beat something like "it's not yet time to use Python 3" with a nuanced explanation.
had my experience would have been different. It's bad enough to have to tell people "Python 3 is currently lacking some critical libraries, particularly third-party libraries" without also telling them (wrongly IMO) "oh, and it's a new language too".
That's why I propose the C to C++ analogy. True, C++ does introduce a lot of new features, but most programmers migrating from C to C++ don't learn to use them properly for years, if ever, I'm told. Note also that I don't propose this as PSF advertising. I proposed it as a response to Mark's question, "what should I tell my readers?"
On Sun, 20 Jun 2010 18:14:02 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
had my experience would have been different. It's bad enough to have to tell people "Python 3 is currently lacking some critical libraries, particularly third-party libraries" without also telling them (wrongly IMO) "oh, and it's a new language too".
That's why I propose the C to C++ analogy.
I think it's an unfortunate analogy. C++ needs new libraries (with brand new APIs) to take advantage of its abstraction capabilities. Python 3 has almost the same abstraction capabilities as Python 2, you don't need to write new libraries: just port the existing ones.
True, C++ does introduce a lot of new features, but most programmers migrating from C to C++ don't learn to use them properly for years, if ever, I'm told.
I don't see how Python 3 has that problem. You can be productive here and now in Python 3, re-using your knowledge of Python 2 with a bit of added information. Regards Antoine.
On Sun, Jun 20, 2010 at 7:32 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
True, C++ does introduce a lot of new features, but most programmers migrating from C to C++ don't learn to use them properly for years, if ever, I'm told.
I don't see how Python 3 has that problem. You can be productive here and now in Python 3, re-using your knowledge of Python 2 with a bit of added information.
Yeah, the significant issues with Python 3 over Python 2 *only* apply to people with legacy Python 2 code to worry about. The one thing that makes Python 3 potentially less desirable than Python 2 for some new applications is that the third party library support isn't quite as good yet. As more of the "big" libraries and frameworks provide Python 3 compatible versions, that factor will go away. As far as I can tell, with 3 years still to go on my own original prediction of 5+ years for Python 3 to start to be competitive with Python 2 for programming mindshare, adoption actually seems to be progressing fairly well. A lot of key functionality is either already supported in Python 3 or will be soon, and a lot of the rest is at least talking about plans for Python 3 compatibility. It's just that 5 years can seem like an eternity in the internet age, so sometimes people see the relative lack of adoption of Python 3 at this stage and start to panic about it being a failure. Now, if we're still having this conversation in 2013, then I'll admit we have a problem with the Python 3 uptake rate ;) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Antoine Pitrou writes:
I think it's an unfortunate analogy.
Propose a better one, then. I'm definitely not wedded to the ones I've proposed! But we have a PR problem *now*. The loyal opposition clearly intend to continue trash-talking Python 3 until the libraries get to 100% (or a government-approved approximation of 100%). The topic on #python seems unlikely to change at this point, with both Glyph and JP pointedly failing to denounce it publicly, while Stephen defends it and says it's not going to change as long as the libraries aren't done. What do you suggest? Or do you think there's no PR problem we should worry about, just accept that this going to be a further drag on adoption and improvement, and keep on keeping on?
On Mon, 21 Jun 2010 02:30:17 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Antoine Pitrou writes:
I think it's an unfortunate analogy.
Propose a better one, then. I'm definitely not wedded to the ones I've proposed!
I'm not sure why you want an analogy. Python 3 improves the language and drops legacy cruft. Bringing C++ makes the description unnecessarily contentious and loaded (because C++ has a rather bad reputation amongst many people; recently Linus Torvalds explained again why he thought C was much more appropriate a programming language). And it's not even warranted, because the situation is vastly different.
What do you suggest? Or do you think there's no PR problem we should worry about, just accept that this going to be a further drag on adoption and improvement, and keep on keeping on?
I suppose the PR problem could be solved by having an official page on python.org explain what the new features and advantages of Python 3 over Python 2 are. There's no such thing right now; actually, I'm not sure there's a Web page explaining clearly what the difference is about, why it was done in such a compatibility-breaking way, and what we advise (both actual and potential) users to do. I suppose that's a task for the "Web content editor community". Regards Antoine.
Pass the ketchup, I need to eat my words. I wrote:
The loyal opposition clearly intend to continue trash-talking Python 3 until the libraries get to 100% (or a government-approved approximation of 100%). The topic on #python seems unlikely to change at this point, with both Glyph and JP pointedly failing to denounce it publicly, while Stephen defends it and says it's not going to change as long as the libraries aren't done.
It would seem from posts I received after replying (local mail glitch, should have know there was more coming :-( ) that the facts are that the topic is quite likely to change soonish, and that "trash-talking" is being done, if at all, by trolls. (Having spent a few hours on #python today, I see that's a lot more possible than I would have believed in this community. Nobody's immune.) Glyph, JP, and Stephen have my personal apologies.
On Sun, Jun 20, 2010 at 7:30 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Antoine Pitrou writes: But we have a PR problem *now*. The loyal opposition clearly intend to continue trash-talking Python 3 until the libraries get to 100% (or a government-approved approximation of 100%). The topic on #python seems unlikely to change at this point, with both Glyph and JP pointedly failing to denounce it publicly, while Stephen defends it and says it's not going to change as long as the libraries aren't done.
Huh? We just changed the topic on #python because people complained about it. We didn't do it earlier because we didn't know it was a problem. Defending it doesn't mean it's set in stone :-) I don't wanna come across like a jerk but could we please not use loaded terms like "loyal opposition" and "trash-talking"? I don't really think that's what people do or are (or at least want to be/intend to do). I've really honestly tried my best to fix this situation (see the other thread) and the people whom I've gotten input from (both here and in the IRC channels) have been nothing but helpful.
What do you suggest? Or do you think there's no PR problem we should worry about, just accept that this going to be a further drag on adoption and improvement, and keep on keeping on?
I very much like Martin and Antoine's ideas of putting the thing up on python.org, that might also solve people's problems with the apparent dissonance between #python and python-dev/the PSF that neither side really wants. To the contrary, I think everyone wants this situation to improve, including Guido, apparently. Myself included, I think everyone stands to gain here. thanks for listening Laurens
2010/6/20 Steven D'Aprano <steve@pearwood.info>:
Python 2.x introduced Unicode strings. Python 3.x merely makes them the default.
"Merely"? To me this looks as the main reason why a lot of projects haven't been ported to Python 3 yet. I attempted to port pyftpdlib to python 3 several times and the biggest show stopper has always been the bytes / string difference introduced by Python 3 which forces you to *know* and *use* Unicode every time you deal with some text and 2to3 is completely useless here. I can only imagine how difficult can it be to do such a conversion in a project like Twisted or Django where the I/O plays a fundamental role. The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow. The majority of people prefer to stay with bytes and eventually learn and introduce Unicode only when that is actually needed. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil
I can only imagine how difficult can it be to do such a conversion in a project like Twisted or Django where the I/O plays a fundamental role.
For Django, you don't need to imagine, but can look at the actual changes: http://bitbucket.org/loewis/django-3k/
The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow. The majority of people prefer to stay with bytes and eventually learn and introduce Unicode only when that is actually needed.
It's not really an issue with "Unicode", but rather with "characters". Surprisingly, most people don't grasp the notion of "abstract character". This is similar to not grasping the notion of "abstract integral number", which most programmers master over time (although my students typically need a year or more to get the difference between "decimal number", "two's complement", and "abstract integer"; the difference between "character string" and "number" is easier (*)). For numbers, programmers are forced to accept the abstraction. For character strings, they apparently resist much more. Regards, Martin (*) An anecdotal dialog may read like this Teacher: "How are numbers represented in Python?" Student: "In decimal." T: "How so?" S: "I can do x = 47 and it is decimal. I can then do print x and get "47". See?"
On Sun, 20 Jun 2010 14:26:28 +0200 Giampaolo Rodolà <g.rodola@gmail.com> wrote:
I attempted to port pyftpdlib to python 3 several times and the biggest show stopper has always been the bytes / string difference introduced by Python 3 which forces you to *know* and *use* Unicode every time you deal with some text and 2to3 is completely useless here.
I don't really understand what the difficulties are. A character is a character; to convert from bytes to characters needs to know the encoding, which your protocol should specify somewhere (of course, I suppose FTP is old and crummy enough that it may not specify anything). An "encoding" is nothing more than a transformation. When you get gzipped data, you must decompress it before doing anything useful out of it. Similarly, when you get (say) UTF-8 data, you must decode it before doing anything useful out of it.
I can only imagine how difficult can it be to do such a conversion in a project like Twisted or Django where the I/O plays a fundamental role.
Twisted actually seems to enforce the bytes / unicode separation quite well already, so I don't think they should have many problems on that front. Modern Web frameworks seem to be in the same boat (they already give the Web developer unicode strings to play with, and handle the encoding/decoding at the IO boundary transparently).
The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow.
Could Google fund a project named "Unicode Swallow"? Regards Antoine.
On Sun, Jun 20, 2010 at 5:26 AM, Giampaolo Rodolà <g.rodola@gmail.com> wrote:
2010/6/20 Steven D'Aprano <steve@pearwood.info>:
Python 2.x introduced Unicode strings. Python 3.x merely makes them the default.
"Merely"? To me this looks as the main reason why a lot of projects haven't been ported to Python 3 yet. I attempted to port pyftpdlib to python 3 several times and the biggest show stopper has always been the bytes / string difference introduced by Python 3 which forces you to *know* and *use* Unicode every time you deal with some text
Ah, but this is the crux of the difference between Python 2 and 3. The distinction between text and bytes is crucial, and Python 2 tried to paper over the differences in a way that led to endless pain. Many clumsy and shaky hacks have been invented to alleviate the pain but it never goes away. Python 3 takes a much clearer stance on the difference -- your code *must* be aware of the distinction and it *must* deal with it. The problem comes exactly where you find it: when *porting* existing code that uses aforementioned ways to alleviate the pain, you find that the hacks no longer work and a properly layered design is needed that clearly distinguishes between which variables contain bytes and which text.
and 2to3 is completely useless here.
Alas, this is true, because it is not a matter of changing some simple things. The old ways are no longer supported.
I can only imagine how difficult can it be to do such a conversion in a project like Twisted or Django where the I/O plays a fundamental role.
Django actually took one of the most principled stances towards this issue and has already been ported (although the port is not maintained by the core Django developers yet). I can't speak for Twisted but I know they have some funding towards a port. The problem is often worse for smaller libraries (like I presume pyftplib is) which don't have a clear stance about bytes vs. text. Another problem is some internet protocols (of which FTP I believe is one) which use antiquated models for dealing with binary vs. text data, often focusing entirely on encodings (usually and mistakenly called "character sets") rather than on proper Unicode support.
The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow.
Education is needed. When you search Google (or Bing, for that matter :-) for "python unicode" the first hit is http://www.amk.ca/python/howto/unicode, which is highly detailed but probably too much information for the typical person faced with a UnicodeError exception traceback (that page is also focused on Python 2). What we need is a cookbook on how to deal with various common situations.
The majority of people prefer to stay with bytes and eventually learn and introduce Unicode only when that is actually needed.
This is exactly what we tried to do in Python 2 and it was a flagrant disaster. It's just that the work-arounds people have created to deal with it don't port clearly -- which is by design. This is why I've always said that I assumed that the Python 3 transition would take 5 years. On the #python issue, I expect that IRC is much less influential that some here fear (and than some fervent IRC users believe). I don't see reason for panic or heavy-handed interference. OTOH engaging the channel operators more in python-dev sounds like a useful approach. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum writes:
On the #python issue, I expect that IRC is much less influential that some here fear (and than some fervent IRC users believe). I don't see reason for panic or heavy-handed interference. OTOH engaging the channel operators more in python-dev sounds like a useful approach.
From a few hours monitoring and participating in #python, Laurens gives pretty accurate summary of the kind of people in the channel. I didn't see anything about Python 3, but I can definitely imagine there being Python-3-baiting trolls. There certainly were a few trollish
More vice-versa, I now think. Ie, (somewhat) greater python-dev presence on #python is more important. I sort of assumed that people actually participated in #python, as a number do in c.l.p, but that doesn't seem to be so. At least while I was there, I didn't see anybody else who seemed to be python-dev, whether core or the regular denizens of the peanut gallery. posters. Anyway, what I personally plan to do is put in a couple of hours a week on #python, and I probably mostly won't mention Python 3 unless asked, and maybe in discussing Unicode issues. While I don't claim to be particularly *representative* of python-dev, an additional dimension of diversity should go a long way.
On Sun, Jun 20, 2010 at 10:57:05AM -0700, Guido van Rossum wrote:
Education is needed. When you search Google (or Bing, for that matter :-) for "python unicode" the first hit is http://www.amk.ca/python/howto/unicode, which is highly detailed but probably too much information for the typical person faced with a UnicodeError exception traceback (that page is also focused on Python 2). What we need is a cookbook on how to deal with various common
Eep! That should be directed to http://docs.python.org/howto/unicode.html, the copy that's actually incorporated in the Python docs. I'll fix that immediately. Regarding a smaller document for people who hit a UnicodeError exception: could we write a little Unicode FAQ for python.org? --amk
On 6/20/2010 8:26 AM, Giampaolo Rodolà wrote:
I attempted to port pyftpdlib to python 3 several times and the biggest show stopper has always been the bytes / string difference introduced by Python 3 which forces you to *know* and *use* Unicode every time you deal with some text and 2to3 is completely useless here.
I believe the advice in the wiki porting page is to use unicode() and bytes() but never str(), in a version that runs in 2.6. Then 2to3 should do fine. For 2.5-, add 'bytes = str' somewhere. 2to3 still gets patches, I believe, when someone exhibits code that could and ought to be converted but is not. I suspect that if you posted 'Problems porting pyftpdlib to Python3', you would get some help. If it involved inadequacies in the current tools and guides, it would to be be on-topic here. Or try python-list.
The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow.
I felt that way until my daughter decided to switch from Spanish to Japanese for here foreign language. Once I quit fighting it, it because much easier to swallow and learn. As it turns out, thinking in Unicode is a pretty straightforward generalization of thinking in ascii. There are some annoying glitches due to the need to accomodate legacy systems. The plethora of legacy encodings for various subsets, besides ascii, is also a nuisance.
The majority of people
who use latin-char alphabets
prefer to stay with bytes and eventually learn and introduce Unicode only when that is actually needed.
The example at http://code.google.com/p/pyftpdlib/ uses names and filenames. Without unicode, these are restricted to ascii, unless you use multiple encodings, which to me would be worse. Terry Jan Reedy
On Sun, Jun 20, 2010 at 11:30 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 6/20/2010 8:26 AM, Giampaolo Rodolà wrote:
I attempted to port pyftpdlib to python 3 several times and the biggest show stopper has always been the bytes / string difference introduced by Python 3 which forces you to *know* and *use* Unicode every time you deal with some text and 2to3 is completely useless here.
I believe the advice in the wiki porting page is to use unicode() and bytes() but never str(), in a version that runs in 2.6. Then 2to3 should do fine. For 2.5-, add 'bytes = str' somewhere.
Really? I thought you were supposed to call encode/decode methods on the appropriate thing, depending if they're coming from a byte source or a character source. The problems arise when you're doing things like paths, which I believe are bytes on *nix and proper Unicode on Windows (which basically just means they enforce an encoding, UTF-16 if I'm not mistaken). I don't actually use Windows so I might be completely wrong here.
2to3 still gets patches, I believe, when someone exhibits code that could and ought to be converted but is not.
I suspect that if you posted 'Problems porting pyftpdlib to Python3', you would get some help. If it involved inadequacies in the current tools and guides, it would to be be on-topic here. Or try python-list.
The choice of forcing the user to use Unicode and "think in Unicode" was a very brave one, and I'm sure it's for the better, but not everyone wants to deal with that because Unicode is hard to swallow.
I felt that way until my daughter decided to switch from Spanish to Japanese for here foreign language. Once I quit fighting it, it because much easier to swallow and learn. As it turns out, thinking in Unicode is a pretty straightforward generalization of thinking in ascii. There are some annoying glitches due to the need to accomodate legacy systems. The plethora of legacy encodings for various subsets, besides ascii, is also a nuisance.
I think doing unicode/str properly in 2.x is very important, #python stresses it quite often, I think Py3k's strictness is a good idea because people very often write something that appears to work for a long time, and then someone tries it using funny bytes, and everything blows apart. Convincing people their software is wrong when "everything worked five minutes ago" is really hard :-) You'd be surprised how long it can take before some of these problems are found, a couple of weeks ago in #python we had exactly this problem when we were helping Blender folks. There was a bug report from a German Blender user, turns out Blender ignores unicode in some critical spot making importing between people who disagree on charsets impossible. And Blender isn't exactly a project that's two weeks old and filled with idiots :) The downside is that *fixing* them then becomes a nontrivial task. The central problem is probably that a lot of people don't understand Unicode. Recently I learned that even Tanenbaum got it wrong in his latest revision of the computer networks book! (Although that might just be my dutch translation of it being bad).
Terry Jan Reedy
Laurens
On Mon, 21 Jun 2010 08:01:08 am Laurens Van Houtven wrote:
I think doing unicode/str properly in 2.x is very important, #python stresses it quite often, I think Py3k's strictness is a good idea because people very often write something that appears to work for a long time, and then someone tries it using funny bytes, and everything blows apart. Convincing people their software is wrong when "everything worked five minutes ago" is really hard :-)
Worse is when you have people who, when faced with their software failing to handle filenames containing non-ASCII characters ("those funny letters"), insist that the problem is the user for giving non-ASCII characters. Even when they're in the user's native (non-Latin) language. Even when the OS supports them. Gah. -- Steven D'Aprano
participants (18)
-
"Martin v. Löwis" -
A.M. Kuchling -
Antoine Pitrou -
Ben Finney -
Giampaolo Rodolà -
Glyph Lefkowitz -
Guido van Rossum -
Jesse Noller -
Laurens Van Houtven -
lutz＠rmi.net -
Michael Foord -
Nick Coghlan -
P.J. Eby -
Stephen J. Turnbull -
Steve Holden -
Steven D'Aprano -
Terry Reedy -
Tres Seaver