Re: [Python-Dev] RELEASED Python 3.0 final
Bill Janssen wrote: > Thomas Wouters <[EMAIL PROTECTED]> wrote: > >> Allow me to paraphrase glyph (with whom I'm in complete agreement, for what >> it's worth): many newbies will be disappointed by Python if they start with >> Python 3.0 and discover that most of the cool possibilities they had heard >> about are 'being worked on' and not quite ready. I don't doubt that 3.0 will >> be easier for the new programmer to learn, but I do not believe the average >> "Oh, I heard about Python, let's learn it" person should be pointed to 3.0 >> right now. They should be encouraged to learn 2.6 -- or even 2.5. > > I think that's right. > > I was asked this question today, and it comes up (to me) fairly often at > PARC. I usually suggest using the Python version that's standard for > the user's platform, if they use OS X or Linux (and most do), which is > typically 2.5 (for OS X Leopard), and 2.4 (for Linux -- may be out of date). For Linux, it depends on the distro. I think Ubuntu has been on 2.5 since 7.04 or so. 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] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 02:47, Guido van Rossum <[EMAIL PROTECTED]> wrote: > In the mean time, I don't mind if people learn 3.0 first and 2.6 > second. It's probably easier that way than the other way around. :-) It may be easier in a vacuum -- although I don't think it is. 3.0 is more logical than 2.x, and I don't think it's easier to learn about the better way first, and then realize that you have to use some archaic form later. In fact, we had someone on #python just last week who had learned Python from a 2.6 tutorial, then found out he had to use 2.5, and he was actually tripping over some 2.6-only features he'd been taught. When he learned he had to go back and relearn and fix them by hand, his actual words were "if thats the case, I'm gonna be forced to use another language". I hope that isn't a typical example of such a case, but I can partly understand the sentiment. But even if it's true, people don't learn in a vacuum. Almost everybody else will be thinking of 3.0 in terms of 'changes since 2.x', tools such as 2to3 are oriented that way, and explanations on bits and pieces of Python available to be googled are by and large about 2.x, not 3.0. Right now, it's just much easier to go from 2.x to 3.0 than the other way 'round. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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-3.0, unicode, and os.environ
On Fri, Dec 05, 2008 at 08:37:45PM -0500, James Y Knight wrote: > On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote: >> You can't display a non-decodable filename to the user, hence the user >> will have no idea what they're working on. Non-filesystem related apps >> have no business trying to deal with insane filenames. > > Sigh, same arguments, all over again. > > Again, *both* KDE and Gnome apps display non-decodable filenames to the > user, and let the user work with the files. They display as good a > rendition as they can, using a replacement character as appropriate. In > some earlier versions, KDE did not work at all on poorly-encoded files, > and, users submitted bug reports. People do care, it does happen in real > life, and it is a bug in your software if you cannot deal with the users' > files. They just want the software to work. If it shows something weird > in the window titlebar, that's a bit irritating but at least it doesn't > get in the way of working. I agree 100%. Russian Unix users use at least 5 different encodings (koi8-r, cp1251 and utf-8 are the most frequent in use, cp866 and iso-8859-5 are less frequent). I have an FTP server with some filenames in koi8 encoding - these filenames are for unix clients, - and some filenames in cp1251 for w32 clients. Sometimes I run utf-8 xterm (I am a commandline/console unixhead) for my needs (read email, write files in utf-8 with characters beyond koi8-r, which is my primary encoding) - and I still can work with filenames in koi8/cp1251 encodings. My filemanager (Midnight Commander, for the matter) shows these files and directories as "?.???", but I can chdir to such directories, and I can open such files. It would be a big bad blow for me if filemanagers (or other programs) start to filter these filenames. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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-3.0, unicode, and os.environ
On Sat, Dec 06, 2008 at 12:03:55PM +1100, Steven D'Aprano wrote: > I'd rather have the Python API report errors then silence them, at least > by default. +1 for encoding errors by default. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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-3.0, unicode, and os.environ
On Sat, Dec 06, 2008 at 02:22:29AM +0100, "Martin v. L?wis" wrote: > And environment variables, command line arguments, and file names > are not bytes, but characters. "There is no such thing as plain text!" If you say "these are characters" you must also name the encoding for them. LANG/LC_ALL/LC_CTYPE provide a sensible default, but if a program has problems decoding bytes to characters there must be a way for the user to override the default. But the user must be notified about the error, so programs must not silently filters out non-decodable characters. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Where/how should I check this in?
I have a change to check in from this issue: http://bugs.python.org/issue4483 It is a build error for _dbmmodule.c which was reported against Python 3.0 involving a change to the layout of symbols in libgdbm. (There is now a libgdbm_compat in some systems which holds the dbm_* symbols.) With one tweak I'm certain needs to be applied to both 2.6 and trunk. Do I just check it in on all three branches and run svnmerge block to keep it from being considered again? Thanks, Skip ___ 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-3.0, unicode, and os.environ
Nick Coghlan wrote: > Toshio Kuratomi wrote: >>> >> Nonsense. A program can do tons of things with a non-decodable >> filename. Where it's limited is non-decodable filedata. > > You can't display a non-decodable filename to the user, hence the user > will have no idea what they're working on. Non-filesystem related apps > have no business trying to deal with insane filenames. > This is where we disagree. There are many ways to display the non-decodable filename to the user because the user is not a machine. The computer must know the unique sequence of bytes in order to access a file. The user, OTOH, usually only needs to know that the file exists. In most GUI-based end-user oriented desktop apps, it's enough to do str(filename, errors='replace'). For instance, the GNOME file manager displays: "? (Invalid encoding)" and Konqueror, the KDE file manager just displays: "?" The file can still be displayed this way, accessed via the raw bytes that the program keeps internally, and operated upon by applications. For applications in which the user needs more information to differentiate the files the program has the option to display the raw byte sequences as if they were the filename. The *NIX shell and command line tools have this ability. $ LANG=en_US.utf8 ls -b á í $ LANG=C ls -b . .. \303\241 \303\255 $ mv $'\303\241' $'\303\263' $ LANG=C ls -b \303\255 \303\263 $ LANG=en_US.utf8 ls -b í ó > Linux is moving towards a standard of UTF-8 for filenames, and once we > get to the point where the idea of encoding filenames and environment > variables any other way is seen as crazy, then the Python 3 approach > will work seamlessly. > With the caveat that I haven't seen movement by Linux and other Unix variants to enforce UTF-8. What I have seen are statements by kernel programmers that having the filesystem use bytes and not know about encoding is the correct thing to do. This means that utf-8 will be a convention rather than a necessity for a very long time and consequently programs will need to worry about the problems of mixed encoding systems for an equally long time. (Remember, encoding is something that can be changed per user and per file. So on a multiuser OS, mixed encodings can be out of the control of the system administrator for perfectly valid reasons.) > In the meantime, raw bytes APIs will provide an alternative for those > that disagree with that philosophy. > Oh I agree with the UTF-8 everywhere philosophy. I just know that there's tons of real-world systems out there that don't conform to my expectations for sanity and my code has to account for those :-) -Toshio signature.asc Description: OpenPGP digital 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] Python-3.0, unicode, and os.environ
On Fri, Dec 5, 2008 at 10:18 PM, Bugbee, Larry <[EMAIL PROTECTED]> wrote: > There has been some discussion here that users should use the str or > byte function variant based on what is relevant to their system, for > example when getting a list of file names or opening a file. That > thought process really doesn't do much for those of us that write code > that needs to run on any platform type, without alteration or the > addition of complex if-statements and/or exceptions. > > Whatever the resolution here, and those of you addressing this thorny > issue have my admiration, the solution should be such that it gives > consistent behavior regardless of platform type and doesn't require the > programmer to know of all the minute details of each possible target > platform. My prediction is that it won't ever be possible to completely hide this difference between platforms. The platforms differ fundamentally in how they see filenames. An elaborate abstraction can certainly be created that smooths out most of the differences, but at some point useful functionality will have to be lost in order to maintain strict platform independence. This is the fate of most platform-independence abstractions by the way. For example, there are many elaborate packages for platform-independent I/O, but they generally don't provide access to all functionality that is available on a platform. Where they do, the application is once again placed in the position of having to use complex if-statements and/or exceptions. Consider just this example. Many programs have a need to ask their user for a filename to be created by the program. On systems where filenames are raw byte strings, do you want to provide the user with a way to specify an arbitrary byte string? (That is, in addition to the normal case of entering a text string that will be transformed into a filename using some encoding.) Your choices are either not to support the case of bytes that aren't a valid encoding in the current encoding, or add a UI element to select an encoding, or add a UI element to enter raw bytes. An abstraction package is likely to only support the first option (this is what Java does BTW), but this is not acceptable to all applications. > That may not be possible for a while, so interim solutions should be > such that it minimizes later pain. If that means hiding "implementation > details" behind a new function, so be it. Then, at least, the body of > one's app is not burdened with this problem later when conditions > change. I believe the problem's severity is actually overstated. The interim solution with the least amount of pain that will work for almost all apps is to treat filenames as text strings encoded in some default encoding, and ignore filenames that aren't valid encodings of any text string. Yes, it is possible that you'll find that you can't completely remove or traverse certain directory trees. But that's a fact of life anyway (filesystems have many hidden failure modes), so you're better off dealing with *that* possibility than worrying over the issue of undecodable filenames. -- --Guido van Rossum (home page: http://www.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] Python-3.0, unicode, and os.environ
On Fri, Dec 5, 2008 at 8:57 PM, Tres Seaver <[EMAIL PROTECTED]> wrote: > Amen! the idea that paths, environment varioables, and stuff pulled off > of sockets can be treated as text rather than strings is just wishful > thinking. Unfortunately most of the programmers of the world *do* think that way(*), and it's not easy to wean them off the idea. It's a powerful meme that you can use your own name as a file name, even if you happen to be Czech or Vietnamese -- and it's promoted by the two most popular consumer operating systems. (*) With the exception of sockets. Sockets are typically dealt with through protocols and APIs that provide guidance about how to convert between bytes and strings, and whether that is even a meaningful operation. -- --Guido van Rossum (home page: http://www.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] Python-3.0, unicode, and os.environ
Bugbee, Larry wrote: > There has been some discussion here that users should use the str or > byte function variant based on what is relevant to their system, for > example when getting a list of file names or opening a file. That > thought process really doesn't do much for those of us that write code > that needs to run on any platform type, without alteration or the > addition of complex if-statements and/or exceptions. > > Whatever the resolution here, and those of you addressing this thorny > issue have my admiration, the solution should be such that it gives > consistent behavior regardless of platform type and doesn't require the > programmer to know of all the minute details of each possible target > platform. > I've been thinking about this and I can only see one option. I don't think that it really makes less work for the programmer, though -- it just shifts the problem and makes it more apparent what your code is doing. To avoid exceptions and if-then's in program code when accessing filenames, environment variables, etc, you would need to access each of these resources via the byte API. Then, to avoid having to keep track of what's a string and what's a byte in your other code, you probably want to convert those bytes to strings. This is where the burden gets shifted. You'll have your own routine(s) to do the conversion and have to have exception handling code to deal with undecodable filenames. Note 1: your particular app might be able to get away without doing the conversion from bytes to string -- it depends on what you're planning on doing with the filename/environment data. Note 2: If there isn't a parallel API on all platforms, for instance, Guido's proposal to not have os.environb on Windows, then you'll still have to have a platform specific check. (Likely you should try to access os.evironb in this instance and if it doesn't exist, use os.environ instead... and remember that you need to either change os.environ's data into str type or change os.environb's data into byte type.) -Toshio signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Fri, Dec 5, 2008 at 9:28 PM, <[EMAIL PROTECTED]> wrote: > On 5 Dec, 06:10 pm, [EMAIL PROTECTED] wrote: >> On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: >>> With all due respect, for me, "library support" and "serious use" are >>> synonymous. >> >> Glyph, I cannot have a discussion with you if every single post of >> yours is longer than my combined daily output. Please spend some time >> writing shorter posts. I'm sure I'm not the only one here with a short >> attention span. :-) > > I already spend a lot of time trying to remove extraneous details. The > drafts of these messages are usually 3x as long :). So, trying to keep it > short: Thanks! > Thomas paraphrased my point pretty well. The importance of libraries cannot > be overemphasized. Maybe you're right and the stdlib is enough for a large > audience, but I don't know that audience. Everyone I know who uses Python, > uses it because of a library. In some cases, an equivalent library exists > for another language, and Python wins because it has a nicer syntax. But, > in no case does Python win where it *doesn't* have the library. Clearly you're not reading the edu-sig list. :-) > I think that the marketing for py3 needs to target library vendors before > targeting novices. If the novices are targeted first, they are going to > have a bad experience when "python" libraries don't work with py3, and > library maintainers are going to have a bad experience when clueless newbies > harass them to update their software without understanding the magnitude of > the work to do so. I think it's great to have specific marketing targeted towards library developers. I know we haven't done enough -- for example I promised a C extension porting guide which didn't materialize. :-( But I do *not* think it is a good idea to emphasize elsewhere that most people shouldn't use Python 3.0. Py3k will have a hard enough time gaining mindshare without the very developers who created it discouraging its use. If you can't find it in your heart to recommend 3.0, can you at least keep that within your circle of library-producing friends? Whenever someone asks me which version to use, I alwasys respond with a question -- what do you want to use it for? And then I'll give them an answer based on what's available for their needs. Sometimes I have to recommend Python 2.2. It's been a while since I had to recommend 1.5.2 but a few years ago that was still common. (A large company I know still has servers where 1.5.2 is the default, although 2.4 is also installed.) > I've been predicting this for years, but two days into Python 3's release, > I've already seen real-world examples of this pattern in #twisted. I can > tell these people to "downgrade" to py2 when they come ask me for help, but > I don't think most of them ask for help. They just get angry and learn Java > instead. If they're that easily convinced that Java is better they probably were a lost cause anyway, so I won't mourn their departure too much. The one thing I would warn against is replacing a default Python 2.x with Python 3.0 -- if you find 2.x pre-installed, it's likely that other parts of the OS infrastructure depend on it, and *any* upgrade except to 2.x.n is likely to cause trouble. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 2:12 AM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On Sat, Dec 6, 2008 at 02:47, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> In the mean time, I don't mind if people learn 3.0 first and 2.6 >> second. It's probably easier that way than the other way around. :-) > > It may be easier in a vacuum -- although I don't think it is. 3.0 is more > logical than 2.x, and I don't think it's easier to learn about the better > way first, and then realize that you have to use some archaic form later. True, though (at least when writing new 2.x code) it's often not needed to use the archaic forms. E.g. you don't have to use backticks or __cmp__ or string exceptions. And if you can live with 2.6 it gets even better (e.g. relative import, "except ... as ..."). > In > fact, we had someone on #python just last week who had learned Python from a > 2.6 tutorial, then found out he had to use 2.5, and he was actually tripping > over some 2.6-only features he'd been taught. When he learned he had to go > back and relearn and fix them by hand, his actual words were "if thats the > case, I'm gonna be forced to use another language". I hope that isn't a > typical example of such a case, but I can partly understand the sentiment. You can't prevent this kind of thing happening occasionally. I don't generally lie awake over it -- I don't expect a massive exodus. I think some people like to say this kind of thing (especially publicly) because they expect us to be insecure about Python adoption and worried about the competition. Don't fall for the troll bait! When they go home they'll realize that learning Ruby or Java is a lot more work than learning the differences between Python 2.5 and 2.6. Or they'll learn one of those and find that it's not all roses their either. (Ruby is also going through a language transition, and the choice of which version of Java to learn isn't that easy either, despite the strict backwards compatibility -- you can choose to use a somewhat awkward older version, or use the latest and find it's not supported on the next platform you're porting to.) > But even if it's true, people don't learn in a vacuum. Almost everybody else > will be thinking of 3.0 in terms of 'changes since 2.x', tools such as 2to3 > are oriented that way, and explanations on bits and pieces of Python > available to be googled are by and large about 2.x, not 3.0. Right now, it's > just much easier to go from 2.x to 3.0 than the other way 'round. True, but we should work on fixing this rather than giving up. What happened to the 3to2 project? Wasn't someone planning to write a 3.0 to 2.6 (or 2.5?) converter using the same technology in 2to3? We probably need two different marketing/PR streams: one aimed at *existing* Python users (reaffirming we will be supporting 2.x fully for many years to come), another at *new* users (suggesting that now is a better time than ever to learn Python, with 3.0 available and new packages being ported to it all the time). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Fri, Dec 5, 2008 at 10:03 PM, <[EMAIL PROTECTED]> wrote: > The best thing for 3.0 adoption would be a 3.0 "welcoming committee". A > group of hackers wandering from one popular open source library to another, > writing patches for 3.x compatibility issues. There must be lots of people > who care about 3.x adoption, and this is probably the most effective way > they can reach that goal. > > Each time I am going to fix a 3.0 compatibility issue, I have a choice: I > can either make Twisted itself better (add features, fix bugs), or I can > keep Twisted exactly the same but do lots of work so it will work on 3.0. > It seems pretty clear to me that, to the extent that I have time for > Twisted, fixing bugs in the HTTP implementation would be a better deal than > puzzling through a megabyte of diffs generated by 2to3, trying to understand > where it went wrong, and how. > > This doesn't mean I'm "sitting on my hands". It just means I have better > things to be doing with my hands. (To be precise, 1054 better things to do, > re: Twisted. Add in the Divmod projects and it's more like 3000.) > > Of course the distant threat of an unmaintained 2.x series is enough to > motivate me to push a *little* in this direction, but it doesn't make me > happy about it. > > I think this is exactly what the marketing effort around 3.0 needs to be > doing: making a positive case for library and application authors to spend > time to update to 3.x. This is a lot of work, and many (I might even say > most) of us need a lot of cajoling. Free patches are a good incentive :). This is a really good idea. I hope and expect that the information and tools available for porting to 3.0 will dramatically improve over the next half year or so (hopefully the situation is a lot less gloomy already by the time we meet again at PyCon). The porting list that was just created also sounds like a step in the right direction. I do think that in many cases *some* support from the regular maintainers of a library would be needed -- for example if you (in particular) were to express a negative attitude towards porting Twisted to 3.0 (I'm not saying that you do, it's just a hypothetical that would apply to any "BDFL" for any sizable library) then this would discourage others from trying to contribute. OTOH if you made a branch available where you check in the results of running 2to3 over Twisted, with instructions for people to contribute fixes, that would be great -- at almost no cost to you! (Assuming you can get someone else to work on merging trunk improvements into that branch.) Remember the open source mantra -- reap the benefit of all those eyeballs! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On 10:12 am, [EMAIL PROTECTED] wrote: When he learned he had to go back and relearn and fix them by hand, his actual words were "if thats the case, I'm gonna be forced to use another language". I hope that isn't a typical example of such a case, but I can partly understand the sentiment. This is an overreaction, but it's a very typical overreaction. It's difficult to recover from a negative first impression even if you have lots of opportunities; in the case of an anonymous user trying out Python, the user will often stop using it, without telling anyone, and never come back. There's no opportunity to recover. ___ 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-3.0, unicode, and os.environ
On 02:34 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 05, 2008 at 08:37:45PM -0500, James Y Knight wrote: On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote: You can't display a non-decodable filename to the user, hence the user will have no idea what they're working on. Non-filesystem related apps have no business trying to deal with insane filenames. Sigh, same arguments, all over again. People do care, it does happen in real life, and it is a bug in your software if you cannot deal with the users' files. They just want the software to work. If it shows something weird in the window titlebar, that's a bit irritating but at least it doesn't get in the way of working. I agree 100%. Russian Unix users use at least 5 different encodings (koi8-r, cp1251 and utf-8 are the most frequent in use, cp866 and iso-8859-5 are less frequent). I have an FTP server with some filenames in koi8 encoding - these filenames are for unix clients, - and some filenames in cp1251 for w32 clients. Sometimes I run utf-8 xterm (I am a commandline/console unixhead) for my needs (read email, write files in utf-8 with characters beyond koi8-r, which is my primary encoding) - and I still can work with filenames in koi8/cp1251 encodings. My filemanager (Midnight Commander, for the matter) shows these files and directories as "?.???", but I can chdir to such directories, and I can open such files. It would be a big bad blow for me if filemanagers (or other programs) start to filter these filenames. I find it interesting to note that the only users in this discussion who actually have these problems in real life all have this attitude. It is expected that in an imperfect world we will have imperfect encodings, but it is super important that software which can open files can deal with not understanding the character translation of the filename. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 10:48 AM, <[EMAIL PROTECTED]> wrote: > On 10:12 am, [EMAIL PROTECTED] wrote: >> When he learned he had to go >> back and relearn and fix them by hand, his actual words were "if thats the >> case, I'm gonna be forced to use another language". I hope that isn't a >> typical example of such a case, but I can partly understand the sentiment. > > This is an overreaction, but it's a very typical overreaction. It's > difficult to recover from a negative first impression even if you have lots > of opportunities; in the case of an anonymous user trying out Python, the > user will often stop using it, without telling anyone, and never come back. > There's no opportunity to recover. Sorry, but I really don't see it that dark. Either they weren't ready to learn a new language anyway, or they'll try something else, and find that the grass isn't actually that green on the other side of the fence either. In general I don't worry about losing one individual potential user; there are plenty of others. I'd be more worried if someone wrote a nasty blog rant or a Slashdot article after such an experience -- but there will always be lots of people pointing out the other side, so the negative effect of such blogs is usually neutralized quite well. The one overraction that would really worry me is if influential people inside the Python developer community were to start dissing Python 3.0 based on the response of someone in #python. -- --Guido van Rossum (home page: http://www.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] Python-3.0, unicode, and os.environ
On Sat, Dec 6, 2008 at 10:53 AM, <[EMAIL PROTECTED]> wrote: > On 02:34 pm, [EMAIL PROTECTED] wrote: >> I agree 100%. Russian Unix users use at least 5 different encodings >> (koi8-r, cp1251 and utf-8 are the most frequent in use, cp866 and >> iso-8859-5 are less frequent). I have an FTP server with some filenames in >> koi8 encoding - these filenames are for unix clients, - and some filenames >> in cp1251 for w32 clients. Sometimes I run utf-8 xterm (I am >> a commandline/console unixhead) for my needs (read email, write files in >> utf-8 with characters beyond koi8-r, which is my primary encoding) - and >> I still can work with filenames in koi8/cp1251 encodings. My filemanager >> (Midnight Commander, for the matter) shows these files and directories as >> "?.???", but I can chdir to such directories, and I can open such >> files. It would be a big bad blow for me if filemanagers (or other >> programs) start to filter these filenames. > > I find it interesting to note that the only users in this discussion who > actually have these problems in real life all have this attitude. It is > expected that in an imperfect world we will have imperfect encodings, but it > is super important that software which can open files can deal with not > understanding the character translation of the filename. For file managers and similar tools I am absolutely 100% in agreement -- that's why the binary APIs are there. Most apps aren't file managers or ftp clients though. The sky is not falling. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 06, 2008 at 06:03:55AM -, [EMAIL PROTECTED] wrote: -> On 01:47 am, [EMAIL PROTECTED] wrote: -> >>In spite of Python being a programming language, there is a difference -> >>between 'casual user of the language' and 'library developer'; 3.0 is -> >>certainly a must for all actual library developers, and I'm sure most -> >>of -> >>them know about 3.0 by now. We're talking about first impressions for -> >>people -> >>without that knowledge. -> > -> >Well if most library developers already know 3.0 by now, I would hope -> >they aren't going to sit on their hands, and solve the issues at hand! -> -> The best thing for 3.0 adoption would be a 3.0 "welcoming committee". A -> group of hackers wandering from one popular open source library to -> another, writing patches for 3.x compatibility issues. There must be -> lots of people who care about 3.x adoption, and this is probably the -> most effective way they can reach that goal. Does anyone smell a few GSoC projects? (And maybe GHOP if Google decides to run it again; no word yet.) --titus -- C. Titus Brown, [EMAIL PROTECTED] ___ 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] "as" keyword woes
> Date: Fri, 05 Dec 2008 22:22:38 -0800
> From: Dennis Lee Bieber <[EMAIL PROTECTED]>
> Subject: Re: "as" keyword woes
> To: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
>
> I'm still in the dark as to what type of data could
> even inspire the
> use of "as" as an object name... A collection of "a" objects? In which
> case, what are the "a"s?
Please let me clarify. It is not "as" as a standalone object that we
specifically miss in 2.6/3, but rather, the ability to use ".as" used as
a method or attribute name.
In other words we have lost the ability to refer to "as" as the
generalized OOP-compliant/syntax-independent method name for casting:
new_object = old_object.as(class_hint)
# For example:
float_obj = int_obj.as("float")
# or
float_obj = int_obj.as(float_class)
# as opposed to something like
float_obj = int_obj.asFloat()
# which requires a separate method for each cast, or
float_obj = (float)int_obj
# which required syntax-dependent casting [language-based rather than
object-based].
Of course, use of explicit casting syntax "(float)" is fine if you're
restricting yourself to Python and other languages which support
casting, but that solution is unavailable inside of a pure OOP
message-passing paradigm where object.method(argument) invocations are
all you have to work with.
Please note that use of object.asClassname(...) is a ubiqitous
convention for casting objects to specific classes (seen in ObjectiveC,
Java, SmallTalk, etc.).
There, I assert that 'object.as(class_reference)' is the simplest and
most elegant generalization of this widely-used convention. Indeed, it
is the only obvious concise answer, if you are limited to using methods
for casting.
Although there are other valid domain-specific uses for "as" as either a
local variable or attribute names (e.g. systematic naming: as, bs, cs),
those aren't nearly as important compared to "as" being available as the
name of a generalized casting method -- one that is now strictly denied
to users of Python 2.6 and 3.
As someone somewhat knowledgable of how parsers work, I do not
understand why a method/attribute name "object_name.as(...)" must
necessarily conflict with a standalone keyword " as ". It seems to me
that it should be possible to unambiguously separate the two without
ambiguity or undue complication of the parser.
So, assuming I now wish to propose a corrective PEP to remedy this
situation for Python 3.1 and beyond, what is the best way to get started
on such a proposal?
Cheers,
Warren
___
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] "as" keyword woes
Warren DeLano wrote: > There, I assert that 'object.as(class_reference)' is the simplest and > most elegant generalization of this widely-used convention. Indeed, it > is the only obvious concise answer, if you are limited to using methods > for casting. How about "to"? Almost every language I have ever used uses "to" and not "as". Python predominately uses "to" already, so why would you fight that? And moreover, I have never seen a language or library that preferred "as", so I remain to be convinced that "as" is a good choice. > As someone somewhat knowledgable of how parsers work, I do not > understand why a method/attribute name "object_name.as(...)" must > necessarily conflict with a standalone keyword " as ". It seems to me > that it should be possible to unambiguously separate the two without > ambiguity or undue complication of the parser. It's not a matter of whether it is possible. It's a matter of simplicity and a lack of a worthy use-case for allowing it. In general, the trend has been to not allow any keywords as identifiers in the Python language. If there were such a worthy use-case, then what is really import is that it increases the complexity of /the language/ a human programmer needs to parse. > So, assuming I now wish to propose a corrective PEP to remedy this > situation for Python 3.1 and beyond, what is the best way to get started > on such a proposal? I think you will need to work on making a convincing argument as to why the keyword "as" is anymore special than say "for", or any other keywords for that matter. Unless you plan on proposing a reversal of the current keyword/identifier ideology, which is likely to be reject outright. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
As far as the original point of this thread, I started off just defending the cautionary text already present in the announcements and on the website. Since I'm not advocating any changes to that (the brief caveat on the "download" page is fine), we'll just have to agree to disagree on the abstractly appropriate audience for 3.0. I'll respond to some other points though: On 05:54 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 9:28 PM, <[EMAIL PROTECTED]> wrote: On 5 Dec, 06:10 pm, [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: I think it's great to have specific marketing targeted towards library developers. I know we haven't done enough -- for example I promised a C extension porting guide which didn't materialize. :-( Well, get cracking, then! :) If you can't find it in your heart to recommend 3.0, can you at least keep that within your circle of library-producing friends? In another (longer) message, I already said this is what I'm doing. Assuming that we are all my "library-producing friends" here :). I am deliberately refraining from blogging about 3.0 until I have something nice to say. But still, you can't honestly expect me to recommend 3.0 until someone has gotten at least a basic skeleton of Twisted up and running under it :). My own attempts to do so have failed miserably, to the point where I can't even produce a useful bug report without a lot more work. Would you recommend a C compiler that couldn't build Python, or link with it? Whenever someone asks me which version to use, I alwasys respond with a question -- what do you want to use it for? In the longer term, I think that you should look at this as a symptom of a problem. If you learn Java, you learn the most recent version. If you need your software to work with an older version, you just pass a special option to the compiler. If you want your *old* software to work with a *new* version, it basically just does (at least, 99% of the time). I don't think there's anything about the 3.0 language which couldn't be supported in a VM that understood both 2 and 3. "py3to2" seems at least a rough proof of concept of that idea, although it still has some issues. Library availability should be a separate concern from a clean source language. I also don't think 3.0 is perfect, and five years on, there will be a temptation to make more "just this once" incompatible changes. Of course, you've promised these changes won't be made, and *this* set of design mistakes will be with us forever. It would be nice if there were a way for evolution to continue without another reboot of the world. If they're that easily convinced that Java is better they probably were a lost cause anyway, so I won't mourn their departure too much. I really believe that *all* new users are fickle, if they don't have a mandate as to what they need to be learning. Personally, I learned Python because of a memory leak in Swing. ___ 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] "as" keyword woes
On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <[EMAIL PROTECTED]> wrote: [...] > There, I assert that 'object.as(class_reference)' is the simplest and > most elegant generalization of this widely-used convention. Indeed, it > is the only obvious concise answer, if you are limited to using methods > for casting. Well, that's too bad, as 'as' is now a reserved word. > Although there are other valid domain-specific uses for "as" as either a > local variable or attribute names (e.g. systematic naming: as, bs, cs), > those aren't nearly as important compared to "as" being available as the > name of a generalized casting method -- one that is now strictly denied > to users of Python 2.6 and 3. If you had brought this up 5-10 years ago when we first introduced 'as' as a semi-keyword (in the import statement) we might have been able to avert this disaster. As it was, nobody ever brought this up AFICR, so I don't think it's *that* obvious. > As someone somewhat knowledgable of how parsers work, I do not > understand why a method/attribute name "object_name.as(...)" must > necessarily conflict with a standalone keyword " as ". It seems to me > that it should be possible to unambiguously separate the two without > ambiguity or undue complication of the parser. That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. Reserved words are reserved in all contexts, regardless of whether ambiguity could arise. Otherwise *every* reserved word would have to be allowed right after a '.', and many keywords would have to be allowed as identifiers in other contexts. That way lies PL/1... Furthermore, how would you define the 'as' method? Would you also want to be allowed to write def as(self, target): ... ??? Trust me, it's a slippery slope, and you don't want to start going down there. > So, assuming I now wish to propose a corrective PEP to remedy this > situation for Python 3.1 and beyond, what is the best way to get started > on such a proposal? Don't bother writing a PEP to make 'as' available as an attribute again. It has no chance of being accepted. Instead, think of a different word you could use. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On 06:16 pm, [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 10:03 PM, <[EMAIL PROTECTED]> wrote: I do think that in many cases *some* support from the regular maintainers of a library would be needed -- for example if you (in particular) were to express a negative attitude towards porting Twisted to 3.0 (I'm not saying that you do, it's just a hypothetical that would apply to any "BDFL" for any sizable library) then this would discourage others from trying to contribute. Of course. Grumpy as we are, we're preparing for the 3.0 migration, and have been for a while. There are tickets open in the tracker, a buildslave reporting 2.6's -3 warnings, and soon, apparently, a buildslave that will attempt to run the tests with 3.0, although getting anything but a traceback bootstrapping the testing tool is a ways off. My attitude in every public statement I've ever made about 3.0 has been that there is too much migration work for our tiny team to do, but we are very open to getting help from the community. OTOH if you made a branch available where you check in the results of running 2to3 over Twisted, with instructions for people to contribute fixes, that would be great -- at almost no cost to you! (Assuming you can get someone else to work on merging trunk improvements into that branch.) Remember the open source mantra -- reap the benefit of all those eyeballs! This isn't really the way our development process works on Twisted - we don't have enough developers to support more than one line of development. Modules and subsystems can be patched individually, and the whole idea with 2to3 is that source changes should remain compatible with 2.6 (and appropriate level of swaddling can paper over library changes back to 2.3) so those fixes can just go into trunk, right? Nevertheless the sentiment is the same. If someone desperately interested in getting Twisted to work on 3.0, there would be lots of work for them to do and a clear place for them to go do it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 12:19 PM, <[EMAIL PROTECTED]> wrote: > I also don't think 3.0 is perfect, and five years on, there will be a > temptation to make more "just this once" incompatible changes. Of course, > you've promised these changes won't be made, and *this* set of design > mistakes will be with us forever. It would be nice if there were a way for > evolution to continue without another reboot of the world. It would be nice indeed. But we (and any other language that's alive) will need to walk a careful line between evolving too slow and too fast. Hopefully we'll be able to evolve mostly through deprecation and eventual removal of misfeatures rather than through a series of hiccups like 3.0. But it will still be too slow for some and too fast for others. Since one of your favorite themes is that your team is too small, I would like to reuse that idea. If we had as many Python core developers as Sun and IBM have working on Java, we could most likely have introduced all Python 3.0 features gradually, with compiler flags and __future__ imports to support different versions. But despite being a bit bigger than Twisted, we're still severely constrained by resources. My estimation when we started was that it would be easier for the core team to maintain two separate versions over a long time, than to try and produce a single binary capable of running both versions of the language. (Maybe Jython and/or IronPython provide a better platform for doing that though.) Hopefully by the time Python 4000 rolls along, technology will be available to make the transition more smoothly. But we'll still have to break some eggs... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 12:37 PM, <[EMAIL PROTECTED]> wrote: > Of course. Grumpy as we are, we're preparing for the 3.0 migration, and > have been for a while. There are tickets open in the tracker, a buildslave > reporting 2.6's -3 warnings, and soon, apparently, a buildslave that will > attempt to run the tests with 3.0, although getting anything but a traceback > bootstrapping the testing tool is a ways off. Thank you very much for this. > My attitude in every public statement I've ever made about 3.0 has been that > there is too much migration work for our tiny team to do, but we are very > open to getting help from the community. If I were a Twisted user I wouldn't hesitate to help. Open source to the rescue! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On 08:51 pm, [EMAIL PROTECTED] wrote: On Sat, Dec 6, 2008 at 12:19 PM, <[EMAIL PROTECTED]> wrote: I also don't think 3.0 is perfect, and five years on, there will be a temptation to make more "just this once" incompatible changes. Of course, you've promised these changes won't be made, and *this* set of design mistakes will be with us forever. It would be nice if there were a way for evolution to continue without another reboot of the world. Since one of your favorite themes is that your team is too small, I would like to reuse that idea. If we had as many Python core developers as Sun and IBM have working on Java, we could most likely have introduced all Python 3.0 features gradually, with compiler flags and __future__ imports to support different versions. But despite being a bit bigger than Twisted, we're still severely constrained by resources. Ah, the dangers of over-editing. I originally had a whole paragraph about how I understood that the Python dev team was also resource constrained, but I deleted it for brevity. Now you see why my posts are so long! :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Fri, Dec 5, 2008 at 22:03, <[EMAIL PROTECTED]> wrote: > On 01:47 am, [EMAIL PROTECTED] wrote: >>> >>> In spite of Python being a programming language, there is a difference >>> between 'casual user of the language' and 'library developer'; 3.0 is >>> certainly a must for all actual library developers, and I'm sure most of >>> them know about 3.0 by now. We're talking about first impressions for >>> people >>> without that knowledge. >> >> Well if most library developers already know 3.0 by now, I would hope >> they aren't going to sit on their hands, and solve the issues at hand! > > The best thing for 3.0 adoption would be a 3.0 "welcoming committee". A > group of hackers wandering from one popular open source library to another, > writing patches for 3.x compatibility issues. There must be lots of people > who care about 3.x adoption, and this is probably the most effective way > they can reach that goal. > The welcoming committee has somewhat already started. Martin announced on python-porting that he ported psycopg2 himself and submitted the patch. Martin also mostly ported Django at the last PyCon. -Brett ___ 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] Holding a Python Language Summit at PyCon
On Thu, Dec 4, 2008 at 17:02, Frank Wierzbicki <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 3:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Thu, Dec 4, 2008 at 12:05, Frank Wierzbicki <[EMAIL PROTECTED]> wrote: >>> On Wed, Dec 3, 2008 at 10:31 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: 14:00 - 15:30 = Two tracks: Cross-implementation issues: What do the various VMs want/need from CPython to help with their implementations? * Marking CPython-specific tests in the test suite? * Getting an implementation agnostic test suite for the Python language? * Separating the language tests and the pure Python part of the stdlib into a separate project? (Or publish them as a separate package.) * Transition plans for 3.0? Champion needed. >>> I would like to champion this one. >>> >> >> I told AMK this a while back, but might as well make it more public; I >> am up for chairing as well. > Brett, > > Are you saying you've already called the cross-implementation champion > role? No, I am saying I had told AMK I was interested in championing the session. He chose you, and that's that. One less thing for me to worry about. =) > If so I'm happy to defer or co-chair. Your call. I will definitely be there representing CPython as best as I can, so I will be making noise regardless of whether I am standing in front of the room or not. -Brett ___ 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] Holding a Python Language Summit at PyCon
On Dec 6, 2008 5:42pm, Brett Cannon <[EMAIL PROTECTED]> wrote: On Thu, Dec 4, 2008 at 17:02, Frank Wierzbicki wrote: > On Thu, Dec 4, 2008 at 3:16 PM, Brett Cannon wrote: >> On Thu, Dec 4, 2008 at 12:05, Frank Wierzbicki wrote: >>> On Wed, Dec 3, 2008 at 10:31 AM, AM Kuchling wrote: 14:00 - 15:30 = Two tracks: Cross-implementation issues: What do the various VMs want/need from CPython to help with their implementations? * Marking CPython-specific tests in the test suite? * Getting an implementation agnostic test suite for the Python language? * Separating the language tests and the pure Python part of the stdlib into a separate project? (Or publish them as a separate package.) * Transition plans for 3.0? Champion needed. >>> I would like to champion this one. >>> >> >> I told AMK this a while back, but might as well make it more public; I >> am up for chairing as well. > Brett, > > Are you saying you've already called the cross-implementation champion > role? No, I am saying I had told AMK I was interested in championing the session. He chose you, and that's that. One less thing for me to worry about. =) > If so I'm happy to defer or co-chair. Your call. I will definitely be there representing CPython as best as I can, so I will be making noise regardless of whether I am standing in front of the room or not. -Brett Is heckling covered as an official obligation? :) -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] "as" keyword woes
On 06 Dec 2008, at 20:38, Warren DeLano wrote:
Date: Fri, 05 Dec 2008 22:22:38 -0800
From: Dennis Lee Bieber <[EMAIL PROTECTED]>
Subject: Re: "as" keyword woes
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
I'm still in the dark as to what type of data could
even inspire the
use of "as" as an object name... A collection of "a" objects? In
which
case, what are the "a"s?
Please let me clarify. It is not "as" as a standalone object that we
specifically miss in 2.6/3, but rather, the ability to use ".as"
used as
a method or attribute name.
In other words we have lost the ability to refer to "as" as the
generalized OOP-compliant/syntax-independent method name for casting:
new_object = old_object.as(class_hint)
# For example:
float_obj = int_obj.as("float")
# or
float_obj = int_obj.as(float_class)
# as opposed to something like
float_obj = int_obj.asFloat()
# which requires a separate method for each cast, or
float_obj = (float)int_obj
# which required syntax-dependent casting [language-based rather than
object-based].
Of course, use of explicit casting syntax "(float)" is fine if you're
restricting yourself to Python and other languages which support
casting, but that solution is unavailable inside of a pure OOP
message-passing paradigm where object.method(argument) invocations are
all you have to work with.
Please note that use of object.asClassname(...) is a ubiqitous
convention for casting objects to specific classes (seen in
ObjectiveC,
Java, SmallTalk, etc.).
There, I assert that 'object.as(class_reference)' is the simplest and
most elegant generalization of this widely-used convention. Indeed,
it
is the only obvious concise answer, if you are limited to using
methods
for casting.
Although there are other valid domain-specific uses for "as" as
either a
local variable or attribute names (e.g. systematic naming: as, bs,
cs),
those aren't nearly as important compared to "as" being available as
the
name of a generalized casting method -- one that is now strictly
denied
to users of Python 2.6 and 3.
As someone somewhat knowledgable of how parsers work, I do not
understand why a method/attribute name "object_name.as(...)" must
necessarily conflict with a standalone keyword " as ". It seems to me
that it should be possible to unambiguously separate the two without
ambiguity or undue complication of the parser.
So, assuming I now wish to propose a corrective PEP to remedy this
situation for Python 3.1 and beyond, what is the best way to get
started
on such a proposal?
Cheers,
Warren
As long as "as" is widely known as a keyword, I don't see the problem.
Every python developer knows that the convention is to add a trailing
underscore when you want to use a reserved word in your code. Besides,
your examples are quite abstract. I'm sure it's possible to find good
examples for "while", "with", "import", "from" (I often use "from_")
or "try" as well. Or perhaps that the python keywords should be "as_"
so we leave "as" free for eventual methods?
As for the implicit proposition of allowing keywords only for methods,
I agree with Guido about it being a slippery slope. So we would end up
with a language where it is allowed to name methods after keywords,
but not functions (they can be declared in the local scope)? Yikes! Oh
well, maybe it's possible for an intelligent parser to distinguish
between keywords and function references, but think of the poor
grammar highlighters in all source editors! What a nightmare it will
be for them. Anyway, is there any language that does this, allowing
keywords as method names? I don't know, but if not, there's probably a
reason for it.
Your views on code elegance are also rather Javaish. I'd go for
"class_reference(object)" (and why the heck would you "be limited to
using method for casting"?).
Ciao,
Virgil
___
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] Buildbots for 2.6 and 3.0
Hello people, Looking at http://www.python.org/dev/buildbot/, we are still missing buildbots for the release26-maint and release30-maint branches. Is someone working on that? 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] 3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts? [1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] Buildbots for 2.6 and 3.0
BTW, 3.0 went out the door with test_binascii failing on windows. Was surprised that some buildbot wasn't complaining. - Original Message - From: "Antoine Pitrou" <[EMAIL PROTECTED]> To: Sent: Saturday, December 06, 2008 3:15 PM Subject: [Python-Dev] Buildbots for 2.6 and 3.0 Hello people, Looking at http://www.python.org/dev/buildbot/, we are still missing buildbots for the release26-maint and release30-maint branches. Is someone working on that? 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/python%40rcn.com ___ 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] 3.0.1 possibilities
Strong +1 Are the RMs on board? - Original Message - From: "Benjamin Peterson" <[EMAIL PROTECTED]> To: Sent: Saturday, December 06, 2008 3:18 PM Subject: [Python-Dev] 3.0.1 possibilities Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts? [1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com ___ 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] 3.0.1 possibilities
+1 On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Since the release of 3.0, several critical issues have come to our > attention. Namely, the builtin cmp function wasn't removed [1] and the > new IO library proved to be (as expected) abysmally slow [2][3][4]. > Christian proposed that we release 3.0.1 within the next week to patch > up this critical issues. Thoughts? > > > [1] http://bugs.python.org/1717 > [2] http://bugs.python.org/4533 > [3] http://bugs.python.org/4561 > [4] http://bugs.python.org/4565 -- --Guido van Rossum (home page: http://www.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] 3.0.1 possibilities
Benjamin Peterson gmail.com> writes: > > Since the release of 3.0, several critical issues have come to our > attention. Namely, the builtin cmp function wasn't removed [1] and the > new IO library proved to be (as expected) abysmally slow [2][3][4]. > Christian proposed that we release 3.0.1 within the next week to patch > up this critical issues. The IO library needs a lot of work to make it as fast as in 2.6, one week isn't enough. I'm not sure an emergency release with the linked patches is very useful honestly. ___ 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] 3.0.1 possibilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote: On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts? [1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 I've set the priority on all these to release blockers, but I have my reservations about 4561 and 4565. Resolution of those seem like more than a week or so away. If we want to do a bug fix release for 3.0.1, I'd like to do it no later than the 19th. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSTsNtXEjvBPtnXfVAQKI4AP8CNQEEb2KuN8cvd+t6YK39jFPxEo8j/YV 022zAWX3nNgj/R88C7OwoP6nYLx+zz4D3USj65OZN4NS9W9tJYKs+Lv6CnjIJi2X cVceihcJHVYbyx8r14mYt6VjSmpTuNBD8uPZGv23WLZJZ5pNpWeuEMqI6XR27bY2 NYxbwSEUQpw= =3wZN -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] RELEASED Python 3.0 final
On Sat, Dec 06, 2008, Guido van Rossum wrote: > > But I do *not* think it is a good idea to emphasize elsewhere that > most people shouldn't use Python 3.0. Py3k will have a hard enough > time gaining mindshare without the very developers who created > it discouraging its use. If you can't find it in your heart to > recommend 3.0, can you at least keep that within your circle of > library-producing friends? Sorry, I don't think I can do that. It's difficult-to-impossible to leap straight from Python 2.2 or 2.3 to 3.0, and I think that most released Python software still ought to support versions going back that far. Unless someone plans to use Python only on machines where they can guarantee availability of 3.0, I think that sticking with 2.x is the prudent course. Then again, until the release of 3.0, I was still advocating the use of classic classes in the 2.x series, and I haven't yet decided whether I should change that stance now that there is a released version of Python where new-style classes are the default. I believe that it would be a shame and a disservice to Python if there were a large proportion of the Python community that discouraged the use of 3.0; I also believe it would be a shame and a disservice to Python if you (and other people) tell conservatives like me that we should keep our mouths shut. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ 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] 3.0.1 possibilities
On Sat, Dec 06, 2008, Benjamin Peterson wrote: > > Since the release of 3.0, several critical issues have come to our > attention. Namely, the builtin cmp function wasn't removed [1] and the > new IO library proved to be (as expected) abysmally slow [2][3][4]. > Christian proposed that we release 3.0.1 within the next week to patch > up this critical issues. Thoughts? Seems overly aggressive to me. These prohibit use of 3.0 in production environments; they do not prohibit development in 3.0. I think we should target early January and make it public that we are doing so. That will give more time for any additional similar bugs to get fixed at once. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ 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] Buildbots for 2.6 and 3.0
Hello, On Sun, Dec 7, 2008 at 00:19, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > BTW, 3.0 went out the door with test_binascii failing on windows. > Was surprised that some buildbot wasn't complaining. They were complaining. But not loud enough to stop the release. (see bottom of http://www.python.org/dev/buildbot/3.0/x86%20W2k8%203.0/builds/486/step-test/0 ) -- Amaury Forgeot d'Arc ___ 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-3.0, unicode, and os.environ
Oleg Broytmann wrote: > My filemanager > (Midnight Commander, for the matter) shows these files and directories as > "?.???", but I can chdir to such directories, and I can open such > files. It would be a big bad blow for me if filemanagers (or other > programs) start to filter these filenames. Summary for those without the time to read the longer version below: - File managers, backup managers and similar apps should use the binary APIs worldwide - Most apps in countries where encoding problems are common will also need to use the binary APIs to be acceptable to their uses - Many apps in countries where the 'native' encoding is UTF-8, ASCII or latin-1 will be able to use the Unicode APIs without any issues whatsoever - Apps targeting a limited, well-controlled execution environment (e.g. web services) will also be able to use the Unicode APIs - I think the binary and Unicode APIs should be available (and fully functional) on all platforms (including Windows) so that app developers don't create portability problems for themselves when they make the decision as to which API to use - The point about *filesystem* apps (i.e. file managers, backup tools, indexing engines) needing to deal with the imperfect world of dodgy filesystem encodings isn't in dispute at all - that's why the binary alternative APIs were added. The point is that there is a spectrum from providing a completely clean solution that addresses only the ideal case of "file paths and other items such as environment variable names and values retrieved from the OS are always well-formed text in the appropriate default encoding" (which will actually work for large chunks of the planet - those where the locals are native ASCII speakers and those where computers didn't start to enter widespread use until after Unicode was already available) to addressing only the most pessimistic case of "you can't trust the default encoding at all, and need to assume that all strings retrieved from the OS contain arbitrary binary data" (which is actually true for some parts of the planet, but thankfully not for all of it). Hopefully people can at least agree that the first extreme is unacceptable because that ideal world doesn't exist. I personally think that the other extreme is *also* unacceptable, because it burdens every single application developer with dealing with a potential problem that quite simply may not be a problem for them because they're in a situation where the naive assumption of a sane operating environment is actually a valid one for their particular application. The idea of parallel Unicode and bytes APIs means that for those with an appropriately limited target environment and/or audience, the Unicode APIs will "just work", while the developers that aren't so lucky can rely on the binary APIs instead. That's actually the one place where I disagree with Guido: I agree with Adam that the binary APIs *should* be available on Windows. The difference would be that whereas on *nix type systems, the bytes APIs are the 'lower level' that more accurately represents the underlying OS, on Windows it would be the other way around, with the Unicode APIs as the lower level ones, and the binary APIs as wrappers around them that automatically decoded the bytes representation to a Unicode one when writing to the OS, and encoded from Unicode to bytes when reading from the OS. If the binary APIs are missing from a major platform (i.e. Windows) then the choice to use them brings with it a major cross-platform portability problem that should really be handled by the standard library. 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] 3.0.1 possibilities
On Sat, Dec 6, 2008 at 15:41, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote: > >> On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson >> <[EMAIL PROTECTED]> wrote: >>> >>> Since the release of 3.0, several critical issues have come to our >>> attention. Namely, the builtin cmp function wasn't removed [1] and the >>> new IO library proved to be (as expected) abysmally slow [2][3][4]. >>> Christian proposed that we release 3.0.1 within the next week to patch >>> up this critical issues. Thoughts? >>> >>> >>> [1] http://bugs.python.org/1717 >>> [2] http://bugs.python.org/4533 >>> [3] http://bugs.python.org/4561 >>> [4] http://bugs.python.org/4565 > > I've set the priority on all these to release blockers, but I have my > reservations about 4561 and 4565. Resolution of those seem like more than a > week or so away. > > If we want to do a bug fix release for 3.0.1, I'd like to do it no later > than the 19th. > +1 just to get rid of cmp(). And if io speedups can happen, great, but they can also wait for 3.0.2. -Brett ___ 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-3.0, unicode, and os.environ
Toshio Kuratomi wrote: > Note 2: If there isn't a parallel API on all platforms, for instance, > Guido's proposal to not have os.environb on Windows, then you'll still > have to have a platform specific check. (Likely you should try to access > os.evironb in this instance and if it doesn't exist, use os.environ > instead... and remember that you need to either change os.environ's data > into str type or change os.environb's data into byte type.) Note that this is why I personally think the binary API variants *should* exist on Windows, just with the sense of the system encoding flipped around. That is, on *nix: - underlying OS API uses bytes - binary API just passes values straight through - Unicode API uses the system encoding to encode Unicode names and values to be passed to the OS API and to decode bytes names and values received from the OS API While on Windows: - underlying OS API uses Unicode - Unicode API just passes values straight through - binary API uses the system encoding to decode bytes names and values to be passed to the OS API and to encode Unicode names and values received from the OS API 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] Python-3.0, unicode, and os.environ
Nick Coghlan gmail.com> writes: > > If the binary APIs are missing from a major platform (i.e. Windows) then > the choice to use them brings with it a major cross-platform portability > problem that should really be handled by the standard library. +1 I might also add that providing binary APIs does not prevent us to implement some special representation of broken filenames when using the unicode APIs (for example using private Unicode characters - I'm not sure what the right terminology is - as sometimes suggested). 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] "as" keyword woes
Warren DeLano wrote:
> In other words we have lost the ability to refer to "as" as the
> generalized OOP-compliant/syntax-independent method name for casting:
Other possible spellings:
# Use the normal Python idiom for avoiding keyword clashes
# and append a trailing underscore
new_object = old_object.as_(class_hint)
float_obj = int_obj.as_("float")
float_obj = int_obj.as_(float_class)
# Use a different word (such as, oh, "cast" perhaps?)
new_object = old_object.cast(class_hint)
float_obj = int_obj.cast("float")
float_obj = int_obj.cast(float_class)
You could make a PEP if you really wanted to, but it's going to be rejected.
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] Python-3.0, unicode, and os.environ
* Nick Coghlan wrote: > Toshio Kuratomi wrote: > > Note 2: If there isn't a parallel API on all platforms, for instance, > > Guido's proposal to not have os.environb on Windows, then you'll still > > have to have a platform specific check. (Likely you should try to > > access os.evironb in this instance and if it doesn't exist, use > > os.environ instead... and remember that you need to either change > > os.environ's data into str type or change os.environb's data into byte > > type.) > > Note that this is why I personally think the binary API variants > *should* exist on Windows, just with the sense of the system encoding > flipped around. > > That is, on *nix: > - underlying OS API uses bytes > - binary API just passes values straight through > - Unicode API uses the system encoding to encode Unicode names and > values to be passed to the OS API and to decode bytes names and values > received from the OS API > > While on Windows: > - underlying OS API uses Unicode > - Unicode API just passes values straight through > - binary API uses the system encoding to decode bytes names and values > to be passed to the OS API and to encode Unicode names and values > received from the OS API Now that is somewhat strange. That way you'll have two unreliable APIs and need to switch depending on the platform again. nd -- +[>++<-]>++>++[><-]>++.<[>++<-]>+++.--. +.< <.>[><-]>---.<+++[><-]>+.+. +.<+++[><-]>.---.<+++[><-]> +.<<.>+[>---<-]>+.<+[><-]>+.<+++[><-]>+.--.<<.>++ [>--<-]>.<+[>+<-]>.++..--.<+++[><-]>+. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
Aahz wrote: > I believe that it would be a shame and a disservice to Python if there > were a large proportion of the Python community that discouraged the use > of 3.0; I also believe it would be a shame and a disservice to Python if > you (and other people) tell conservatives like me that we should keep our > mouths shut. I don't think being honest about the situation is going to hurt anything in the long run. There are lots of advantages to 3.0, but also plenty of good reasons to stick with 2.x as well. At this point in time, my own recommendation would be that if someone doesn't have time to do a proper evaluation of the situation (talking production development here, not "learning for fun"), then I would probably still point them at 2.5. That recommendation will probably change to 2.6 in a couple of months (since it usually takes a few months after a release for the rest of the Python ecosystem to catch up with a new 2.x release). If they have the time though, my recommendation would be for them to do their *own* evaluation, looking both at things that favour 3.0 like Unicode handling and general developer convenience, as well as the things that currently favour 2.x like IO speed and availability of 3rd party libraries. 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] Python-3.0, unicode, and os.environ
André Malo wrote: >> While on Windows: >> - underlying OS API uses Unicode >> - Unicode API just passes values straight through >> - binary API uses the system encoding to decode bytes names and values >> to be passed to the OS API and to encode Unicode names and values >> received from the OS API > > Now that is somewhat strange. That way you'll have two unreliable APIs and > need to switch depending on the platform again. Sory, system encoding was probably a poor choice of words there, since that generally means mbcs when talking about windows (which would indeed be a very poor choice of encoding). For binary wrappers around the Windows Unicode APIs, I was thinking specifically of using UTF-8, since that should be able to encode anything the Unicode APIs can handle. 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] RELEASED Python 3.0 final
> Sorry, I don't think I can do that. It's difficult-to-impossible to leap > straight from Python 2.2 or 2.3 to 3.0 My experience is different. That is very well possible (of course, I haven't heard in a long time of a project that needs to maintain compatibility with 2.2). 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] Buildbots for 2.6 and 3.0
> Looking at http://www.python.org/dev/buildbot/, we are still missing buildbots > for the release26-maint and release30-maint branches. Is someone working on > that? Yes. I won't enable 2.6 build slaves until 2.5.3 is released, but will afterwards. 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] Python-3.0, unicode, and os.environ
On Sun, Dec 07, 2008, Nick Coghlan wrote: > > If the binary APIs are missing from a major platform (i.e. Windows) then > the choice to use them brings with it a major cross-platform portability > problem that should really be handled by the standard library. +1 -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ 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] "as" keyword woes
> Date: Sat, 6 Dec 2008 12:13:16 -0800 (PST) > From: Carl Banks <[EMAIL PROTECTED]> > Subject: Re: "as" keyword woes > To: [EMAIL PROTECTED] > Message-ID: > > (snip) > > If you write a PEP, I advise you to try to sound less whiny and than > you have in this thread. > > (snip) Ehem, well, such comments notwithstanding, I thank everyone who responded to my latest post on this topic for taking my inquiry seriously, and for providing cogent, focused, well-reasoned feedback while not resorting to name-calling, to false accusations on top of baseless assumptions, or to explicit personal attacks on my competence, sincerity, experience, credibility, or form. To you especially, I am grateful for your input for your years of service to the community and to the noble ideals you embody in the Python project. May the rest of us (not just myself) be ashamed of our lesser conduct and learn from you exemplary performance. So to summarize, having assimilated all responses over the past several days (python-list as well as python-dev, for the newcomers), I now accept the following as self-evident: -> "as", as a Python keyword, is a here to stay: Love it or leave it. -> Likewise ditto for the GIL: if you truly need Python concurrency within a single process, then use a Python implementation other than CPython. Season's greetings to all! Peace. Cheers, Warren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Sat, Dec 6, 2008 at 5:45 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Aahz wrote: >> I believe that it would be a shame and a disservice to Python if there >> were a large proportion of the Python community that discouraged the use >> of 3.0; I also believe it would be a shame and a disservice to Python if >> you (and other people) tell conservatives like me that we should keep our >> mouths shut. I hope I am not perceived as telling you to keep your mouth shut. I am merely hoping that you will decide for yourself after having heard me out. > I don't think being honest about the situation is going to hurt anything > in the long run. There are lots of advantages to 3.0, but also plenty of > good reasons to stick with 2.x as well. > > At this point in time, my own recommendation would be that if someone > doesn't have time to do a proper evaluation of the situation (talking > production development here, not "learning for fun"), then I would > probably still point them at 2.5. That recommendation will probably > change to 2.6 in a couple of months (since it usually takes a few months > after a release for the rest of the Python ecosystem to catch up with a > new 2.x release). > > If they have the time though, my recommendation would be for them to do > their *own* evaluation, looking both at things that favour 3.0 like > Unicode handling and general developer convenience, as well as the > things that currently favour 2.x like IO speed and availability of 3rd > party libraries. That sounds right. I just heard (via Martin) that PEP 3131 (Unicode letters in identifiers) is already a big hit in Japan. -- --Guido van Rossum (home page: http://www.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] Python-3.0, unicode, and os.environ
On Sat, Dec 6, 2008 at 6:51 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > André Malo wrote: >>> While on Windows: >>> - underlying OS API uses Unicode >>> - Unicode API just passes values straight through >>> - binary API uses the system encoding to decode bytes names and values >>> to be passed to the OS API and to encode Unicode names and values >>> received from the OS API >> >> Now that is somewhat strange. That way you'll have two unreliable APIs and >> need to switch depending on the platform again. > > Sory, system encoding was probably a poor choice of words there, since > that generally means mbcs when talking about windows (which would indeed > be a very poor choice of encoding). > > For binary wrappers around the Windows Unicode APIs, I was thinking > specifically of using UTF-8, since that should be able to encode > anything the Unicode APIs can handle. If the Unicode APIs only have correct unicode, sure. If not you'll get errors translating to UTF-8 (and the byte APIs are supposed to pass bad names through unaltered.) Kinda ironic, no? -- Adam Olsen, aka Rhamphoryncus ___ 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-3.0, unicode, and os.environ
Guido van Rossum wrote: > On Sat, Dec 6, 2008 at 10:53 AM, <[EMAIL PROTECTED]> wrote: >> I find it interesting to note that the only users in this discussion who >> actually have these problems in real life all have this attitude. It is >> expected that in an imperfect world we will have imperfect encodings, but it >> is super important that software which can open files can deal with not >> understanding the character translation of the filename. > > For file managers and similar tools I am absolutely 100% in agreement > -- that's why the binary APIs are there. > > Most apps aren't file managers or ftp clients though. The sky is not falling. > I agree that the sky is not falling (as long as we get a binary API for env vars in 3.1) but I'm still wondering what the use case you see is. Most apps aren't file managers or ftp clients but when they interact with files (for instance, a file selection dialog) they need to be able to show the user all the relevant files. So on an app-by-app basis the need for this is high. On a code basis, I'd hope that most file selection dialogs are pulled out into libraries... but that still doesn't help me identify when someone would expect that asking python for a list of all files in a directory or a specific set of files in a directory should, without warning, return only a subset of them. In what situations is this appropriate behaviour? -Toshio signature.asc Description: OpenPGP digital 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] Python-3.0, unicode, and os.environ
On 06:07 am, [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On Sat, Dec 6, 2008 at 10:53 AM, <[EMAIL PROTECTED]> wrote: I find it interesting to note that the only users in this discussion who actually have these problems in real life all have this attitude. For file managers and similar tools I am absolutely 100% in agreement -- that's why the binary APIs are there. Most apps aren't file managers or ftp clients though. The sky is not falling. Most apps aren't file managers or ftp clients but when they interact with files (for instance, a file selection dialog) they need to be able to show the user all the relevant files. So on an app-by-app basis the need for this is high. While I tend to agree emphatically with this, the *real* solution here is a path-abstraction library. In separate discussions, the difficulty of getting such a thing into the standard library has been discussed, due to the wide variety of opinions as to what it should look like (and the shocking level of difficulty involved in making such a thing really work correctly). I'd be very happy to talk to you off-list about my ideas for such a thing, but I'd rather not resurrect yet another tedious discussion here just now :). On a code basis, I'd hope that most file selection dialogs are pulled out into libraries... but that still doesn't help me identify when someone would expect that asking python for a list of all files in a directory or a specific set of files in a directory should, without warning, return only a subset of them. In what situations is this appropriate behaviour? If you say listdir(unicode) on a POSIX OS, your program is saying "I only know how to deal with unicode results from this function, so please only give me those.". If your program is smart enough to deal with bytes, then you would have asked for bytes, no? Returning only filenames which can be properly decoded makes sense. Otherwise everyone needs to learn about this highly confusing issue, even for the simplest scripts. Skipping undecodable values is good enough that it will work 90% of the time. When you need to get to 100%, it won't be impossible - the bytes APIs will be there. In the longer term, hopefully some path abstraction will eventually be there too. We should not wait for a perfectly correct path abstraction to arrive before providing the primitives to do it yourself, though. ___ 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
