On Mon, Jan 24, 2011 at 3:20 PM, Antoine Pitrou 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 can
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 ar
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 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
> 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, a
> 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
gar
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
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 th
On Wed, Jan 26, 2011 at 04:34, Nick Coghlan wrote:
> On Wed, Jan 26, 2011 at 7:57 PM, Victor Stinner
> 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, *ever
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
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, a
On 26 January 2011 12:30, Nick Coghlan 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 wstr field (
On Wed, Jan 26, 2011 at 7:57 PM, Victor Stinner
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 should
be reviewed by a sec
On Wed, Jan 26, 2011 at 11:50 AM, Dj Gilcrease wrote:
> On Tue, Jan 25, 2011 at 5:43 PM, M.-A. Lemburg 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 memory as 3 copies on Windows: o
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
> (unles
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 y
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
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.
> (...
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
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
(
20 matches
Mail list logo
