Re: [Python-Dev] [Python-checkins] devguide: Move Misc/maintainers.rst here and rename to experts.rst.
Hi, On Thu, Jan 20, 2011 at 04:56, brett.cannon python-check...@python.org wrote: +Unless a name is followed by a '*', you should never assign an issue to +that person, only make them nosy. Names followed by a '*' may be assigned +issues involving the module or topic for which the name has a '*'. isn't last sentence a bit weird? I'm not native but Names followed by a '*' may issues assigned for the modules be a bit better? ok, fairly minor you can also ignore it :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Jan 19, 2011, at 11:39 PM, Toshio Kuratomi wrote: Tangent: This is not true about Linux. UTF-8 is a matter of the interpretation of the filesystem bytes that the user specifies by setting their system locale. Setting system locale to ASCII for use in system-wide scripts, is quite common as is changing locale settings in other parts of the world (as I can tell you from the bug reports colleagues CC me on to fix for the problems with unicode support in their python2 programs). Fortunately, there's been some (slow) movement towards adding a C.UTF-8 locale and using that by default where C (ASCII) is currently used. So that may be less of a problem in a few years time. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
Le mercredi 19 janvier 2011 à 20:39 -0800, Toshio Kuratomi a écrit :
Teaching students to write non-portable code (relying on filesystem encoding
where your solution is, don't upload to pypi anything that has non-ascii
filenames) seems like the exact opposite of how you'd want to shape a young
student's understanding of good programming practices.
That was already discuted before: see PEP 3131.
http://www.python.org/dev/peps/pep-3131/#common-objections
If the teacher choose to use non-ASCII, (s)he is responsible to explain
the consequences to his/her students :-)
In a school, you can use the same configuration
(encoding) on all computers.
In a school computer lab perhaps. But not on all the students' and
professors' machines. How many professors will be cursing python when they
discover that the example code that they wrote on their Linux workstation
doesn't work when the students try to use it in their windows computer lab?
Because some students use a stupid or misconfigured OS, Python should
only accept ASCII names? So, why do Python 3 support non-ASCII
filenames: it is very well known that non-ASCII filenames is the root in
many troubles! Should we simply drop unicode support for all filenames?
And maybe restrict bytes filenames to bytes in [0; 127]? Or better,
restrict to [32; 126] (U+007f causes some troubles in some terminals).
I think that in 2011, non-ASCII filenames are well supported on all
(modern) operating systems. Issues with non-ASCII filenames are OS
specific and should be fixed by the user (the admin of the computer).
Additionally, those other filesystem operations have
been growing the ability to take byte values and encoding parameters because
unicode translation via a single filesystem encoding is a good default but
not a complete solution.
If you are unable to configure correctly your system to decode/encode
correctly filenames, you should just avoid non-ASCII characters in the
module names.
You only give theorical arguments: did you at least try to use non-ASCII
module names on your system with Python 3.2? I suppose that it will just
work and you will never notice that the unicode module name (on import
café) in encoded to bytes.
It fails on on OSes using filesystem encodings other than UTF-8 (eg.
Windows)... because of a Python bug, and I just asked if I have to fix
this bug (or if we should deny non-ASCII names). If the bug is fixed, it
will works everywhere.
Your solution creates modules which aren't portable
More and more operating systems use a filesystem encoding able to encode
any Unicode characters. ASCII-only always give you the best portability,
but I think that today you can start to play with (at least) ISO-8859-1
characters (café should work on all operating systems). If you don't
Unicode issues (I personally love them!), just use ASCII everywhere.
One of my proposals creates python code which isn't portable. The other one
suffers some of the same disadvantages as your solution in portability but
allows for tools that could automatically correct modules.
__import__('café'.encode('UTF-8')) or
__import__('café'.encode('ISO-8859-1')) is less portable than
__import__('café').
You think that if a module is named appropriately on one system but is not
portable to another
system, that's fine.
No, I am not saying that.
I say that if your name is broken while you transfer your project from a
system to another (eg. decompressing an archive creates filenames with
mojibake in the filenames), you should fix your transfer procedure (eg.
use another archive format, use a script to fix filenames, or anything
else), but don't try to handle invalid filenames.
Setting system locale to ASCII for use in system-wide scripts
This is stupid :-) Yes, on such system you, cannot open *any* non-ASCII
file with Python 3 (except if you work, as Python 2, on bytes
filenames).
Python cannot do anything to improve Unicode support on such system:
only the administrator have to something to do for that.
I know that you can give me many examples of systems where Unicode
doesn't work because the system is not correctly configured. But my
opinion is that we should support non-ASCII names because there are
somewhere some systems where Unicode is fully functionnal :-)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88119 - in python/branches/py3k/Doc: library/inspect.rst whatsnew/3.2.rst
Le jeudi 20 janvier 2011 à 05:03 +0100, raymond.hettinger a écrit :
* Python's import mechanism can now load modules installed in directories
with
- non-ASCII characters in the path name.
+ non-ASCII characters in the path name:
+
+ import møøse.bites
(Required extensive work by Victor Stinner in :issue:`9425`.)
Ooops, it is not the good example :-) In this example, møøse is not a
module path, but a module name... And Python 3.2 doesn't support
correctly non-ASCII module names on all operating systems yet (see
[Python-Dev] Import and unicode: part two thread :-)).
#9425 only concerns sys.path (eg.
sys.path.append('/home/møøse/modules/')).
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Wed, Jan 19, 2011 at 5:01 PM, Simon Cross hodgestar+python...@gmail.com wrote: On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner victor.stin...@haypocalc.com wrote: (a) Python 3 doesn't support non-ASCII module names -0: I'm vaguely against this being supported because I'd rather not have to deal with what happens when the guess regarding the filesystem encoding is wrong. On the other hand, a general encouragement to stick to ASCII module names is probably functionally equivalent without imposing a hard restriction. I'm changing my vote on this to a +1 for two reasons: * Initially I thought this wasn't supported by Python at all but I see that currently it is supported but that support is broken (or at least limited to UTF-8 filesystem encodings). Since support is there, might as well make it better (especially if it tidies up the code base at the same time). * I still don't think it's a good idea to give modules non-ASCII names but the consenting adults approach suggests we should let people shoot themselves in the foot if they believe they have good reason to do so. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88121 - python/branches/py3k/Doc/whatsnew/3.2.rst
Le jeudi 20 janvier 2011 à 10:04 +0100, raymond.hettinger a écrit : +Some operating systems allow direct access to the unencoded bytes in the +environment. If so, the :attr:`os.supports_bytes_environ` constant will be +true. + +For direct access to unencoded environment variables (if available), +use the new :func:`os.getenvb` function or use :data:`os.environb` +which is a bytes version of :data:`os.environ`. Hum, I think that undecoded bytes term is more appropriate. You can decode bytes and encode characters, but not the opposite. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r88122 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Thu, 20 Jan 2011 10:47:04 +0100 (CET) raymond.hettinger python-check...@python.org wrote: +Code Repository +=== + +In addition to the existing Subversion code repository at http://svn.python.org +there is now a `Mercurial http://mercurial.selenic.com/`_ repository at +http://hg.python.org/ . Shouldn't we wait until that repository is ready? Right now people willing to work with it will get the surprise that it hasn't been updated for 3 months. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 10:08 PM, Simon Cross hodgestar+python...@gmail.com wrote: I'm changing my vote on this to a +1 for two reasons: * Initially I thought this wasn't supported by Python at all but I see that currently it is supported but that support is broken (or at least limited to UTF-8 filesystem encodings). Since support is there, might as well make it better (especially if it tidies up the code base at the same time). * I still don't think it's a good idea to give modules non-ASCII names but the consenting adults approach suggests we should let people shoot themselves in the foot if they believe they have good reason to do so. I'm also +1 on this for the reasons Simon gives. I should have a chance to look at the patch this weekend. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88121 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Thu, Jan 20, 2011 at 10:41 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Le jeudi 20 janvier 2011 à 10:04 +0100, raymond.hettinger a écrit : +Some operating systems allow direct access to the unencoded bytes in the +environment. If so, the :attr:`os.supports_bytes_environ` constant will be +true. + +For direct access to unencoded environment variables (if available), +use the new :func:`os.getenvb` function or use :data:`os.environb` +which is a bytes version of :data:`os.environ`. Hum, I think that undecoded bytes term is more appropriate. You can decode bytes and encode characters, but not the opposite. I was going to say the same thing. encoded, undecoded or raw would all work, but unencoded definitely isn't right. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r88122 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Thu, Jan 20, 2011 at 3:11 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 20 Jan 2011 10:47:04 +0100 (CET) raymond.hettinger python-check...@python.org wrote: +Code Repository +=== + +In addition to the existing Subversion code repository at http://svn.python.org +there is now a `Mercurial http://mercurial.selenic.com/`_ repository at +http://hg.python.org/ . Shouldn't we wait until that repository is ready? Right now people willing to work with it will get the surprise that it hasn't been updated for 3 months. Should that perhaps be http://code.python.org/hg/ ? I've been using that repository for the last two months or so, and it seems to be up to date (to within an hour or so, at least). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r88122 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Thu, 20 Jan 2011 15:59:39 +0200 Nadeem Vawda nadeem.va...@gmail.com wrote: On Thu, Jan 20, 2011 at 3:11 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 20 Jan 2011 10:47:04 +0100 (CET) raymond.hettinger python-check...@python.org wrote: +Code Repository +=== + +In addition to the existing Subversion code repository at http://svn.python.org +there is now a `Mercurial http://mercurial.selenic.com/`_ repository at +http://hg.python.org/ . Shouldn't we wait until that repository is ready? Right now people willing to work with it will get the surprise that it hasn't been updated for 3 months. Should that perhaps be http://code.python.org/hg/ ? I've been using that repository for the last two months or so, and it seems to be up to date (to within an hour or so, at least). Indeed. However, this will not be the definitive repository (as used after the migration), so I'm not sure it deserves mentioning in the what's new. Also, it's technically not new at all :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 5:16 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Jan 20, 2011 at 10:08 PM, Simon Cross hodgestar+python...@gmail.com wrote: I'm changing my vote on this to a +1 for two reasons: * Initially I thought this wasn't supported by Python at all but I see that currently it is supported but that support is broken (or at least limited to UTF-8 filesystem encodings). Since support is there, might as well make it better (especially if it tidies up the code base at the same time). * I still don't think it's a good idea to give modules non-ASCII names but the consenting adults approach suggests we should let people shoot themselves in the foot if they believe they have good reason to do so. I'm also +1 on this for the reasons Simon gives. Same here. *Most* code will never be shared, or will only be shared between users in the same community. When it goes wrong it's also a learning opportunity. :-) I should have a chance to look at the patch this weekend. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
(Hi, I'm writing from an address different to the one I'm subscribed with to the list because I don't have reverse dns in my mail server and mail.python.org rejects my messages. I hope that's not much trouble) Maybe Python should always use an ASCII encodable filename for modules: a translation of the module name into an ASCII encodable string that, preferrably, was the same as the module name if the module name didn't have any non-ASCII characters. Like, if the code said: import cafe Python would look for a file named: cafe.py but if the code said: import café then Python would look, in any platform, for a file named: cafeacute;.py or caf#233;.py or something nicer. Something along the lines of xmlcharrefreplace. Just an idea. Andy. El 1/20/11 12:21 a.m., Glyph Lefkowitz escribió: On Jan 20, 2011, at 12:19 AM, Glenn Linderman wrote: Now if the stuff after m_ was the hex UTF-8 of café, that could get interesting :) (As it happens, it's the hex digest of the MD5 of the UTF-8 of café... ;-)) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/andy%40lists.teijelo.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 12:51:29PM +0100, Victor Stinner wrote: Le mercredi 19 janvier 2011 à 20:39 -0800, Toshio Kuratomi a écrit : Teaching students to write non-portable code (relying on filesystem encoding where your solution is, don't upload to pypi anything that has non-ascii filenames) seems like the exact opposite of how you'd want to shape a young student's understanding of good programming practices. That was already discuted before: see PEP 3131. http://www.python.org/dev/peps/pep-3131/#common-objections If the teacher choose to use non-ASCII, (s)he is responsible to explain the consequences to his/her students :-) It's not discussed in that PEP section. The PEP section says this: People claim that they will not be able to use a library if to do so they have to use characters they cannot type on their keyboards. Whether you can type it at your keyboard or not is not the problem here. The problem is portability. The students and professors are sharing code with each other. But because of a mixture of operating systems (let alone locale settings), the code written by one partner is unable to run on the computer of the other. If non-ascii filenames without a defined encoding are considered a feature, python cannot even issue a descriptive error when this occurs. It can only say that it could not find the module but not why. A restriction on module names to ascii only could actually state that module names are not allowed to be non-ASCII when it encounters the import line. In a school, you can use the same configuration (encoding) on all computers. In a school computer lab perhaps. But not on all the students' and professors' machines. How many professors will be cursing python when they discover that the example code that they wrote on their Linux workstation doesn't work when the students try to use it in their windows computer lab? Because some students use a stupid or misconfigured OS, Python should only accept ASCII names? Just a note -- you'll get much farther if you refrain from calling names. It just makes me think that you aren't reading and understanding the issue I'm raising. My examples that you're replying to involve two properly configured OS's. The Linux workstations are configured with a UTF-8 locale. The Windows OS's use wide character unicode. The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. So, why do Python 3 support non-ASCII filenames: it is very well known that non-ASCII filenames is the root in many troubles! Should we simply drop unicode support for all filenames? And maybe restrict bytes filenames to bytes in [0; 127]? Or better, restrict to [32; 126] (U+007f causes some troubles in some terminals). If you want to argue that because python3 supports non-ascii filenames in other code, then the logical extension is that the import mechanism should support importing module names defined by byte sequences. I happen to think that import has a lot of differences between it and other filenames as I've said three times now. I think that in 2011, non-ASCII filenames are well supported on all (modern) operating systems. Issues with non-ASCII filenames are OS specific and should be fixed by the user (the admin of the computer). Additionally, those other filesystem operations have been growing the ability to take byte values and encoding parameters because unicode translation via a single filesystem encoding is a good default but not a complete solution. If you are unable to configure correctly your system to decode/encode correctly filenames, you should just avoid non-ASCII characters in the module names. This seems like an argument to only have unicode versions of all filesystem operations. Since you've been spearheading the effort to have bytes versions of things that access filenames, environment variables, etc, I don't think that you seriously mean that. Perhaps there is a language issue here. You only give theorical arguments: did you at least try to use non-ASCII module names on your system with Python 3.2? I suppose that it will just work and you will never notice that the unicode module name (on import café) in encoded to bytes. Yes I did and I got it to fail a cornercase as I showed twice with the same example in other posts. However, I want to make clear here that the issue is not that I can create a non-ascii filename and then import it. The issue is that I can create a non-ascii filename and then try to share it with the usual tools and it won't work on the recipient's system. (A tangent is whether the recipient's system is physically distinct from mine or only has a different environment on the same physical host.) It fails on on OSes using filesystem encodings other than UTF-8 (eg. Windows)... because of a Python bug, and I just asked if I have to
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 11:45 AM, Andy Teijelo ateij...@gmail.com wrote: .. but if the code said: import café then Python would look, in any platform, for a file named: cafeacute;.py or caf#233;.py or something nicer. Something along the lines of xmlcharrefreplace. Just an idea. Curiously, something like this already happens on OSX when filename is not valid UTF-8. For example, open(b'\xdb\xcd', 'w').close() open(b'\xdb\xcd') _io.TextIOWrapper name=b'\xdb\xcd' mode='r' encoding='UTF-8' but the actual file created is named %DB%CD. (Looks like URL-encoding). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 12:44 PM, Toshio Kuratomi a.bad...@gmail.com wrote: .. My examples that you're replying to involve two properly configured OS's. The Linux workstations are configured with a UTF-8 locale. The Windows OS's use wide character unicode. The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. I re-read your posts on this thread, but could not find the examples that you refer to. ISTM, your hypothetical students should have no problem as long as their professor uses proper tools to package her code. For example, if she uses a recent version of zip that supports the Info-ZIP Unicode Comment Extra Field (see http://www.pkware.com/documents/casestudies/APPNOTE.TXT) and students use similarly up to date unzip tool, the shared code should work as expected. Similarly, I would be surprised if Samba server would not be able to present a shared Linux partition that uses UTF-8 encoding to a Windows client in a way that will make wopen() work as expected. The problem with current Python import mechanism is that it does not use wopen() on Windows and instead, attempts to encode Unicode module name into a mythical single-byte filesystem encoding (locale ANSI code page?) and calls byte-oriented open(char *) on the result. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Short doc about where to get tech help related to developing Python.
On Wed, Jan 19, 2011 at 15:21, Sandro Tosi sandro.t...@gmail.com wrote: Hi, On Wed, Jan 19, 2011 at 23:19, brett.cannon python-check...@python.org wrote: +Where to Get Help += +If you are working on Python it is very possible you will come across an issue +where you need some assistance in solving (this happens to core developers all +the time). You have a couple of options depending on what kind of help you need. +If the question involves process or tool usage then please check the developer's +guide first as is should answer your question. as it should +Filing a Bug + +If you come across an odd error message that seems like a bug, then file a bug +on the `issue tracker`_. In the bug you can explain that you are not sure why +the error is coming up or that the exact nature of the problem is. Someone will ...or what the exact...? +Asking a Technical Question +--- +You have two avenues of communication out of the :ref:`myriad of options +available communication`. If you are comfortable with IRC you can try asking +in #python-dev. Typically there are a couple of experienced developers, ranging +from triagers to core developers, who can ask questions about developing for who can answer questions They can ask as well. =) Anyway, all changes coming in the next push. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Move Misc/maintainers.rst here and rename to experts.rst.
It's just a bit wordy. I simplified it. On Thu, Jan 20, 2011 at 01:22, Sandro Tosi sandro.t...@gmail.com wrote: Hi, On Thu, Jan 20, 2011 at 04:56, brett.cannon python-check...@python.org wrote: +Unless a name is followed by a '*', you should never assign an issue to +that person, only make them nosy. Names followed by a '*' may be assigned +issues involving the module or topic for which the name has a '*'. isn't last sentence a bit weird? I'm not native but Names followed by a '*' may issues assigned for the modules be a bit better? ok, fairly minor you can also ignore it :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, Jan 20, 2011 at 01:43:03PM -0500, Alexander Belopolsky wrote: On Thu, Jan 20, 2011 at 12:44 PM, Toshio Kuratomi a.bad...@gmail.com wrote: .. My examples that you're replying to involve two properly configured OS's. The Linux workstations are configured with a UTF-8 locale. The Windows OS's use wide character unicode. The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. I re-read your posts on this thread, but could not find the examples that you refer to. Examples might be a bad word in this context. Victor was commenting on the two brainstorm ideas for alternatives to ascii-only that I had. One was: * Mandate that every python module on a platform has a specific encoding (rather than the value of the locale) The other was: * allow using byte strings for import I think that both ideas are inferior to mandating that every python module filename is ascii. From what I'm getting from Victor's posts is that he, at least, considers the portability problems to be ignorable because dealing with ambiguous file name encodings is something that he'd like to force third party tools to deal with. -Toshio pgpdh2k6Fwv56.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving stuff out of Misc and over to the devguide
Short of moving README.coverity (I'm waiting to here back from the company), I'm done with my tweaks to the directory. On Wed, Jan 19, 2011 at 15:31, Brett Cannon br...@python.org wrote: OK, here is my plan that I will implement: MOVE -- developers.txt maintainers.rst README.gdb README.coverity README.Emacs DELETE (seem way too old to still be relevant; tell me if I am wrong) --- README.OpenBSD README.AIX cheatsheet LEAVE everything else (with README properly edited and simplified to only list files with non-obvious names) On Mon, Jan 17, 2011 at 12:32, Brett Cannon br...@python.org wrote: There is a bunch of stuff in Misc that probably belongs in the devguide (under Resources) instead of in svn. Here are the files I think can be moved (in order of how strongly I think they should be moved): PURIFY.README README.coverty README.klocwork README.valgrind Porting developers.txt maintainers.rst SpecialBuilds.txt Now before anyone yells that is inconvenient, don't forget that all core developers can check out and edit the devguide, and that almost all of the files listed (SpecialBuilds.txt is the exception) are typically edited and viewed on their own. Anyway, if there is a file listed here you don't think should move out of py3k and into the devguide, speak up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving stuff out of Misc and over to the devguide
Brett, I'm sure I just missed it, but where is the devguide in the Subversion tree? Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88127 - in python/branches/py3k/Misc: README.AIX README.OpenBSD cheatsheet
brett.cannon wrote: Author: brett.cannon Date: Thu Jan 20 20:34:35 2011 New Revision: 88127 Log: Remove some outdated files from Misc. Removed: python/branches/py3k/Misc/README.AIX Are you sure that the AIX README is outdated ? It explains some of the details of why there are scripts like ld_so_aix which are still needed on AIX. python/branches/py3k/Misc/README.OpenBSD Same here. Does OpenBSD 4.x still have the issues mentioned in the file. python/branches/py3k/Misc/cheatsheet Wouldn't it be better to update this useful file (as part of your PSF grant) ? Most of it still applies to Py3. Regarding some other things you removed or moved: DSVN-Python3/Misc/maintainers.rst DSVN-Python3/Misc/developers.txt Why were these removed from the source archive ? They are useful to have around for users wanting to report bugs and are useful to follow the development of the core team between different Python versions. DSVN-Python3/Misc/python-mode.el Why is this gone ? It's a useful file for Emacs users and usually more recent than what you get with your Emacs installation. DSVN-Python3/Misc/AIX-NOTES I guess this was renamed to README.AIX before you removed it. See above. DSVN-Python3/Misc/PURIFY.README Why is this outdated ? Should probably be renamed to README.Purify. DSVN-Python3/Misc/RFD That's a piece of Python history. These nuggets should stay in the Python source archive, IMHO. DSVN-Python3/Misc/setuid-prog.c This is useful for people writing setuid programs in Python and avoids many of the usual pitfalls: http://mail.python.org/pipermail/python-list/1999-April/620658.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2011) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving stuff out of Misc and over to the devguide
It's not in the svn tree; it's an Hg repo: ssh://h...@hg.python.org/devguide . The link is also listed in the Resources section of the devguide. On Thu, Jan 20, 2011 at 11:59, s...@pobox.com wrote: Brett, I'm sure I just missed it, but where is the devguide in the Subversion tree? Thx, Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88127 - in python/branches/py3k/Misc: README.AIX README.OpenBSD cheatsheet
On Thu, 20 Jan 2011 21:09:47 +0100 M.-A. Lemburg m...@egenix.com wrote: brett.cannon wrote: Author: brett.cannon Date: Thu Jan 20 20:34:35 2011 New Revision: 88127 Log: Remove some outdated files from Misc. Removed: python/branches/py3k/Misc/README.AIX Are you sure that the AIX README is outdated ? It explains some of the details of why there are scripts like ld_so_aix which are still needed on AIX. If someone wants to contribute an up-to-date version they're welcome. The version which has been deleted was totally obsolete. http://bugs.python.org/issue10709 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Jan 20, 2011, at 11:46 AM, Guido van Rossum wrote: On Thu, Jan 20, 2011 at 5:16 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Jan 20, 2011 at 10:08 PM, Simon Cross hodgestar+python...@gmail.com wrote: I'm changing my vote on this to a +1 for two reasons: * Initially I thought this wasn't supported by Python at all but I see that currently it is supported but that support is broken (or at least limited to UTF-8 filesystem encodings). Since support is there, might as well make it better (especially if it tidies up the code base at the same time). * I still don't think it's a good idea to give modules non-ASCII names but the consenting adults approach suggests we should let people shoot themselves in the foot if they believe they have good reason to do so. I'm also +1 on this for the reasons Simon gives. Same here. *Most* code will never be shared, or will only be shared between users in the same community. When it goes wrong it's also a learning opportunity. :-) Despite my usual proclivity for being contrarian, I find myself in agreement here. Linux users with locales that don't specify UTF-8 frankly _should_ have to deal with all kinds of nastiness until they can transcode their filesystems. MacOS and Windows both have a right answer here and your third-party tools shouldn't create mojibake in your filenames. However, I feel that we should not necessarily be making non-ASCII programmers second-class citizens, if they are to be supported at all. The obvious outcome of the current regime is, if you want your code to work in the wider world, you have to make everything ASCII, so non-ASCII programmers have to do a huge amount of extra work to prepare their stuff for distribution. As an english speaker I'd be happy about that, but as a person with a lot of Chinese in-laws, it gives me pause. There is a difference between sharing code for inspection and editing (where a little codec pain is good for the soul: set your locale to UTF-8 and forget it already!) and sharing code so that a (non-programming) user can just run it. If I can write software in English and distribute it to Chinese people, fair's fair, they should be able to write it in chinese and have it work on my computer. To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? That way a distributed egg would be importable from a zipfile regardless of how screwed up the distribution target machine's filesystem is. (And this is yet more motivation for distributors to set zip_safe=True.)___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88127 - in python/branches/py3k/Misc: README.AIX README.OpenBSD cheatsheet
On Thu, Jan 20, 2011 at 12:09, M.-A. Lemburg m...@egenix.com wrote: brett.cannon wrote: Author: brett.cannon Date: Thu Jan 20 20:34:35 2011 New Revision: 88127 Log: Remove some outdated files from Misc. Removed: python/branches/py3k/Misc/README.AIX Are you sure that the AIX README is outdated ? It explains some of the details of why there are scripts like ld_so_aix which are still needed on AIX. I asked earlier if anyone thought they were not and no one spoke up. Same goes for README.OpenBSD. python/branches/py3k/Misc/README.OpenBSD Same here. Does OpenBSD 4.x still have the issues mentioned in the file. python/branches/py3k/Misc/cheatsheet Wouldn't it be better to update this useful file (as part of your PSF grant) ? Most of it still applies to Py3. That file was not even updated to cover context managers and the 'with' keyword so it's been outdated for years and for at least a couple of releases now. If no one has cared to update it for the last two releases of Python 2.x I don't see a point in my spending time doing an update, especially considering it is a duplicate of official docs which is just asking for maintenance trouble. Regarding some other things you removed or moved: D SVN-Python3/Misc/maintainers.rst D SVN-Python3/Misc/developers.txt Why were these removed from the source archive ? They are useful to have around for users wanting to report bugs and are useful to follow the development of the core team between different Python versions. They are in the devguide now. D SVN-Python3/Misc/python-mode.el Why is this gone ? It's a useful file for Emacs users and usually more recent than what you get with your Emacs installation. Barry removed that (I think) two months ago; I was simply updating the README to reflect the actual state of the directory. D SVN-Python3/Misc/AIX-NOTES I guess this was renamed to README.AIX before you removed it. See above. D SVN-Python3/Misc/PURIFY.README Why is this outdated ? Should probably be renamed to README.Purify. Because Barry said it was considering it contained an email that has not worked in a decade. D SVN-Python3/Misc/RFD That's a piece of Python history. These nuggets should stay in the Python source archive, IMHO. Once again, it was already not there and this is just a cleanup of the file; I didn't delete it. D SVN-Python3/Misc/setuid-prog.c This is useful for people writing setuid programs in Python and avoids many of the usual pitfalls: Another cleanup of the file. -Brett http://mail.python.org/pipermail/python-list/1999-April/620658.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2011) Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
Toshio Kuratomi: My examples that you're replying to involve two properly configured OS's. The Linux workstations are configured with a UTF-8 locale. The Windows OS's use wide character unicode. The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. This implies a symmetric issue,. but I can not see how there can be a problem with non-ASCII module names on Windows as the file system allows all Unicode characters so can represent any module name. OS X is also based on Unicode file names. While it is possible to mount file systems on Windows or OS X that do not support Unicode file names these are a very unusual situation that will cause problems in other ways. Common Linux distributions like Ubuntu and Fedora now default to UTF-8 locales. The situations in which users may encounter installations that do not support Unicode file names have reduced greatly. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Thu, 20 Jan 2011 15:27:08 -0500 Glyph Lefkowitz gl...@twistedmatrix.com wrote: To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? It already has, but it's dependent on a flag in the zip file itself (actually, one flag per archived file in the zip it seems). (by the way, it would be nice if your text/mail editor wrapped lines at 80 characters or something) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On 1/20/2011 12:27 PM, Glyph Lefkowitz wrote: To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? That way a distributed egg would be importable from a zipfile regardless of how screwed up the distribution target machine's filesystem is. (And this is yet more motivation for distributors to set zip_safe=True.) I guess zip_safe is a distutils thing, and I haven't (yet) used distutils. But regarding zip files, I was trying to figure out if ZipFile module supported the CP437/UTF-8 flag, but its documentation seems to predate that concept, and just talks about unencoded byte streams. Yet, I think I have Python3 code that passes str to the filenames, and that works, so some amount of encoding and decoding to something must be happening behind the documentation's back? It does seem that if a ZipFile is created with the UTF-8 flag turned on, that Python should respect that, and that should be independent of the file system configured encoding on the local machine on which the ZipFile is used (as long as the name of the ZipFile is usable). I do know that listing filenames from a zip file created without the UTF-8 flag, using ZipFile to access it and place the names inside a web page that specifies its encoding to be UTF-8 produces illegal characters, so I've become tuned in recently to the zip files do have such a flag, and have been learning the right options to turn it on for the command line tools I use to create zip files... but was surprised when investigating the same for ZipFile. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Move Misc/README.Emacs to here.
Hi, On Thu, Jan 20, 2011 at 20:33, brett.cannon python-check...@python.org wrote: +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 78 + coding: utf-8 + End: maybe this can be removed now Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88127 - in python/branches/py3k/Misc: README.AIX README.OpenBSD cheatsheet
On Thu, Jan 20, 2011 at 3:37 PM, Brett Cannon br...@python.org wrote: On Thu, Jan 20, 2011 at 12:09, M.-A. Lemburg m...@egenix.com wrote: .. python/branches/py3k/Misc/cheatsheet Wouldn't it be better to update this useful file (as part of your PSF grant) ? Most of it still applies to Py3. That file was not even updated to cover context managers and the 'with' keyword so it's been outdated for years and for at least a couple of releases now. If no one has cared to update it for the last two releases of Python 2.x I don't see a point in my spending time doing an update, especially considering it is a duplicate of official docs which is just asking for maintenance trouble. You should probably close issue4819 with won't fix in this case. http://bugs.python.org/issue4819 I am with MAL on this one, though. I don't think equivalent presentation is duplicated anywhere in the docs. It would be better to have it updated and moved to Doc. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88127 - in python/branches/py3k/Misc: README.AIX README.OpenBSD cheatsheet
On Thu, Jan 20, 2011 at 13:09, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Thu, Jan 20, 2011 at 3:37 PM, Brett Cannon br...@python.org wrote: On Thu, Jan 20, 2011 at 12:09, M.-A. Lemburg m...@egenix.com wrote: .. python/branches/py3k/Misc/cheatsheet Wouldn't it be better to update this useful file (as part of your PSF grant) ? Most of it still applies to Py3. That file was not even updated to cover context managers and the 'with' keyword so it's been outdated for years and for at least a couple of releases now. If no one has cared to update it for the last two releases of Python 2.x I don't see a point in my spending time doing an update, especially considering it is a duplicate of official docs which is just asking for maintenance trouble. You should probably close issue4819 with won't fix in this case. http://bugs.python.org/issue4819 I am with MAL on this one, though. I don't think equivalent presentation is duplicated anywhere in the docs. It would be better to have it updated and moved to Doc. If someone wants to update I'm not objecting, I'm just saying I view getting the devguide done and moving on to the Python 2 - 3 porting guide more important. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
Am 20.01.2011 12:51, schrieb Victor Stinner: You only give theorical arguments Read Anathem lately? ;) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Fri, Jan 21, 2011 at 5:27 AM, Toshio Kuratomi a.bad...@gmail.com wrote: I think that both ideas are inferior to mandating that every python module filename is ascii. From what I'm getting from Victor's posts is that he, at least, considers the portability problems to be ignorable because dealing with ambiguous file name encodings is something that he'd like to force third party tools to deal with. I think you're starting from an incorrect premise: we *already* allow non-ASCII module names in Py3k. They just don't always work properly, hence why people are currently much, much better off using pure ASCII for their module names (as ASCII is still the lowest common denominator for internet communication). However, you are proposing that, instead of attempting to fix at least some of the cases where it doesn't work, we throw up our hands and tell people Since some poorly configured systems have trouble with this feature, we're taking it away from everybody. Sorry if this breaks your code. While there may be situations where that's a valid approach, this isn't one of them. Yes, non-ASCII filenames are problems for all sorts of reasons (with Python's historically poor support being one of them). The idea is that we're striving to no longer be part of that problem, even if it isn't within our power to fix it entirely. Once we fix the core to handle various Unicode issues, then over time that support can ripple out through the rest of the Python ecosystem - we don't expect everything to magically just work as soon as the basic issue in the core is fixed. It's going to be *years* before non-ASCII file names are as portable as pure ASCII ones (it kind of reminds me of the era when you had to avoid spaces in filenames because so many applications choked on them, even after the OS had been updated to support them). As far as the question of filenames not being re-encoded properly when copied between two systems, then yes, that *is* a problem with the third party tools used to do the copying. Such tools will break any code that uses the str APIs to access the filesystem. To deal with the case of undecodable filenames that the import system skips over, it is certainly possibly that importlib or runpy (probably the former) could acquire a function that allowed a named file to imported directly (with a specific module name) rather than requiring the import system to search for it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Copy over the dev FAQ and *only* strip out stuff covered elsewhere in the
On Fri, Jan 21, 2011 at 6:42 AM, brett.cannon python-check...@python.org wrote: brett.cannon pushed 82d3a1b694b3 to devguide: http://hg.python.org/devguide/rev/82d3a1b694b3 changeset: 167:82d3a1b694b3 user: Brett Cannon br...@python.org date: Thu Jan 20 12:40:47 2011 -0800 summary: Copy over the dev FAQ and *only* strip out stuff covered elsewhere in the devguide. Nick Coghlan should be a happy boy after this. Yay, thanks :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87815 - peps/trunk/pep-3333.txt
On Fri, Jan 7, 2011 at 4:39 PM, phillip.eby python-check...@python.orgwrote:
Author: phillip.eby
Date: Fri Jan 7 16:39:27 2011
New Revision: 87815
Log:
More bytes I/O fixes
Modified:
peps/trunk/pep-.txt
Modified: peps/trunk/pep-.txt
==
--- peps/trunk/pep-.txt (original)
+++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011
@@ -310,9 +310,9 @@
elif not headers_sent:
# Before the first output, send the stored headers
status, response_headers = headers_sent[:] = headers_set
- sys.stdout.write('Status: %s\r\n' % status)
+ sys.stdout.buffer.write('Status: %s\r\n' % status)
for header in response_headers:
- sys.stdout.write('%s: %s\r\n' % header)
+ sys.stdout.buffer.write('%s: %s\r\n' % header)
Also note that .buffer might not be available in some cases (i.e. when
sys.stdout has been replaced with other objects).
sys.stdout.write('\r\n')
sys.stdout.buffer.write(data)
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87815 - peps/trunk/pep-3333.txt
On Jan 20, 2011, at 9:31 PM, Ezio Melotti wrote:
Modified: peps/trunk/pep-.txt
==
--- peps/trunk/pep-.txt (original)
+++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011
@@ -310,9 +310,9 @@
elif not headers_sent:
# Before the first output, send the stored headers
status, response_headers = headers_sent[:] = headers_set
- sys.stdout.write('Status: %s\r\n' % status)
+ sys.stdout.buffer.write('Status: %s\r\n' % status)
for header in response_headers:
- sys.stdout.write('%s: %s\r\n' % header)
+ sys.stdout.buffer.write('%s: %s\r\n' % header)
Also note that .buffer might not be available in some cases (i.e. when
sys.stdout has been replaced with other objects).
Do you have a recommendation for a better way to do bytes I/O on stdin/sydout,
then?...just saying that .buffer might not be available isn't a very useful
comment unless there's a replacement idiom...
James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote: On Thu, 20 Jan 2011 15:27:08 -0500 Glyph Lefkowitz gl...@twistedmatrix.com wrote: To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? It already has, but it's dependent on a flag in the zip file itself (actually, one flag per archived file in the zip it seems). (by the way, it would be nice if your text/mail editor wrapped lines at 80 characters or something) You could complain to Apple, but it seems unlikely that they'd change it. They broke it intentionally in OSX 10.6.2 for better compatibility with MS Outlook. (for the technically inclined: It still wraps lines at 80 characters in the raw message, but it uses quoted-printable encoding to escape the line-breaks, so mail readers which decode quoted-printable but can't flow text are now S.O.L. Apple used to use the nice format=flowed standard instead.) James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Fri, Jan 21, 2011 at 3:44 PM, Atsuo Ishimoto ishim...@gembook.org wrote: I don't want Python to encourage people to use non-ascii module names. Today, seeing UnicodeEncodingError is one of popular reasons for newbies to abandon learning Python in Japan. Non-ascii module name is an another source of confusion for newbies. Experienced Japanese programmers may not use non-ascii module names to avoid encoding issues. But novice programmers or non-programmers willing to learn programming with Python will wish to use Japanese module names. Their programs will stop working if they copy them to another environment. Sooner or later, they will see storange ImportError and will start complaining Python sucks! Python doesn't support Japanese! on Twitter. Copying files with non-ascii file name over platform is not easy as it sounds. What happen if I copy such files from OSX to my web hosting server ? Results might differ depending on tools I use to copy and platforms. These all sound like good reasons to continue to *advise* against using non-ASCII module names. But aside from that, they sound exactly like a lot of the arguments we heard when Py3k started enforcing the bytes/text distinction more rigorously: you're going to break stuff!. Yes, we know. But if core software development components like Python don't try to improve their Unicode support, how is the situation ever going to get better? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On 1/20/2011 12:44 PM, Toshio Kuratomi wrote: The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. The problem that I reported and hope will be fixed is that private code written and tested on one machine, which will never be distributed, could not be imported on the *same* machine, with nothing changed on that machine except for writing a second file that does the import. If filenames get mangled when file are transported (admittedly more likely with non-ascii chars), that is a different issue. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r88121 - python/branches/py3k/Doc/whatsnew/3.2.rst
Am 20.01.2011 10:04, schrieb raymond.hettinger: +os +-- + +Different operating systems use various encodings for filenames and environment +variables. The :mod:`os` module provides two new functions, +:func:`~os.fsencode` and :func:`~os.fsdecode`, for encoding and decoding +filenames: + + filename = 'словарь' + os.fsencode(filename) +b'\xd1\x81\xd0\xbb\xd0\xbe\xd0\xb2\xd0\xb0\xd1\x80\xd1\x8c' + open(os.fsencode(filename)) Please do not include Cyrillic characters directly in the source -- it breaks the LaTeX PDF build. A non-ascii name from the latin-1 range should be fine. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On Fri, Jan 21, 2011 at 4:44 PM, Atsuo Ishimoto ishim...@gembook.org wrote:
On Fri, Jan 21, 2011 at 2:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
These all sound like good reasons to continue to *advise* against
using non-ASCII module names. But aside from that, they sound exactly
like a lot of the arguments we heard when Py3k started enforcing the
bytes/text distinction more rigorously: you're going to break
stuff!.
No, non-ASCII module names are new breakage you are going to introduce now :)
No, they're not. Non-ASCII module names *already work* in Python 3.1
on UTF-8 filesystems. The portability problem you're complaining about
exists now, and Victor is trying to at least partially alleviate it by
making these filenames work correctly on more properly configured
systems (such as Windows). It won't go away until all filesystem
manipulation tools are properly Unicode aware, but that's no reason
for us to continue to unnecessarily exacerbate the problem.
Given imp_cafe.py:
import café
And café.py:
print('Hello world from {}'.format(__name__))
I get the following result:
~$ python3.1 imp_cafe.py
Hello world from café
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
