Re: [Python-Dev] email package status in 3.X
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?" ___ 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
[Python-Dev] [OT] Re: email package status in 3.X
On Sun, 20 Jun 2010 12:05:46 +1000 Steven D'Aprano 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. ___ 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] email package status in 3.X
On Sun, 20 Jun 2010 18:14:02 +0900 "Stephen J. Turnbull" 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. ___ 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
[Python-Dev] [OT] the Kool-Aid Acid Test (was: email package status in 3.X)
Steven D'Aprano 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 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 ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Hello, I'm one of the active people in #python that some people dislike for behavior with respect to Python 3. First of all I'd like to defuse the situation, much like Jacob. Seriously. It's been a bunch of posts so far and most of them have been pretty angry. Let's take a deep breath and try to fix the situation that's getting people frustrated like grownups :-) (FWIW: I find being called worse than half-intelligent pretty offensive. Let's stop doing that?) The idea being expressed in the IRC topic is _way_ bigger than the room an IRC topic gives you. Yes, it's an imperfect medium, yes, it's probably partially based on the use case: it's just that experience leads us to believe that the vast majority of use cases ends up being more in 2.x turf then 3.x turf, at the very least in the past. I'm sorry if you had the impression people wanted to nail you at the stake for using Python 3. If that's how you felt, it isn't true. I basically agree with Glyph. I don't think we've recently (I'm not omnipresent) told anyone who had any good reasons to to stop using Python 3. If someone's doing work that actually needs Python 3 (most recent example a GSOC student porting Sphinx), we try our best to help, and AFAICT we've mostly been successful. (Please correct me if you think this is erroneous.). We don't get too many people that actually want or need that, but I'm guessing that's mostly because people porting libraries to py3k usually already know what they're doing so they don't need the first-line-of-defense thing for Python questions that #python tries to be. Maybe you disagree on what good reasons are. #python is a bunch of volunteers giving help, free of charge, which is usually of a pretty high standard because they're professional Python developers and have been for a long time. Maybe that biases some of us against Py3k? Fact remains that there's a bunch of active people on IRC who pour a lot of time and effort into #python and make a lot of newbies really happy, and I think the picture you're painting based on a single issue that clearly not everyone agrees on is a bit disrespectful and somewhat unfair. Also, I'm pretty sure nobody has ever said that Python 3.x was a "failure", or anything like it. #python has claims that Python 3.x, as a platform for building production apps, is a work in progress because of third party library support, and the language itself is pretty much done and okay -- a cleaner version of 2.x. People ask why it's too early to use Py3k, and that's _always_ the answer they get: at least the first half, and usually the second half too. In the mean while, we encourage people to write code that will be easy to port and behave well in 3.x: new-style classes, don't use eager versions when the Py3k default is lazy and you don't actually need the eager thing, use as many third party libraries as possible (the idea being that this would minimize effort needed to make the switch on the grand scale of things), use absolute imports always (and only explicit relative, but it's discouraged), always have a full unit test suite. This is advice that generally makes a lot of sense, and it's the recommended thing in PEP 3000 for porting to 3.x as well. We're still telling people to use Python 2.x by default because of a few major things: 1. going out on a limb here: well over 90% of those people are completely new to Python and out of those most of them completely new to programming too, 2. the nicest libraries for doing a lot of stuff aren't ported yet, or are in the process of being ported but not yet recommended for actual use by their authors, (this seems to be a point of contention?) 3. we know how to help people better with it Which are all basically different incarnations of the same issue. People are working on libraries everywhere and I really don't want to pretend those people haven't gotten any work done, but AFAICT a lot of these for existing mature projects that you'd want people to use in order to be happy productive Python users don't really exist yet or are at best experimental. At the very least I think most people can agree that 2.x is still the default release for existing, mature software projects and most new ones too. I can only speak for my own area of intrest: Python is way too big for anyone to have used every piece of software for it ever. I, personally, don't use 3.x because I develop for PyS60 devices, PythonCE devices (2.5 only), and Twisted servers (2.6), and none of those work on 3.x yet. The other thing we build is websites, and AFAIK the web situation, for now, is still "use python2.x", too? (for any non-trivial website, of course). We use AMQP, and the best thing we've found for it is 2.x only (maybe Carrot and Pika do 3.x now, but I can't find any evidence of it). Nobody here (here = place of business) hates Python 3. We just can't use it. I'm very sorry if you've been offended. Like Glyph said: we're not grinding ideological axes. We're just recommending w
Re: [Python-Dev] email package status in 3.X
On Sun, Jun 20, 2010 at 7:32 PM, Antoine Pitrou 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 | [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] #Python3 ! ? (was Python Library Support in 3.x)
On 20 Jun 2010, at 11:35, Laurens Van Houtven wrote: Hello, I'm one of the active people in #python that some people dislike for behavior with respect to Python 3. First of all I'd like to defuse the situation, much like Jacob. Seriously. It's been a bunch of posts so far and most of them have been pretty angry. Let's take a deep breath and try to fix the situation that's getting people frustrated like grownups :-) (FWIW: I find being called worse than half-intelligent pretty offensive. Let's stop doing that?) The idea being expressed in the IRC topic is _way_ bigger than the room an IRC topic gives you. Hey Laurens - I don't have an issue with with anything you've said, but given the topic is far more nuanced than an IRC topic can express maybe that just isn't the right place for it. Michael Yes, it's an imperfect medium, yes, it's probably partially based on the use case: it's just that experience leads us to believe that the vast majority of use cases ends up being more in 2.x turf then 3.x turf, at the very least in the past. I'm sorry if you had the impression people wanted to nail you at the stake for using Python 3. If that's how you felt, it isn't true. I basically agree with Glyph. I don't think we've recently (I'm not omnipresent) told anyone who had any good reasons to to stop using Python 3. If someone's doing work that actually needs Python 3 (most recent example a GSOC student porting Sphinx), we try our best to help, and AFAICT we've mostly been successful. (Please correct me if you think this is erroneous.). We don't get too many people that actually want or need that, but I'm guessing that's mostly because people porting libraries to py3k usually already know what they're doing so they don't need the first-line-of-defense thing for Python questions that #python tries to be. Maybe you disagree on what good reasons are. #python is a bunch of volunteers giving help, free of charge, which is usually of a pretty high standard because they're professional Python developers and have been for a long time. Maybe that biases some of us against Py3k? Fact remains that there's a bunch of active people on IRC who pour a lot of time and effort into #python and make a lot of newbies really happy, and I think the picture you're painting based on a single issue that clearly not everyone agrees on is a bit disrespectful and somewhat unfair. Also, I'm pretty sure nobody has ever said that Python 3.x was a "failure", or anything like it. #python has claims that Python 3.x, as a platform for building production apps, is a work in progress because of third party library support, and the language itself is pretty much done and okay -- a cleaner version of 2.x. People ask why it's too early to use Py3k, and that's _always_ the answer they get: at least the first half, and usually the second half too. In the mean while, we encourage people to write code that will be easy to port and behave well in 3.x: new-style classes, don't use eager versions when the Py3k default is lazy and you don't actually need the eager thing, use as many third party libraries as possible (the idea being that this would minimize effort needed to make the switch on the grand scale of things), use absolute imports always (and only explicit relative, but it's discouraged), always have a full unit test suite. This is advice that generally makes a lot of sense, and it's the recommended thing in PEP 3000 for porting to 3.x as well. We're still telling people to use Python 2.x by default because of a few major things: 1. going out on a limb here: well over 90% of those people are completely new to Python and out of those most of them completely new to programming too, 2. the nicest libraries for doing a lot of stuff aren't ported yet, or are in the process of being ported but not yet recommended for actual use by their authors, (this seems to be a point of contention?) 3. we know how to help people better with it Which are all basically different incarnations of the same issue. People are working on libraries everywhere and I really don't want to pretend those people haven't gotten any work done, but AFAICT a lot of these for existing mature projects that you'd want people to use in order to be happy productive Python users don't really exist yet or are at best experimental. At the very least I think most people can agree that 2.x is still the default release for existing, mature software projects and most new ones too. I can only speak for my own area of intrest: Python is way too big for anyone to have used every piece of software for it ever. I, personally, don't use 3.x because I develop for PyS60 devices, PythonCE devices (2.5 only), and Twisted servers (2.6), and none of those work on 3.x yet. The other thing we build is websites, and AFAIK the web situation, for now, is still "use python2.x", too? (for any non-trivial website, of course). We use AMQP, and the best thing we've found for it is 2.x only (maybe
Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)
Michael, Fair point! It's mostly put in the topic so people can ask about it and we can give them more detailed answers, because, as other people have mentioned, the exact answer depends largely on what *precisely* someone is doing. I'm not sure what sort of an effect it would have if we took it out. Maybe something we could try? I'm not sure it'd have much of a practical effect since most of the regulars expertise isn't going to shift instantly, so getting actual help is probably going to be a bit rough on 3.x users. At the very least I'm going to take this suggestion to #python's regulars and see what they have to say about it :-) (One of the problems people I've talked to in private that were "pretty miffed" about is the dissonance between #python and python-dev, and that there's some problem with people assuming things said on #python as being very authoritative answers (ha ha). I think this is really bad for Python as a whole and I've love to hear ideas on how you guys think it could be fixed.) thanks Laurens ___ 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] email package status in 3.X
2010/6/20 Steven D'Aprano : > 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 ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 9:33 PM, Laurens Van Houtven wrote: > I'm not sure what sort of an effect it would have if we took it out. > Maybe something we could try? I'm not sure it'd have much of a > practical effect since most of the regulars expertise isn't going to > shift instantly, so getting actual help is probably going to be a bit > rough on 3.x users. Given the number of other links that are already in the status message, it would be really nice if the comment could be updated to something like: "Is Python3 ready for me? http://python-commandments.org/python3.html"; i.e. make it clear that this is a question where the answer will vary based on your use case, and provide a clear direction on where to get more information. That page could then be updated to give a more balance view of the pros of Python 3 (e.g. cleaner core language design, future direction of the language, much better Unicode support) and the pros of Python 2 (e.g. wider installed base, better current third party library support, greater existing developer base, larger support ecosystem, greater #python expertise) > (One of the problems people I've talked to in private that were > "pretty miffed" about is the dissonance between #python and > python-dev, and that there's some problem with people assuming things > said on #python as being very authoritative answers (ha ha). I think > this is really bad for Python as a whole and I've love to hear ideas > on how you guys think it could be fixed.) There are always going to be differences in how different communities see the world and even the "Python community" is far too large to have a consistent point of view on almost any topic. So we'll likely have to muddle through with various ideas slowly percolating through to different parts of the community. That said, keeping in touch with the #python crew is certainly something we haven't paid much attention to in the past, but is probably just as important as staying in touch with major library developers and the developers of other implementations. 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, 20 Jun 2010 13:33:35 +0200 Laurens Van Houtven wrote: > > (One of the problems people I've talked to in private that were > "pretty miffed" about is the dissonance between #python and > python-dev, and that there's some problem with people assuming things > said on #python as being very authoritative answers (ha ha). I think > this is really bad for Python as a whole and I've love to hear ideas > on how you guys think it could be fixed.) Perhaps lower the tone a bit on http://pound-python.org/ ? “foremost support system for developing quality Python applications” ... “crack team of Python experts” ... “Your time won't be wasted by architecture astronauts or trivial repetitions of the docs”. (I understand these are slightly tongue-in-cheek but, if this page is intented mainly for beginners, I think being descriptive is more valuable) Also, mention other support options there - primarily comp.lang.python, of course, and the official documentation pages. 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] #Python3 ! ? (was Python Library Support in 3.x)
I'm sorry if you had the impression people wanted to nail you at the stake for using Python 3. If that's how you felt, it isn't true. I basically agree with Glyph. I don't think we've recently (I'm not omnipresent) told anyone who had any good reasons to to stop using Python 3. If someone's doing work that actually needs Python 3 (most recent example a GSOC student porting Sphinx), we try our best to help, and AFAICT we've mostly been successful. (Please correct me if you think this is erroneous.). We don't get too many people that actually want or need that, but I'm guessing that's mostly because people porting libraries to py3k usually already know what they're doing so they don't need the first-line-of-defense thing for Python questions that #python tries to be. Thanks for explaining your position on this so carefully, Laurens. You've made many reasonable points which I hope will help to cool things down a little. Clearly, there are situations where it makes sense to advocate Python 2.X and other situations where people can be encouraged to consider Python 3. The issues that potential users need to consider are too subtle to be represented fairly by the simple advice to 'avoid Python 3', so can we not all agree to remove it as a #python topic as a gesture of goodwill? Nobody need change their opinions or adovacy as a result, but it would have the benefit of presenting #python in a more neutral and inclusive light. I've not used IRC much in the past, but if it would be useful for someone like myself - a longtime Python user but recent and enthusiastic Python 3 adopter - to offer my opinions and advice on the issue to newcomers then I'm certainly willing to get involved. We're still telling people to use Python 2.x by default because of a few major things: 1. going out on a limb here: well over 90% of those people are completely new to Python and out of those most of them completely new to programming too, Not sure if I agree with you here; I regard people new to programming as the prime candidates for using Python 3. Many of the language changes have the effect of making it significantly easier to learn for newcomers (I wrote about this a while ago - see http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html). Also, people new to Python or programming in general won't have the burden of legacy code that needs to be converted. The only situation in which I'd direct someone new to programming away from Python 3 would be if they had a specific need to use a library that wasn't yet supported. 2. the nicest libraries for doing a lot of stuff aren't ported yet, or are in the process of being ported but not yet recommended for actual use by their authors, (this seems to be a point of contention?) This has certainly been the key issue for me. Only in the past two or three months have we got to the point where I feel can commit to Python 3 fully. Six months ago, I definitely could not have done so. This is progress, and we need to be positive about it. Regards, Nick -- Dr Nick Efford, School of | E: [email protected] Computing, University of | T: +44 113 343 6809 Leeds, Leeds, LS2 9JT, UK | W: http://www.comp.leeds.ac.uk/nde/ --+- PGP fingerprint: 6ADF 16C2 4E2D 320B F537 8F3C 402D 1C78 A668 8492 ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 2:30 PM, Nick Coghlan wrote: > On Sun, Jun 20, 2010 at 9:33 PM, Laurens Van Houtven > wrote: > Given the number of other links that are already in the status > message, it would be really nice if the comment could be updated to > something like: > > "Is Python3 ready for me? http://python-commandments.org/python3.html"; Sounds like a great idea, I'll run it past the other folks. > i.e. make it clear that this is a question where the answer will vary > based on your use case, and provide a clear direction on where to get > more information. I think the reason #python regulars never saw this as a problem is because people who actually ask do get this answer. At least they do if Aaron, Allen, Brendon, Clovis, Stephen, Devin, me... (list of names way too numerous to be exhaustive) are awake. Maybe the strong language does scare people off from that critical asking-for-more-information step, so yes, reviewing that would be a good idea. > There are always going to be differences in how different communities > see the world and even the "Python community" is far too large to have > a consistent point of view on almost any topic. So we'll likely have > to muddle through with various ideas slowly percolating through to > different parts of the community. That said, keeping in touch with the > #python crew is certainly something we haven't paid much attention to > in the past, but is probably just as important as staying in touch > with major library developers and the developers of other > implementations. My thoughts exactly on both counts. Communication good, embrace heterogeneity :) > Cheers, > Nick. > Thanks for your input, Laurens ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 2:51 PM, Antoine Pitrou wrote: > On Sun, 20 Jun 2010 13:33:35 +0200 > Laurens Van Houtven wrote: > Perhaps lower the tone a bit on http://pound-python.org/ ? > “foremost support system for developing quality Python > applications” ... “crack team of Python experts” ... “Your time won't > be wasted by architecture astronauts or trivial repetitions of the > docs”. Noted, we'll say the same thing but differently. > (I understand these are slightly tongue-in-cheek but, if this page is > intented mainly for beginners, I think being descriptive is more > valuable) Yes, it is tongue-in-cheek, but perhaps a bit too much so :-) I didn't write it, it just never struck me as a problem at the time. I think the problem is that that page was created to fix a very specific problem (explaining why #python isn't a search engine), and it probably got written more out of something snapping than an attempt to be informative. > Also, mention other support options there - primarily comp.lang.python, > of course, and the official documentation pages. Will do. > Regards > > Antoine. Thanks for your input, Laurens ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 11:08 PM, Nick Efford wrote: > Not sure if I agree with you here; I regard people new to > programming as the prime candidates for using Python 3. Many of > the language changes have the effect of making it significantly > easier to learn for newcomers (I wrote about this a while ago - > see http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html). That's actually one of the better write-ups I've seen regarding several of the key benefits of the Python 3 transition. They're easy to lose sight of when discussing the topic with the existing developers that are bearing the cost of converting their code due to changes that were made primarily for the benefit of new users. 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] #Python3 ! ? (was Python Library Support in 3.x)
Glyph Lefkowitz wrote: > On Jun 19, 2010, at 5:02 PM, Terry Reedy wrote: > >> HoweverI have very little experience with IRC and consequently have >> little idea what getting a permanent, owned, channel like #python >> entails. Hence the '?' that follows. >> >> What do others think? > > Sure, this is a good idea. > > Technically speaking, this is extremely easy. Somebody needs to "/msg > chanserv register #python3" and that's about it. (In this case, that > "someone" may need to be Brett Cannon, since he is the official group > contact for Freenode regarding Python-related channels.) > > Practically speaking, you will need a group of at least a dozen > contributors, each in a different timezone, who sit there all day > answering questions :). Otherwise the ownership of the channel is just > a signpost pointing at an empty room. > Which is yet another reason I don't think it would be productive to attempt any kind of pre-emptive action against the #python team. They do serve a very useful purpose, and there is reasoned logic behind their position even if we might wish it were different. 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 ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
On 2010-06-19, Arc Riley wrote: > You mean Twisted support, No. I don't. Often, on #python, we get the situation where someone approaches us saying, "I have this problem in my python code, why does this not work for me?" and usually very quickly we establish the programmer has followed a tutorial or attempted to use a library that depends on python 2, but the programmer is running python 3. Queried on why they are using python 3, the answer is frequently, "Because I downloaded the latest version." For those people, we believe it is too early to use python 3. When talking to these people with a world view of "why shouldn't i use the latest version" having a concrete preexisting statement in the topic we can point to is invaluable. We don't always ask those who are having python 3 problems to go to python2. Often we simply explain about all strings bring unicode or print now being a function, and the conversation dies. There are also programmers who definately should be using python 3 for their work. They know who they are. They do receive support in #python. -- In writing this email to python-dev, I have reviewed my logs of #python specifically looking for the phrase 'python 3'. Here are some packages that were named in the conversations: - py2exe - cx_Freeze - twisted - PIL - ctypes - email I present this list because they are what programmers are coming to #python to ask about, and that may be relevent to your discussion about python 3 ports. -- Regards, Stephen Thorne ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 3:08 PM, Nick Efford wrote: > Thanks for explaining your position on this so carefully, > Laurens. You've made many reasonable points which I hope will > help to cool things down a little. Cool, glad it's appreciated. > Clearly, there are situations where it makes sense to advocate > Python 2.X and other situations where people can be encouraged to > consider Python 3. The issues that potential users need to > consider are too subtle to be represented fairly by the simple > advice to 'avoid Python 3', so can we not all agree to remove > it as a #python topic as a gesture of goodwill? I like the idea of changing it to something that points to a more detailed thing as someone suggested above. Ideally short and completely neutral, like "2.x or 3.x? http://shorturl/whatever";. > Nobody need change their opinions or adovacy as a result, I very much doubt that'd happen anyway ;-) > but it would have the benefit of presenting #python in a more > neutral and inclusive light. +1 > I've not used IRC much in the past, but if it would be useful for > someone like myself - a longtime Python user but recent and > enthusiastic Python 3 adopter - to offer my opinions and advice > on the issue to newcomers then I'm certainly willing to get > involved. Everybody's very welcome, the entire reason I'm putting time into this is because apparently some people felt less welcome than I'd like them to feel :-) >> We're still telling people to use Python 2.x by default because of a >> few major things: >> >> 1. going out on a limb here: well over 90% of those people are >> completely new to Python and out of those most of them completely new >> to programming too, > > Not sure if I agree with you here; I regard people new to > programming as the prime candidates for using Python 3. Many of > the language changes have the effect of making it significantly > easier to learn for newcomers (I wrote about this a while ago - > see http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html). > Also, people new to Python or programming in general won't have > the burden of legacy code that needs to be converted. Very nice read. Most points are indeed common questions, we just tell people how to work around them in 2.x. ie, whenever someone posts old-style classes, someone will always point out to them that they really probably want new-style even if they don't get the difference yet; for integer division we tell people to convert to float or from __future__ import division, if you use print call it with exactly one string and just build that string, never ever ever use input, just use raw_input, that sort of stuff. Not always very clean, more of a workaround. Also stuff like chevron print is actively discouraged in favor of using a logging module or eg sys.stderr. Of course, in py3k where you don't have to, which is even nicer :-) I'm guessing it's okay to link to this from the newer, more neutral pages? :-) > The only situation in which I'd direct someone new to programming > away from Python 3 would be if they had a specific need to use a > library that wasn't yet supported. Yeah, I think the reason for that rule is that the majority of people asking about new software actually start or end up in this category. No statistics to back that up, but the regulars seem to agree (again, maybe we're biased). See Steve Thorne (Jerub)'s post in a parallel thread. Usually it's because they want to do something that people have already solved, and #python is pretty strict about discouraging implementing software that already exists. Of course, as the porting of Python 3.x packages progresses this point becomes more and more moot. A possible solution is that we suggest that people, instead of rolling their own thing from scratch, help to port an existing good 2.x lib to 3.x, or use 2.x? I don't think it's a good idea to start encouraging NIH in new programmers :-) >> 2. the nicest libraries for doing a lot of stuff aren't ported yet, or >> are in the process of being ported but not yet recommended for actual >> use by their authors, (this seems to be a point of contention?) > > This has certainly been the key issue for me. Only in the past > two or three months have we got to the point where I feel can commit > to Python 3 fully. Six months ago, I definitely could not have > done so. This is progress, and we need to be positive about it. Yeah, that message has been in the /topic for _WAY_ longer than 6 months. > > Regards, > > > Nick Thank you very much for your input, Laurens ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
Stephen Thorne wrote: > On 2010-06-19, Arc Riley wrote: >> You mean Twisted support, > > No. I don't. > > Often, on #python, we get the situation where someone approaches us saying, "I > have this problem in my python code, why does this not work for me?" and > usually very quickly we establish the programmer has followed a tutorial or > attempted to use a library that depends on python 2, but the programmer is > running python 3. > > Queried on why they are using python 3, the answer is frequently, "Because I > downloaded the latest version." > > For those people, we believe it is too early to use python 3. When talking to > these people with a world view of "why shouldn't i use the latest version" > having a concrete preexisting statement in the topic we can point to is > invaluable. > > We don't always ask those who are having python 3 problems to go to python2. > Often we simply explain about all strings bring unicode or print now being a > function, and the conversation dies. > > There are also programmers who definately should be using python 3 for their > work. They know who they are. They do receive support in #python. > > -- > > In writing this email to python-dev, I have reviewed my logs of #python > specifically looking for the phrase 'python 3'. Here are some packages that > were named in the conversations: > > - py2exe > - cx_Freeze > - twisted > - PIL > - ctypes > - email > > I present this list because they are what programmers are coming to #python to > ask about, and that may be relevent to your discussion about python 3 ports. > Given the amount of interest this thread has generated I can't help wondering why it isn't more prominent in python.org content. Is the developer community completely disjoint with the web content editor community? If there is such a disconnect we should think about remedying it: a large "Python 2 or 3?" button could link to a reasoned discussion of the pros and cons as evinced in this thread. That way people will end up with the right version more often (and be writing Python 2 that will more easily migrate to Python 3, if they cannot yet use 3). There seems to be a perception that the PSF can help fund developments, and indeed Jesse Noller has made a small start with his sprint funding proposal (which now has some funding behind it). I think if it is to do so the Foundation will have to look for substantial new funding. I do not currently understand where this funding would come from, and would like to tap your developer creativity in helping to define how the Foundation can effectively commit more developer time to Python. GSoC and GHOP are great examples, but there is plenty of room for all sorts of initiatives that result in development opportunities. I'd like to help. 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 ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 5:37 PM, Steve Holden wrote: > Glyph Lefkowitz wrote: >> On Jun 19, 2010, at 5:02 PM, Terry Reedy wrote: > Which is yet another reason I don't think it would be productive to > attempt any kind of pre-emptive action against the #python team. They do > serve a very useful purpose, and there is reasoned logic behind their > position even if we might wish it were different. > > regards > Steve I'm one of them so I'm a bit biased, but I'd say the biggest argument is that it's not set in stone (I'm trying to fix it and the regulars have been nothing but cooperative). Nobody from the #python people realized this was a huge thing for people up until today. It's been up there for a long time, and it's becoming less and less defensible every passing day (and that's a good thing!), so we're basically debating what ought to change and when. It's not really a matter of disliking, it's more of a matter of "um, it's still up there because nobody thought it had to go" :-) FWIW: I think a separate #python3 channel would be a really bad idea. thanks Laurens ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Status update: Topic now says: NO LOL | Don't paste in here: use http://paste.pocoo.org/ | http://pound-python.org/ | Include Python version in questions | 2.x or 3.x? http://tinyurl.com/py2or3 | Tutorial: http://docs.python.org/tut/ | FAQ: http://effbot.org/pyfaq/ | New Programmer? Read http://tinyurl.com/thinkcspy2e | #python.web #wsgi #python-fr #python.de #python-es #python.tw #python.pl #python-br #python-nl Right now the shorturl points to the excellent http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html by Nick Efford, until we get the Py2.x vs Py3.x page as suggested above done, which will hopefully be in the next few hours. pound-python.org not touched yet because 1) the appropriate person isn't available right now 2) it's not as pressing a matter as the other thing. Thanks again for everyone's input on all of python-dev, #python, #python-offtopic, Laurens ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
On Mon, 21 Jun 2010 01:00:03 +0900 Steve Holden wrote: > > Given the amount of interest this thread has generated I can't help > wondering why it isn't more prominent in python.org content. Is the > developer community completely disjoint with the web content editor > community? Sorry for a naive question, but what is the web content editor community? 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] #Python3 ! ? (was Python Library Support in 3.x)
Laurens Van Houtven wrote: > Status update: > > Topic now says: > > NO LOL | Don't paste in here: use http://paste.pocoo.org/ | > http://pound-python.org/ | Include Python version in questions | 2.x or 3.x? > http://tinyurl.com/py2or3 | Tutorial: http://docs.python.org/tut/ | FAQ: > http://effbot.org/pyfaq/ | New Programmer? Read > http://tinyurl.com/thinkcspy2e | #python.web #wsgi #python-fr #python.de > #python-es #python.tw #python.pl #python-br #python-nl > > Right now the shorturl points to the excellent > http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html by Nick Efford, > until we get the Py2.x vs Py3.x page as suggested above done, which > will hopefully be in the next few hours. > > pound-python.org not touched yet because 1) the appropriate person > isn't available right now 2) it's not as pressing a matter as the > other thing. > > > Thanks again for everyone's input on all of python-dev, #python, > #python-offtopic, > Laurens > And thanks for engaging so directly and responsively. The Python community has impressed me again with its maturity. 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 ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
Am 20.06.2010 19:01, schrieb Antoine Pitrou: On Mon, 21 Jun 2010 01:00:03 +0900 Steve Holden wrote: Given the amount of interest this thread has generated I can't help wondering why it isn't more prominent in python.org content. Is the developer community completely disjoint with the web content editor community? Sorry for a naive question, but what is the web content editor community? I think he's talking about the editors of www.python.org. 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] #Python3 ! ? (was Python Library Support in 3.x)
Am 20.06.2010 18:20, schrieb Laurens Van Houtven: 2.x or 3.x? http://tinyurl.com/py2or3 If you are interested, we could host any material that somebody would want to provide on http://python.org/py2or3 (which would be one letter shorter :-). We could also make this a redirect. 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] email package status in 3.X
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? ___ 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] email package status in 3.X
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?" ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Laurens Van Houtven writes: > > The only situation in which I'd direct someone new to programming > > away from Python 3 would be if they had a specific need to use a > > library that wasn't yet supported. > > Yeah, I think the reason for that rule is that the majority of people > asking about new software actually start or end up in this category. I think that the most experienced people have absurdly high standards for "support" compared to those new to programming. I hope they check their advice against the real requirements of the new programmer. > Usually it's because they want to do something that people have > already solved, If they're new to programming, they're already in adventure mode. Why not point out the Road Less Traveled? That will make all the difference. Of course you should point out that it's going to be bumpier, and of course that is likely to push the majority of practical folks back to Python 2. But some of them are likely to be willing to endure a bit of frustration, especially if they're told that their bug reports will be listened to seriously on python-dev (given help from an experienced hand in formatting them!) > A possible solution is that we suggest that people, instead of > rolling their own thing from scratch, help to port an existing good > 2.x lib to 3.x, or use 2.x? Exactly. Don't give them rose-colored glasses about porting, and warn that some are just plain broken (eg, because of inappropriate assumptions about bytes vs Unicode). But on the other hand, some will mostly work for them, and their bug reports on the corner cases will be helpful. > I don't think it's a good idea to start encouraging NIH in new > programmers :-) Agreed. ___ 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] email package status in 3.X
On Mon, 21 Jun 2010 02:30:17 +0900 "Stephen J. Turnbull" 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. ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
Laurens Van Houtven writes: > Also, I'm pretty sure nobody has ever said that Python 3.x was a > "failure", or anything like it. #python has claims that Python 3.x, as > a platform for building production apps, is a work in progress How about "Python 3 is a work in progress" for the topic? That seems to me to strike exactly the right balance, and encourage the interested to ask the right kind of question. ___ 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] email package status in 3.X
On Sun, 20 Jun 2010 14:26:28 +0200 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 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. ___ 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] email package status in 3.X
On Sun, Jun 20, 2010 at 5:26 AM, Giampaolo Rodolà wrote: > 2010/6/20 Steven D'Aprano : >> 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) ___ 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] email package status in 3.X
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. ___ 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] email package status in 3.X
On Sun, Jun 20, 2010 at 7:30 PM, Stephen J. Turnbull 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 ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 7:48 PM, Stephen J. Turnbull wrote: > Laurens Van Houtven writes: > > > Also, I'm pretty sure nobody has ever said that Python 3.x was a > > "failure", or anything like it. #python has claims that Python 3.x, as > > a platform for building production apps, is a work in progress > > How about "Python 3 is a work in progress" for the topic? That seems > to me to strike exactly the right balance, and encourage the > interested to ask the right kind of question. I think even that's a bit too loaded, as a sign of goodwill I think we're going to go with something completely neutral like "2.x vs 3.x". But I'm not going to argue that ad nauseam because it's really just bikeshedding. thanks for your input Laurens ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
At 01:00 AM 6/21/2010 +0900, Steve Holden wrote: If there is such a disconnect we should think about remedying it: a large "Python 2 or 3?" button could link to a reasoned discussion of the pros and cons as evinced in this thread. That way people will end up with the right version more often (and be writing Python 2 that will more easily migrate to Python 3, if they cannot yet use 3). +1 ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
> If there is such a disconnect we should think about remedying it: a > large "Python 2 or 3?" button could link to a reasoned discussion of the > pros and cons as evinced in this thread. That way people will end up > with the right version more often (and be writing Python 2 that will > more easily migrate to Python 3, if they cannot yet use 3). Me and ikanobori (Simon De Vlieger) are working on this. Laurens ___ 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] email package status in 3.X
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. 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. >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 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. ___ 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] email package status in 3.X
At 10:57 AM 6/20/2010 -0700, Guido van Rossum wrote: 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. Actually, I would say that it's more that (in the network protocol case) we *have* bytes, some of which we would like to *treat* as text, yet do not wish to constantly convert back and forth to full-blown unicode -- especially since the protocols themselves designate ASCII or latin-1 at the transport layer (sometimes with odder encodings above, but these already have to be explicitly dealt with by existing code). While reading over this thread, I'm wondering whether at least my (WSGI-related) problems in this area would be solved by the availability of a type (say "bstr") that was simply a wrapper providing string-like behavior over an underlying bytes, byte array, or memoryview, that would produce objects of compatible type when combined with strings (by encoding them to match). Then, I could wrap bytes with it to pass them to string operations, and then feed them back into everything else. The bstr type ideally would be directly compatible with bytes I/O, or at least have a .bytes attribute that would be. It seems like that would reduce WSGI porting issues quite a bit, since it would mostly consist of throwing extra bstr() calls in where things are breaking, and maybe grabbing the .bytes attribute for I/O. This approach would still be explicit as to what types you're working with, but would not require O(n) *conversions* at every interaction boundary. It would be limited, of course, to single-byte encodings with all characters (0-255) valid. OTOH, maybe there should just be a bytestrings module with bytestrings.ascii and bytestrings.latin1, and between the two that should cover the network protocol needs quite well. Actually, if the Python 3 str() constructor could do O(1) conversion for the latin-1 case (i.e., just wrapped the underlying bytes), I would just put, "bstr = lambda x: str(x,'latin-1')" at the top of my programs and have roughly the same effect. This idea is still a bit half-baked, but a more baked version might be just the ticket for porting stuff that used str to work with bytes in 2.x, if only because writing, e.g.: newurl = bstr(urljoin(bstr(base), 'subdir')) seems so much saner than writing *this* everywhere: newurl = str(urljoin(str(base, 'latin-1'), 'subdir'), 'latin-1') It is perhaps a bit late to propose this idea, since ideally we would also want to use it in 2.x to aid porting. But I'm curious if any other people here experiencing byte/unicode woes in relation to network protocols would find this a solution to their chief frustration. (i.e., that the stdlib often insists now on strings, where effectively bytes were usable before, and thus one must do conversions both coming and going.) ___ 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
[Python-Dev] issue 8959
We currently have one release blocker for 2.7: http://bugs.python.org/issue8959 It is a Windows and a ctypes regression. As far as I can tell, the offending revision could just be reverted but it does not merge cleanly. Can anyone offer more expertise? -- 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] #Python3 ! ? (was Python Library Support in 3.x)
Am 20.06.2010 19:48, schrieb Stephen J. Turnbull: Laurens Van Houtven writes: > Also, I'm pretty sure nobody has ever said that Python 3.x was a > "failure", or anything like it. #python has claims that Python 3.x, as > a platform for building production apps, is a work in progress How about "Python 3 is a work in progress" for the topic? I wouldn't say that, either - not more than Python 2 was a work in progress over the last 10 years. 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 7:42 PM, Stephen J. Turnbull wrote: > Laurens Van Houtven writes: > > Yeah, I think the reason for that rule is that the majority of people > > asking about new software actually start or end up in this category. > > I think that the most experienced people have absurdly high standards > for "support" compared to those new to programming. I hope they check > their advice against the real requirements of the new programmer. Maybe. I'm not very sure about this: for example quite a few parts in Twisted are pretty hazy voodoo magic to me ;-) I actually recommend the high standards stuff to newbies specifically because it's high standards. If I meet some bug, I can probably work around it, but I imagine that it'd be much more frustrating for a newbie to come into contact with a bunch of stuff that really isn't very well polished or supported? I could be wrong. > > Usually it's because they want to do something that people have > > already solved, > > If they're new to programming, they're already in adventure mode. Why > not point out the Road Less Traveled? That will make all the > difference. Of course you should point out that it's going to be > bumpier, and of course that is likely to push the majority of > practical folks back to Python 2. Three big reasons I can think of: because it doesn't always exist, because even if it does exist we don't always know about it, and because people actually helping people in #python would be far less adept at helping people with it :-) We have a bunch of people that end up doing their own thing anyway now, that just means we can't be as helpful later when they have more questions. > But some of them are likely to be > willing to endure a bit of frustration, especially if they're told > that their bug reports will be listened to seriously on python-dev > (given help from an experienced hand in formatting them!) Maybe that would help, yeah. We have a bunch of people now that start and then give up. They don't port, because they can't be bothered. They just start from scratch. > > A possible solution is that we suggest that people, instead of > > rolling their own thing from scratch, help to port an existing good > > 2.x lib to 3.x, or use 2.x? > > Exactly. Don't give them rose-colored glasses about porting, and warn > that some are just plain broken (eg, because of inappropriate > assumptions about bytes vs Unicode). But on the other hand, some will > mostly work for them, and their bug reports on the corner cases will > be helpful. I think that's usually more effort than new programmers are willing to put in, people tend to underestimate the cost of developing something from scratch in my experience. But sure, we all agree it's a good idea, so let's put it in the official thing about 2.x vs 3.x :) > > I don't think it's a good idea to start encouraging NIH in new > > programmers :-) > > Agreed. I think we're kind of getting into the territory of personal preferences here. Thanks for your input, Laurens ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Sun, Jun 20, 2010 at 9:10 PM, "Martin v. Löwis" wrote: > Am 20.06.2010 19:48, schrieb Stephen J. Turnbull: >> How about "Python 3 is a work in progress" for the topic? > > I wouldn't say that, either - not more than Python 2 was a work in progress > over the last 10 years. > > Regards, > Martin Yeah, this is why I really like a completely neutral topic. thanks, Laurens ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
On 20/06/2010 17:00, Steve Holden wrote: [snip...] -- In writing this email to python-dev, I have reviewed my logs of #python specifically looking for the phrase 'python 3'. Here are some packages that were named in the conversations: - py2exe - cx_Freeze - twisted - PIL - ctypes What is the problem with ctypes in Python 3? Are there particular problems with it - it is part of the standard library and available right? - email I present this list because they are what programmers are coming to #python to ask about, and that may be relevent to your discussion about python 3 ports. Given the amount of interest this thread has generated I can't help wondering why it isn't more prominent in python.org content. Is the developer community completely disjoint with the web content editor community? The "web content editor community" (the python.org webmasters) is really just a handful of people. I did suggest a few weeks ago (in response to an enquiry about why there was no guide to choosing between Python 2 and 3 easily visible on the website) that we add or prominently link to a page with information like this. There was no response but I do think it would be a good idea. If there is such a disconnect we should think about remedying it: a large "Python 2 or 3?" button could link to a reasoned discussion of the pros and cons as evinced in this thread. That way people will end up with the right version more often (and be writing Python 2 that will more easily migrate to Python 3, if they cannot yet use 3). Yep. All the best, Michael Foord There seems to be a perception that the PSF can help fund developments, and indeed Jesse Noller has made a small start with his sprint funding proposal (which now has some funding behind it). I think if it is to do so the Foundation will have to look for substantial new funding. I do not currently understand where this funding would come from, and would like to tap your developer creativity in helping to define how the Foundation can effectively commit more developer time to Python. GSoC and GHOP are great examples, but there is plenty of room for all sorts of initiatives that result in development opportunities. I'd like to help. regards Steve -- 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] Python Library Support in 3.x (Was: email package status in 3.X)
On Sun, Jun 20, 2010 at 12:00 PM, Steve Holden wrote: ...snip >> > Given the amount of interest this thread has generated I can't help > wondering why it isn't more prominent in python.org content. Is the > developer community completely disjoint with the web content editor > community? Yes. > If there is such a disconnect we should think about remedying it: a > large "Python 2 or 3?" button could link to a reasoned discussion of the > pros and cons as evinced in this thread. That way people will end up > with the right version more often (and be writing Python 2 that will > more easily migrate to Python 3, if they cannot yet use 3). Yes; the website needs to change. > There seems to be a perception that the PSF can help fund developments, > and indeed Jesse Noller has made a small start with his sprint funding > proposal (which now has some funding behind it). I think if it is to do > so the Foundation will have to look for substantial new funding. I do > not currently understand where this funding would come from, and would > like to tap your developer creativity in helping to define how the > Foundation can effectively commit more developer time to Python. The good news is that I've already had a few potential companies approach me to inquire as to the possibility of sponsoring porting sprints for specific itches they have. I am going to continue to encourage this on my end, as well as redirecting them to direct PSF donations as they arise. I suspect; if we were to keep pushing the concept of sponsored sprints / bounties on Python 3 library porting, we could see things pick up donation wise. I've long suspected that there are companies out there who do have funds, but lack a target, and don't see a general PSF donation as directly beneficial to their goals (although we will continue to work to convince them otherwise). > GSoC and GHOP are great examples, but there is plenty of room for all > sorts of initiatives that result in development opportunities. I'd like > to help. Quick, off the seat of my pants idea - let's start by encouraging and advertising sponsored sprints in the vein I've outlined in my existing approved proposal. Once we know how to allow companies to donate directly into a fund for direct improvement / porting, we provide them a target which allows them to see measurable outcomes. Just a thought Jesse ___ 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] email package status in 3.X
On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby wrote: > At 10:57 AM 6/20/2010 -0700, Guido van Rossum wrote: >> >> 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. > > Actually, I would say that it's more that (in the network protocol case) we > *have* bytes, some of which we would like to *treat* as text, yet do not > wish to constantly convert back and forth to full-blown unicode -- > especially since the protocols themselves designate ASCII or latin-1 at the > transport layer (sometimes with odder encodings above, but these already > have to be explicitly dealt with by existing code). > > While reading over this thread, I'm wondering whether at least my > (WSGI-related) problems in this area would be solved by the availability of > a type (say "bstr") that was simply a wrapper providing string-like behavior > over an underlying bytes, byte array, or memoryview, that would produce > objects of compatible type when combined with strings (by encoding them to > match). > > Then, I could wrap bytes with it to pass them to string operations, and then > feed them back into everything else. The bstr type ideally would be > directly compatible with bytes I/O, or at least have a .bytes attribute that > would be. > > It seems like that would reduce WSGI porting issues quite a bit, since it > would mostly consist of throwing extra bstr() calls in where things are > breaking, and maybe grabbing the .bytes attribute for I/O. > > This approach would still be explicit as to what types you're working with, > but would not require O(n) *conversions* at every interaction boundary. It > would be limited, of course, to single-byte encodings with all characters > (0-255) valid. > > OTOH, maybe there should just be a bytestrings module with bytestrings.ascii > and bytestrings.latin1, and between the two that should cover the network > protocol needs quite well. > > Actually, if the Python 3 str() constructor could do O(1) conversion for the > latin-1 case (i.e., just wrapped the underlying bytes), I would just put, > "bstr = lambda x: str(x,'latin-1')" at the top of my programs and have > roughly the same effect. > > This idea is still a bit half-baked, but a more baked version might be just > the ticket for porting stuff that used str to work with bytes in 2.x, if > only because writing, e.g.: > > newurl = bstr(urljoin(bstr(base), 'subdir')) > > seems so much saner than writing *this* everywhere: > > newurl = str(urljoin(str(base, 'latin-1'), 'subdir'), 'latin-1') > > It is perhaps a bit late to propose this idea, since ideally we would also > want to use it in 2.x to aid porting. But I'm curious if any other people > here experiencing byte/unicode woes in relation to network protocols would > find this a solution to their chief frustration. (i.e., that the stdlib > often insists now on strings, where effectively bytes were usable before, > and thus one must do conversions both coming and going.) > I hate to reply with a simple +1 - but I've heard this pain and proposal from a frightening number of people, something which allowed you to use bytes with some of the sting methods would go a really long way to solving a lot of peoples python 3 pain. I don't relish the idea that once people start moving over, there might be a billion implementations of "things like this". jesse ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On 6/20/2010 6:35 AM, Laurens Van Houtven wrote: I'm one of the active people in #python that some people dislike for behavior with respect to Python 3. As I wrote, I disliked the observable, written behavior, now changed. You are obviously a fine person. We both love Python and have both contributed time for years to helping others with Python. The premise for this branch thread was: IF #python is really #python2 and somewhat anti-Python3, THEN (and only then), maybe we need a #python3. I am delighted that you have already refuted the premise with a new, much improved, splash topic. I now feel free to ask Python3 questions on the existing channel -- things like "Is issue applicable to Python3?" -- as I work on reviewing tracker issues. In that respect, this thread is finished for me. But I hope it is just the start of better cooperation and communication. Just a few notes in addition to other responses. First of all I'd like to defuse the situation. Excellently done. Also, I'm pretty sure nobody has ever said that Python 3.x was a "failure", or anything like it. I have no idea what has been said by you or anyone on #python, but people *have* posted on both python-list and here on py-dev things like "Python3 is not ready for use. It is a failure. Do not use it." (any of that sound familiar? ;-) and even "Python3 should be scrapped!". I am relieve that you have disassociated yourself and #python from such sentiments. --- On newbies and version choice: I agree with Nick Efford that people using Python to learn about programming may be better off with Python3. I am using a subset of Python3 in a book on algorithms for the reasons he gave and others. Not even mentioned so far in this thread is the availability of unicode identifiers for people with non-Latin alphabets. Of course, Asian schoolkids are unlikely to request help on #python. And the point about suggesting Python2 because that is what you all are good at helping with, is well taken. I do think people learning Python2 now should have a Python3-aware guide to doing so. This > In the mean while, we encourage people to write code that will be easy > to port and behave well in 3.x: new-style classes, don't use eager > versions when the Py3k default is lazy and you don't actually need the > eager thing, use as many third party libraries as possible (the idea > being that this would minimize effort needed to make the switch on the > grand scale of things), use absolute imports always (and only explicit > relative, but it's discouraged), always have a full unit test suite. is a good start. I think something like that would be good for the #python web page, or added to python.org somewhere. Terry Jan Reedy ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
On 6/20/2010 3:59 PM, Jesse Noller wrote: I suspect; if we were to keep pushing the concept of sponsored sprints / bounties on Python 3 library porting, we could see things pick up donation wise. I've long suspected that there are companies out there who do have funds, but lack a target, and don't see a general PSF donation as directly beneficial to their goals (although we will continue to work to convince them otherwise). Universities **love** unrestricted donations to their general fund. But they bow to human nature and accept and even seek all kinds of targeted donations: buildings, rooms, departments, centers, institutes, programs, professorships, scholarships, research projects, curriculum developments projects, and so on. (Of course, the desire to target on the part of donors is also in part a recognition of human nature, that unrestricted funds might be used frivolously or even in a way that the donor considers obnoxious.) I think it would be great So I think it good that you/PSF try doing the same. And do not ignore individuals. Terry Jan Reedy ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In reply to the recent post by Laurens and the vow I made to change the text which is presented on the python-commandments domain I have asked Laurens to write a new text on the subject. This message is a heads up to let all of you know that this new article is now available on the following URL: http://python-commandments.org/python3.html This article will probably be the featured article on #python's /topic regarding Python 2 or 3. I also read some remarks about possibly having an official article up on the Python website and in case that happens that will take the place of this article. Regards, Simon de Vlieger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMHoQxAAoJEBBSHP7i+JXfGdUP/3NsUuMAJ2DONJZE4AbQIx5G n7UE/SD0teZpyrYYIzV/PI1m40xz5XBe+zJyNfGN7m+MNoW7lGIxHgBoTB5CU6eE 10LeNy2qR9eqRQ/NZ+t8GJul4zuGIocPglDqCX/M6KtFCmtDsgSgbLaMFEgI4lRs vZr9I9hUX9E1r+9T50uxo/YHQm+QW/HIYVks15nOoeUalkhxlQF67vvzH8/lds/F sl5DxXe/zo287GeOIjpDNI/+0KJtUTLop4S/cpVxxA5eNX9lgGztq1wmKCMQmKcB FS/WfQomyEhZhTk4CtIMQ7HM51bGUHwDeoO8qIOrayTM8ucoruO0QyzmZM0yxoDY G+GVYabTKKp9ICDaUvOMxYpRnuz/Xb10nb9HphutQ03cjR28bJLR8nuLUBmIzcJK ICXVIcV11hD01hzGWBJ7llQeoHl9ykaZu54PqpnZ/gdUrBVJ7VRItb5b4wP/PTwJ frtNvnVwBnuR9wfQmCV9Do1UVTAVUqjFRpoBujIgSaZCa1wyF5U+8eHVD26u8lDj +Hva28S/MggzIbc9x3/yv070204JaZVD1Q6fR5cSWdCMHgEDnwCmRjqlqLRW7zqS al4/JaxDiqa7RrB8+liFDijtqopy7K6a3vDK4BBHuyqWmJ9lGqVJzC0ynRE6DV7N 4+lJCEF9qLW++QgjHXR2 =qRiB -END 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] #Python3 ! ? (was Python Library Support in 3.x)
Glad to hear the efforts are so appreciated. Unfortunately not everyone agrees, but I'm beginning to think that's the tragedy of internet politics :) On Sun, Jun 20, 2010 at 10:34 PM, Terry Reedy wrote: > On 6/20/2010 6:35 AM, Laurens Van Houtven wrote: > I have no idea what has been said by you or anyone on #python, but people > *have* posted on both python-list and here on py-dev things like "Python3 is > not ready for use. It is a failure. Do not use it." (any of that sound > familiar? ;-) and even "Python3 should be scrapped!". I am relieve that you > have disassociated yourself and #python from such sentiments. I can understand how people coming to #python might have thought that, in retrospect. I just wanted to make that part clear :) As for the "Python 3.x is a failure" people, I just tune those out, and if they're trolling about it on IRC, ban them. > On newbies and version choice: I agree with Nick Efford that people using > Python to learn about programming may be better off with Python3. I am using > a subset of Python3 in a book on algorithms for the reasons he gave and > others. Not even mentioned so far in this thread is the availability of > unicode identifiers for people with non-Latin alphabets. I think the difference here is probably the focus. I think you're more interested in teaching people Python in a more academic context: basically teaching CS through Python. #python, on the other hand, is trying to help people build practical tools where the CS is often an afterthought (though not as much as it is in other programming language channels which I won't name). >> In the mean while, we encourage people to write code that will be easy >> to port and behave well in 3.x: new-style classes, don't use eager >> versions when the Py3k default is lazy and you don't actually need the >> eager thing, use as many third party libraries as possible (the idea >> being that this would minimize effort needed to make the switch on the >> grand scale of things), use absolute imports always (and only explicit >> relative, but it's discouraged), always have a full unit test suite. > > is a good start. I think something like that would be good for the #python > web page, or added to python.org somewhere. Yeah, it's actually extremely prevalent, it's just not voiced anywhere, we could probably put it up somewhere. It's sort of up in the pound-python page but it's well-hidden in tongue-in-cheek, as Antoine pointed out :) > Terry Jan Reedy > Laurens ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
That's not actually up just yet, I'd like people to review it, personally I think it's still a tad bit biased towards Py3k. Until then I'm keeping the Py3.x document by Nick Efford up there. Thanks for your continued participation and seemingly endless patience, Laurens ___ 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] email package status in 3.X
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 ___ 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] email package status in 3.X
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 ___ 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
[Python-Dev] bytes / unicode
On Sun, 20 Jun 2010 14:40:56 -0400 "P.J. Eby" wrote: > > Actually, I would say that it's more that (in the network protocol > case) we *have* bytes, some of which we would like to *treat* as > text, yet do not wish to constantly convert back and forth to > full-blown unicode Well, then why don't you just stick with a bytes object? > While reading over this thread, I'm wondering whether at least my > (WSGI-related) problems in this area would be solved by the > availability of a type (say "bstr") that was simply a wrapper > providing string-like behavior over an underlying bytes, byte array, > or memoryview, that would produce objects of compatible type when > combined with strings (by encoding them to match). This really sounds horrible. Python 3 was designed precisely to discourage ad hoc mixing of bytes and unicode. > Actually, if the Python 3 str() constructor could do O(1) conversion > for the latin-1 case (i.e., just wrapped the underlying bytes), I > would just put, "bstr = lambda x: str(x,'latin-1')" at the top of my > programs and have roughly the same effect. Did you do any measurements that show that latin-1 decoding (hardly a complicated task) introduces a performance regression in Web frameworks in 3.x? > seems so much saner than writing *this* everywhere: > > newurl = str(urljoin(str(base, 'latin-1'), 'subdir'), 'latin-1') urljoin already returns an str object. Why do you want to decode it again? ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On Mon, Jun 21, 2010 at 7:12 AM, Simon de Vlieger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In reply to the recent post by Laurens and the vow I made to change the text > which is presented on the python-commandments domain I have asked Laurens to > write a new text on the subject. > > This message is a heads up to let all of you know that this new article is > now available on the following URL: > http://python-commandments.org/python3.html That's a fairly decent write-up in my opinion. As Laurens pointed, it trends towards the "use Python 3 if you can, Python 2 if you need to" point of view, which I personally think is the right spin to be putting on this issue, but obviously opinions will vary on that front. About the only specific wording tweak I would suggest is that "little regard for backwards compatibility" should be phrased as "less regard for backwards compatibility". There were still quite a few ideas we rejected as gratuitously incompatible, even for Py3k (the eventual decision to retain old-style string formatting comes to mind). 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] bytes / unicode
2010/6/20 Antoine Pitrou : > On Sun, 20 Jun 2010 14:40:56 -0400 > "P.J. Eby" wrote: >> >> Actually, I would say that it's more that (in the network protocol >> case) we *have* bytes, some of which we would like to *treat* as >> text, yet do not wish to constantly convert back and forth to >> full-blown unicode > > Well, then why don't you just stick with a bytes object? There are not many tools for treating bytes as text. -- 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] email package status in 3.X
On 6/20/2010 1:30 PM, Stephen J. Turnbull wrote: The topic on #python seems unlikely to change at this point I just verified that, thanks to Laurens and whoever, it has been. It is now rather good. Terry Jan Reedy ___ 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] email package status in 3.X
On Sun, Jun 20, 2010 at 11:30 PM, Terry Reedy 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 ___ 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] email package status in 3.X
> I hate to reply with a simple +1 - but I've heard this pain and
> proposal from a frightening number of people, something which allowed
> you to use bytes with some of the sting methods would go a really long
> way to solving a lot of peoples python 3 pain. I don't relish the idea
> that once people start moving over, there might be a billion
> implementations of "things like this".
My concern with it would be creating the temptation to use these new
objects that can't tolerate multibyte or variable character length
encodings when the general string type was more relevant (thus to some
degree perpetuating Python 2.x issues with incomplete Unicode
handling).
Perhaps if people could identify which specific string methods are
causing problems? In 3.2, there really aren't that many differences
between the available methods for strings and bytes:
>>> set(dir(str)) - set(dir(bytes))
{'isprintable', 'format', '__mod__', 'encode', 'isidentifier',
'_formatter_field_name_split', 'isnumeric', '__rmod__', 'isdecimal',
'_formatter_parser'}
>>> set(dir(bytes)) - set(dir(str))
{'decode', 'fromhex'}
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] email package status in 3.X
On 6/20/2010 4:10 PM, Jesse Noller wrote: On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby wrote: While reading over this thread, I'm wondering whether at least my (WSGI-related) problems in this area would be solved by the availability of a type (say "bstr") that was simply a wrapper providing string-like behavior over an underlying bytes, byte array, or memoryview, that would produce objects of compatible type when combined with strings (by encoding them to match). I hate to reply with a simple +1 - but I've heard this pain and proposal from a frightening number of people, something which allowed you to use bytes with some of the sting methods would go a really long way to solving a lot of peoples python 3 pain. I don't relish the idea that once people start moving over, there might be a billion implementations of "things like this". Given that the 3.x bytes and bytearray classes do retain text methods like .capitalize(), which are meaningless for arbitrary binary data, it is not clear to me what you are asking for or what problem a new class would solve. I am curious though. Terry Jan Reedy ___ 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] email package status in 3.X
On Jun 20, 2010, at 6:21 PM, Terry Reedy wrote: On 6/20/2010 4:10 PM, Jesse Noller wrote: On Sun, Jun 20, 2010 at 2:40 PM, P.J. Eby wrote: While reading over this thread, I'm wondering whether at least my (WSGI-related) problems in this area would be solved by the availability of a type (say "bstr") that was simply a wrapper providing string- like behavior over an underlying bytes, byte array, or memoryview, that would produce objects of compatible type when combined with strings (by encoding them to match). I hate to reply with a simple +1 - but I've heard this pain and proposal from a frightening number of people, something which allowed you to use bytes with some of the sting methods would go a really long way to solving a lot of peoples python 3 pain. I don't relish the idea that once people start moving over, there might be a billion implementations of "things like this". Given that the 3.x bytes and bytearray classes do retain text methods like .capitalize(), which are meaningless for arbitrary binary data, it is not clear to me what you are asking for or what problem a new class would solve. I am curious though. Ask the web-sig and wsgi folks for starters. I know they've experienced non-zero pain. ___ 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] bytes / unicode
Also, url's are bytestrings - by definition; if the standard library has made them unicode objects in 3, I expect a lot of pain in the webserver space. -Rob ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
On 6/20/2010 5:53 PM, Nick Coghlan wrote: On Mon, Jun 21, 2010 at 7:12 AM, Simon de Vlieger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In reply to the recent post by Laurens and the vow I made to change the text which is presented on the python-commandments domain I have asked Laurens to write a new text on the subject. That's a fairly decent write-up in my opinion. As Laurens pointed, it trends towards the "use Python 3 if you can, Python 2 if you need to" point of view, which I personally think is the right spin to be putting on this issue, but obviously opinions will vary on that front. About the only specific wording tweak I would suggest is that "little regard for backwards compatibility" should be phrased as "less regard for backwards compatibility". There were still quite a few ideas we rejected as gratuitously incompatible, even for Py3k (the eventual decision to retain old-style string formatting comes to mind). I have much the same opinion, and the ame suggestion, as Nick. People do not usually see the proposals that were rejected and the changes not made in 3.0. For those who *do* wish, there are about 25 items listed at http://www.python.org/dev/peps/pep-3099/ Things that will Not Change in Python 3000 Nick listed one thing not on the list. Eliminating the duplicate method names in the unittest module is another. (In isolation, most everyone was in favor. Guido's reason for leaving the duplication: porting 2 to 3 is much easier with a good (and stable) test suite. Therefore, cleaning up unittest and possibly breaking test suites, even with a 2to3 conversion, would not be a good idea.) Terry Jan Reedy ___ 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] Mercurial
On Sat, Jun 19, 2010 at 05:42, Antoine Pitrou wrote: > On Sat, 19 Jun 2010 17:43:02 +0530 > Senthil Kumaran wrote: >> On Sat, Jun 19, 2010 at 01:51:04PM +0200, Antoine Pitrou wrote: >> > FWIW, the EOL extension is now part of Mercurial: >> > http://mercurial.selenic.com/wiki/EolExtension >> >> Should we all move soon now? >> Any target date you have in mind, Antoine? > > I should point out that I am in no way responsible for the migration. > I think Dirkjan and Brett said they would tackle this after the 2.7 > release. But they'd better answer by themselves :) WIth the eol extension dealt with, it means all hold-ups are on python-dev's end, not Mercurial's which is good. As for what is left exactly, Dirkjan can answer better than I can; at this point I am simply the guy trying to help keep the momentum going while not doing any technical work. ___ 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] #Python3 ! ? (was Python Library Support in 3.x)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20 jun 2010, at 23:53, Nick Coghlan wrote: About the only specific wording tweak I would suggest is that "little regard for backwards compatibility" should be phrased as "less regard for backwards compatibility". There were still quite a few ideas we rejected as gratuitously incompatible, even for Py3k (the eventual decision to retain old-style string formatting comes to mind). I have changed this text to include the wording tweak. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMHp7DAAoJEBBSHP7i+JXfSkMQANw1SNroVYNkDUEJCIKtdKEJ HyGBMZpG0liUfqVf8YAjNRYEscpWtsS2Inh8PBlTUwo5OTZPmbggJVZGO17E7Z8k ld9TASppKraNZL62nBno5us2rnc2aUJL6GCaKPL1SQkk8GG1yLAV57j8d4R50QZS 4S7ogFPgVveM4VYEZXaZrlHpzlHjdh8xjq7f4Pl8IKJQZm6uOorK+sL+jiw0DauA UEJ53rx0agy8GRwtnOY7XvqP0lgXLfZ/axTW9e6FkKXBcHYv3qdEAvdC3wyF9OKJ nSNo7vIj4z24V7x9WQdIcc2wifHGPqSBSfnUc4Y3TPAaPLAjlX3HX3C4J+iFbI4/ c6VIm/OSPhcuclV0IgTJGvDOoyVlxTXFnOhOobXFI3KcAtCMQw5Y9gzx+4f5nahJ YMlu54lFhqMsBzsTMlYcispEbbAuban4aZH7JAZ645F/AMzGqiTUZyHgD+A+i+9P Ctu7DStT4tI/ZHcsqjnSkmpLxFhr3kNZct71aS22xOpm4MBAXmPEFYa2a/LpozHi pDhuKJbwNc/+lbgiK267IP+V2pfKQ73qMQhn6hq0IPAgBXNu8fHJ6af6bygmIr/S sK/0zddz3C2qCgqHmYGBwYfrmQB0fgM4ic9Zi2I9/flH+6cLolhSHkOqGkH1m0DQ totdE00iTLVuy6VEmMmm =NcT9 -END 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] #Python3 ! ? (was Python Library Support in 3.x)
Okay cool, we fixed it: http://python-commandments.org/python3.html People are otherwise happy with the text? Thanks for your continued input, Laurens ___ 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] bytes / unicode
On 6/20/2010 5:55 PM, Benjamin Peterson wrote: 2010/6/20 Antoine Pitrou: On Sun, 20 Jun 2010 14:40:56 -0400 "P.J. Eby" wrote: Actually, I would say that it's more that (in the network protocol case) we *have* bytes, some of which we would like to *treat* as text, yet do not wish to constantly convert back and forth to full-blown unicode Well, then why don't you just stick with a bytes object? There are not many tools for treating bytes as text. If one writes a function (most easily in Python) 1. in terms of the methods and operations shared by unicode and bytes, which is nearly all of them, and 2. does not gratuitously (and dare I say, unpythonically) do a class check to unnecessarily exclude one or the other, and 3. does not specialize by assuming only one of the possible values for type-specific constants, such as number of chars/codes, and 4. does not do something unicode specific such as normalization, then the function should be agnostic and operate generically. I think there was some temptation to be 'pure' and limit text methods to str and enforce the decode-manipulate-encode paradigm (which is extremely common in various forms, and nothing unusual). But for practicality and efficiency, that was not done. Do you have in mind any tools that could and should operate on both, but do not? (I realize that at the C level, code is not just specialized to 'unicode', but to 2-byte versus 4-byte representations.) Terry Jan Reedy ___ 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] email package status in 3.X
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
___
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] bytes / unicode
At 07:33 PM 6/20/2010 -0400, Terry Reedy wrote: Do you have in mind any tools that could and should operate on both, but do not? From http://mail.python.org/pipermail/web-sig/2009-September/004105.html : """The problem which arises is that unquoting of URLs in Python 3.X stdlib can only be done on unicode strings. If though a string contains non UTF-8 encoded characters it can fail.""" I don't have any direct experience with the specific issue demonstrated in that post, but in the context of the discussion as a whole, I understood the overall issue as "if you pass bytes to certain stdlib functions, you might get back unicode, an explicit error, or (at least in the case shown above) something that's just plain wrong." ___ 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] email package status in 3.X
At 08:08 AM 6/21/2010 +1000, Nick Coghlan wrote:
Perhaps if people could identify which specific string methods are
causing problems?
__getitem__(int) returns an integer rather than a bytestring, so
anything that manipulates individual characters can't be given bytes
and have it work.
That was one of the key differences I had in mind for a bstr type,
apart from designing it to coerce normal strings to bstrs in
cross-type operations, and to allow O(1) "conversion" to/from bytes.
Another randomly chosen byte/string incompatibility (Python 3.1; I
don't have 3.2 handy at the moment):
>>> os.path.join(b'x','y')
Traceback (most recent call last):
File "", line 1, in
File "c:\Python31\lib\ntpath.py", line 161, in join
if b[:1] in seps:
TypeError: Type str doesn't support the buffer API
>>> os.path.join('x',b'y')
Traceback (most recent call last):
File "", line 1, in
File "c:\Python31\lib\ntpath.py", line 161, in join
if b[:1] in seps:
TypeError: 'in ' requires string as left operand, not bytes
Ironically, it seems to me that in trying to make the type
distinction more rigid, Py3K fails in this area precisely because it
is not a rigidly typed language in the Java or Haskell sense: i.e.,
os.path.join doesn't say, "I need two stringlike objects of the *same
type*", not even in its docstring.
At least in Java, you would either implement a "path" type with
coercions from bytes and strings, or you'd have a class with
overloaded methods for handling join operations on bytes and strings,
respectively, thereby avoiding this whole mess.
(Alas, this little example on the 'in' operator also shows that my
bstr effort would probably fail anyway, because there's no
'__rcontains__' (__lcontains__?) to allow it to override the str
type's __contains__.)
___
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] bytes / unicode
At 11:47 PM 6/20/2010 +0200, Antoine Pitrou wrote:
On Sun, 20 Jun 2010 14:40:56 -0400
"P.J. Eby" wrote:
>
> Actually, I would say that it's more that (in the network protocol
> case) we *have* bytes, some of which we would like to *treat* as
> text, yet do not wish to constantly convert back and forth to
> full-blown unicode
Well, then why don't you just stick with a bytes object?
Because the stdlib is not consistent in how well it handles bytes objects.
> While reading over this thread, I'm wondering whether at least my
> (WSGI-related) problems in this area would be solved by the
> availability of a type (say "bstr") that was simply a wrapper
> providing string-like behavior over an underlying bytes, byte array,
> or memoryview, that would produce objects of compatible type when
> combined with strings (by encoding them to match).
This really sounds horrible. Python 3 was designed precisely to
discourage ad hoc mixing of bytes and unicode.
Who said ad hoc mixing? The point is to have a simple way to ensure
that my bytes don't get implicitly converted to unicode, and
(ideally) don't have to get converted *back*, either.
The idea that by passing bytes to the stdlib, I randomly get back
either bytes or unicode (i.e. undocumentedly and inconsistently
between different stdlib APIs, as well as possibly dependent on
runtime conditions), is NOT "discouraging ad hoc mixing".
> seems so much saner than writing *this* everywhere:
>
> newurl = str(urljoin(str(base, 'latin-1'), 'subdir'), 'latin-1')
urljoin already returns an str object. Why do you want to decode it
again?
Ugh. I meant:
newurl = urljoin(str(base, 'latin-1'), 'subdir').encode('latin-1')
Which just goes to the point of how ridiculous it is to have to
convert things to strings and back again to use APIs that ought to
just handle bytes properly in the first place.
(I don't know if there are actually any problems in the case of
urljoin; I wasn't the person who originally brought up the "stdlib
not treating URLs as bytestrings in 3.x" issue on the
Web-SIG. Somewhere along the line I got the impression that urljoin
was one such API, but in researching the issue it looks like maybe
the canonical example was qsl_parse.)
It's possible that the stdlib situation has improved tremendously
since then, of course. I don't know if the bug was reported, or how
many remain.
And it's precisely the part where I don't know how many remain that
keeps me from doing more than idly thinking about porting any of my
libraries (let alone apps) to Python 3.x. The fact that the stdlib
itself has these sorts of issues raises major red flags to me about
whether the One Obvious Way has yet been found. If the stdlib
maintainers don't agree on the One Obvious Way, that seems even
worse. Or if there is such a Way, but nobody has documented its
practices yet, that's almost the same thing.
I also find it weird that there seem to be two camps on this subject,
one of which claims that All Is Well And There Is No Problem -- but I
do not recall seeing anyone who was in the "What do I do; this
doesn't seem ready" camp who switched sides and took the time to
write down what made them realize that they were wrong about there
being a problem, and what steps they had to take. The existence of
one or more such documents would certainly ease my mind, and I
imagine that of other people who are less waiting for others'
libraries, than for the stdlib (and/or language) itself to settle.
(Or more precisely, for it to be SEEN to have settled.)
___
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] bytes / unicode
On 6/20/2010 9:33 PM, P.J. Eby wrote:
At 07:33 PM 6/20/2010 -0400, Terry Reedy wrote:
Do you have in mind any tools that could and should operate on both,
but do not?
From http://mail.python.org/pipermail/web-sig/2009-September/004105.html :
Thank for the concrete examples in this and your other post.
I am cc-ing the author of the above.
"""The problem which arises is that unquoting of URLs in Python 3.X
stdlib can only be done on unicode strings.
Actually, I believe this is an encoding rather than bytes versus unicode
issue.
> If though a string
contains non UTF-8 encoded characters it can fail."""
Which is to say, I believe, if the ascii text in the (unicode) string
has a % encoding of a byte that that is not a legal utf-8 encoding of
anything.
The specific example is
>>> urllib.parse.parse_qsl('a=b%e0')
[('a', 'b�')]
where the character after 'b' is white ? in dark diamond, indicating an
error.
parse_qsl() splits that input on '=' and sends each piece to
urllib.parse.unquote
unquote() attempts to "Replace %xx escapes by their single-character
equivalent.". unquote has an encoding parameter that defaults to 'utf-8'
in *its* call to .decode. parse_qsl does not have an encoding parameter.
If it did, and it passed that to unquote, then
the above example would become (simulated interaction)
>>> urllib.parse.parse_qsl('a=b%e0', encoding='latin-1')
[('a', 'bà')]
I got that output by copying the file and adding "encoding-'latin-1'" to
the unquote call.
Does this solve this problem?
Has anything like this been added for 3.2?
Should it be?
I don't have any direct experience with the specific issue demonstrated
in that post, but in the context of the discussion as a whole, I
understood the overall issue as "if you pass bytes to certain stdlib
functions, you might get back unicode, an explicit error, or (at least
in the case shown above) something that's just plain wrong."
As indicated above, I so far think that the problem is with the
application of the new model, not the model itself.
Just for 'fun', I tried feeding bytes to the function.
>>> p.parse_qsl(b'a=b%e0')
Traceback (most recent call last):
File "", line 1, in
p.parse_qsl(b'a=b%e0')
File "C:\Programs\Python31\lib\urllib\parse.py", line 377, in parse_qsl
pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
TypeError: Type str doesn't support the buffer API
I do not know if that message is correct, but certainly trying to split
bytes with unicode is (now, at least) a mistake. This could be 'fixed'
by replacing the typed literals with expressions that match the type of
the input. But I am not sure if that is sensible since the next step is
to unquote and decode to unicode anyway. I just do not know the use case.
Terry Jan Reedy
___
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] bytes / unicode
On Sun, Jun 20, 2010 at 23:55, Benjamin Peterson wrote: > There are not many tools for treating bytes as text. Well, what tools would you need that can be used also on bytes? Bytes objects has a lot of the same methods like strings do, and that will cover 99% of the cases. Most text tools assume that the text really is text, and much of it doesn't make sense unless you've converted it to Unicode first. But most of the things you would need to do, such as in a web-server doesn't really involve treating the text as something linguistic, but it's a matter of replacing and escaping and such, and that could be done while the text is in bytes form.But the tools for that exists... Is there some specific tool that is missing? -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.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
