Toshio Kuratomi writes:
Sure ... but with these systems, neither read-modules-as-locale or
read-modules-as-utf-8 are a good solution to work, correct?
Good solution, no, but I believe that read-modules-as-locale *should*
work to a great extent. AFAIK Python 3 reads Python programs as str
Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
Why not locale:
* Relying on locale is simply not portable. (...)
* Mixing of modules from different locales won't work. (...)
I don't understand what you are talking about.
When you import a module, the module name becomes a
Hi,
Le mardi 25 janvier 2011 à 18:07 -0800, Brett Cannon a écrit :
This broke the buildbots (R. David Murray thinks you may have
forgotten to call super() in the 'payload is None' branch). Are you
getting code reviews and fully running the test suite before
committing? We are in RC.
(...)
Am 26.01.2011 10:40, schrieb Victor Stinner:
Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
Why not locale:
* Relying on locale is simply not portable. (...)
* Mixing of modules from different locales won't work. (...)
I don't understand what you are talking about.
I
On Wed, Jan 26, 2011 at 11:12:02AM +0100, Martin v. L??wis wrote:
There are cases where there is no real transfer, in the sense in which
you are using the word. For example, with NFS, you can access the very
same file simultaneously on two systems, with no file name conversion
(unless you are
Le mercredi 26 janvier 2011 à 11:12 +0100, Martin v. Löwis a écrit :
There are cases where there is no real transfer, in the sense in which
you are using the word. For example, with NFS, you can access the very
same file simultaneously on two systems, with no file name conversion
(unless you
On Wed, Jan 26, 2011 at 11:50 AM, Dj Gilcrease digitalx...@gmail.com wrote:
On Tue, Jan 25, 2011 at 5:43 PM, M.-A. Lemburg m...@egenix.com wrote:
I also don't see how this could save a lot of memory. As an example
take a French text with say 10mio code points. This would end up
appearing in
On Wed, Jan 26, 2011 at 7:57 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
I was stupid to not run at least test_email, sorry. And no, I didn't ask
for a review, because I thought that such minor change cannot be
harmful.
During the RC period, *everything* that touches the code base
On 26 January 2011 12:30, Nick Coghlan ncogh...@gmail.com wrote:
The PEP actually does define that already:
PyUnicode_AsUTF8 populates the utf8 field of the existing string,
while PyUnicode_AsUTF8String creates a *new* string with that field
populated.
PyUnicode_AsUnicode will populate the
On Jan 26, 2011, at 4:40 AM, Victor Stinner wrote:
During
Python 3.2 development, we tried to be able to use a filesystem encoding
different than the locale encoding (PYTHONFSENCODING environment
variable): but it doesn't work simply because Python is not alone in the
OS. Except Python, all
Le mercredi 26 janvier 2011 à 08:24 -0500, James Y Knight a écrit :
On Jan 26, 2011, at 4:40 AM, Victor Stinner wrote:
During
Python 3.2 development, we tried to be able to use a filesystem encoding
different than the locale encoding (PYTHONFSENCODING environment
variable): but it doesn't
On Wed, Jan 26, 2011 at 04:34, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jan 26, 2011 at 7:57 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
I was stupid to not run at least test_email, sorry. And no, I didn't ask
for a review, because I thought that such minor change cannot be
Am 26.01.2011 10:57, schrieb Victor Stinner:
Hi,
Le mardi 25 janvier 2011 à 18:07 -0800, Brett Cannon a écrit :
This broke the buildbots (R. David Murray thinks you may have
forgotten to call super() in the 'payload is None' branch). Are you
getting code reviews and fully running the test
On Jan 26, 2011, at 11:47 AM, Victor Stinner wrote:
Not exactly. Gtk+ uses the glib library, and to encode/decode filenames,
the glib library uses:
- UTF-8 on Windows
- G_FILENAME_ENCODING environment variable if set (comma-separated list
of encodings)
- UTF-8 if G_BROKEN_FILENAMES env
I gets to a dict of class circumventing dictproxy. It's yet unclear
why it segfaults.
The crash as well as the output 1 are both caused because updating
the class dictionary directly doesn't invalidate the method cache.
When the new value for f is assigned to the dict, the old f gets
garbage
If NFSv3 doesn't reencode filenames for each client and the clients
don't reencode filenames, all clients have to use the same locale
encoding than the server. Otherwise, I don't see how it can work.
In practice, users accept that they get mojibake - their editors can
still open the files, and
On Wed, Jan 26, 2011 at 11:12:02AM +0100, Martin v. Löwis wrote:
Am 26.01.2011 10:40, schrieb Victor Stinner:
Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
Why not locale:
* Relying on locale is simply not portable. (...)
* Mixing of modules from different locales
Toshio Kuratomi:
When they update their OS to a version that has
utf-8 python module names, they will find that they have to make a choice.
They can either change their locale settings to a utf-8 encoding and have
the system installed modules work or they can leave their encoding on their
On 1/26/2011 4:47 PM, Toshio Kuratomi wrote:
There's one further case that I am worried about that has no real
transfer. Since people here seem to think that unicode module names are
the future (for instance, the comments about redefining the C locale to
include utf-8 and the comments about
On Mon, Jan 24, 2011 at 3:20 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le mardi 25 janvier 2011 à 00:07 +0100, Martin v. Löwis a écrit :
I'd like to propose PEP 393, which takes a different approach,
addressing both problems simultaneously: by getting a flexible
representation (one that
20 matches
Mail list logo
