Marcin 'Qrczak' Kowalczyk wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> writes:
>
>>> It also allows to put globals in an array instead of a dictionary,
>>> making them as fast as locals.
>> so module namespaces will no longer be populated by *executing* the
>> module contents?
>
> They would, but
Marcin 'Qrczak' Kowalczyk wrote:
> Brian Quinlan <[EMAIL PROTECTED]> writes:
>
>>> Reference counting is inefficient, doesn't by itself handle cycles,
>>> and is impractical to combine with threads which run in parallel. The
>>> general
Marcin 'Qrczak' Kowalczyk wrote:
> Reference counting is inefficient, doesn't by itself handle cycles,
> and is impractical to combine with threads which run in parallel. The
> general consensus of modern language implementations is that a tracing
> GC is the future.
How is reference counting inef
Martin v. Löwis wrote:
>> I can assure you
>> that most of the documents that I work with are not in CP436 - they are
>> a combination of ASCII, ISO8859-1, and UTF-8. I would also guess that
>> this is true of many Windows XP (US-English) users. So, for me and users
>> like me, Python is going t
Marcin 'Qrczak' Kowalczyk wrote:
> Why would it matter? If most of their programs use UTF-8, and it's
> specified by the locale, then fine. My system uses mostly ISO-8859-2,
> and it's also fine, as long as there is a way for the program to get
> that information.
The problem is that blindly using
Guido van Rossum wrote:
> And it seems just as wrong if Python doesn't do what the user expects.
> If I were a beginning Python user, I'd hate it if I had prepared a
> simple data file in vi or notepad and my Python program wouldn't read
> it right because Python's idea of encoding differs from my
It is my understanding that, in Python 3000, certain functions and
methods that currently return lists will return some sort of view type
(e.g. dict.values()) or an iterator (e.g. zip). So certain usage
patterns will no longer be supported e.g. d.keys().sort().
The attached patch, which is a d
