> Fredrik Lundh wrote:
>
> > no need to wait for Guido for this: adding library support for shared-
> > memory dictionaries/lists is a no-brainer. if you have experience in
> > this field, start hacking. I'll take care of the rest ;-)
>
> and you don't need to wait for Python 3000 either, o
Marcin 'Qrczak' Kowalczyk wrote:
> It's not hard realtime. There are no strict guarantees, and a single
> large object is processed in whole.
I know. What I mean to say, I think, is can it be
designed so that there cannot be any pauses longer
than there would have been if freeing had been
perform
Fredrik Lundh wrote:
> David Hopwood wrote:
>
>>For example, "ö" can be represented either as the precomposed character
>>U+00F6,
>>or as "o" followed by a combining diaeresis (U+006F U+0308).
>
> normalization is a good thing, though:
>
> http://www.w3.org/TR/charmod-norm/
>
> (it would
Guido van Rossum schrieb:
> Is anyone familiar enough with modulefinder.py to fix its breakage in
> Py3k? It chokes in a nasty way (exceeding the recursion limit) on the
> relative import syntax. I suspect this is also a problem for 2.5, when
> people use that syntax; hence the cross-post. There's
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> What if the "self" passed to __del__ was instead a weakref.proxy,
> or a similar wrapper object which does not give you access to the
> object itself but lets you access its attributes?
weakref.proxy will find the object already dead.
I doubt this ca
Nick Coghlan wrote:
>> Unfortunately you're right... this is all too simple. The existing
>> mechanism doesn't have a problem with __del__ methods that do not
>> participate in loops. For those that DO participate in loops I
>> think it's perfectly plausible for your __del__ to receive a
>> refere
Guido van Rossum wrote:
> On 9/20/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
>> I wrote:
> msg = u'The ancient greeks used the letter "\U00010143" for the number 5.'
> msg[35:-18]
>> u'"\U00010143"'
> greek_five = msg[36:-19]
> len(greek_five)
>> 2
>>
>>
>> After posting, I re
Giovanni Bajo wrote:
> Is there a design document explaining the rationale of unicode type, the
> status quo?
Guido isn't complaining about people who don't understand the rationale
behind the design, he's complaining about people who HAVEN'T EVEN LOOKED
AT THE CURRENT DESIGN before spouting o
Michael Chermside wrote:
> Nick Coghlan writes:
>[...proposes revision of __del__ rather than removal...]
>> The only way for __del__ to receive a reference to self is if the
>> finalizer argument had a reference to it - but that would mean the
>> object itself was not
>> collectable, so __de
Guido van Rossum wrote:
> I was specifically reacting to your use of the phrasing "I'm very
> tempted to support UTF-8"; this wording suggests that it would be your
> choice to make. I could have pointed out the obvious (that equating
> the difficulty of using UTF-8 with that of using UTF-16 doesn
Second attempt, this time to the right list :)
Jim Jewett wrote:
> On 9/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> # Create a class with the same instance attributes
>> # as the original
>> class attr_holder(object):
>> pass
>>
David Hopwood <[EMAIL PROTECTED]> writes:
> People do need to realize that *all* Unicode encodings are
> variable-length, in the sense that abstract characters can be
> represented by multiple code points.
Unicode algorithms for case mapping, word splitting, collation etc.
are generally defined i
Greg Ewing <[EMAIL PROTECTED]> writes:
>> Incremental GC (e.g. in OCaml) has short pauses. It doesn't scan all
>> memory at once, but distributes the work among GC cycles.
>
> Can it be made to guarantee that no pause will
> be longer than some small amount, such as 20ms?
It's not hard realtime.
David Hopwood wrote:
> For example, "ö" can be represented either as the precomposed character
> U+00F6,
> or as "o" followed by a combining diaeresis (U+006F U+0308).
normalization is a good thing, though:
http://www.w3.org/TR/charmod-norm/
(it would probably be a good idea to turn unico
Guido van Rossum wrote:
> based on a thorough lack of understanding of the status quo no less.
that's, unfortunately, a bit too common on this list.
(as the author of Python's Unicode type and cElementTree, I especially
like arguments along the lines of "using separate buffers to hold the
actu
Adam Olsen wrote:
> Wow, you really did mean code units. In that case I'm very tempted to
> support UTF-8, with byte indexing (which is what code units are in its
> case). It's ugly, but it technically works fine, and it's the de
> facto standard on Linux. No more ugly than UTF-16 code units IM
16 matches
Mail list logo
