Josiah Carlson wrote:
> For is already tuned to be as fast as possible, which makes sense; it is
> used 4,523 times in Python 2.4.0's standard library, and easily hundreds
> of thousands of times in user code. Changing the standard for loop is
> not to be done lightly.
Agreed!
>>And why this is
Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I agree, re-using or extending 'for' doesn't seem like a good idea to me.
>
>
> I agree that re-using a straight 'for' loop is out, due to performance and
> compatibility issues with applying finalisation semantics to all such
> iterative
> loops (the
On Sun, 08 May 2005 14:16:40 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Ron Adam wrote:
>> I agree, re-using or extending 'for' doesn't seem like a good idea to me.
>
>I agree that re-using a straight 'for' loop is out, due to performance and
>compatibility issues with applying finalisation se
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > You should know why that can't work. If I pass a list, is a list an
> > iterator? No, but it should neither be created nor destroyed before or
> > after.
> >
> > The discussion has been had in regards to why re-using 'for' i
Ron Adam wrote:
> I agree, re-using or extending 'for' doesn't seem like a good idea to me.
I agree that re-using a straight 'for' loop is out, due to performance and
compatibility issues with applying finalisation semantics to all such iterative
loops (there's a reason the PEP redraft doesn't s
On May 7, 2005, at 1:45 AM, Michele Simionato wrote:
> On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>> FWIW, I'm +1 on this. Enhanced Iterators
>> * updates the iterator protocol to use .__next__() instead
>> of .next()
>> * introduces a new builtin next()
>> * allows continue-stat
Josiah Carlson wrote:
> You should know why that can't work. If I pass a list, is a list an
> iterator? No, but it should neither be created nor destroyed before or
> after.
>
> The discussion has been had in regards to why re-using 'for' is a
> non-starter; re-read the 200+ messages in t
Nicholas Bastin wrote:
> On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
>
>
>>However, I don't understand all the excitement
>>about Py_UNICODE: if you don't like the way this Python
>>typedef works, you are free to interface to Python using
>>any of the supported encodings using PyUnicode_Enco
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
> Please upload your doc-patch to SF.
All of my proposals for what to change the documention to have been
shot down by Martin. If someone has better verbiage that they'd like
to see, I'd be perfectly happy to patch the doc.
My last suggestion
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
> However, I don't understand all the excitement
> about Py_UNICODE: if you don't like the way this Python
> typedef works, you are free to interface to Python using
> any of the supported encodings using PyUnicode_Encode()
> and PyUnicode_Decode()
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
>
> > [...]
> > The whole PEP draft can be found here:
> > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> > [...]
> > Used as follows::
> >
> > for del auto_retry(3, IOError):
> > f = urllib.urlo
Nicholas Bastin wrote:
> On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
>>With --enable-unicode=ucs2, Python's Py_UNICODE does *not* start
>>supporting the full Unicode ccs the same way it supports UCS-2.
>>Individual surrogate values remain accessible, and supporting
>>non-BMP characters is le
Nick Coghlan wrote:
> [...]
> The whole PEP draft can be found here:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> [...]
> Used as follows::
>
> for del auto_retry(3, IOError):
> f = urllib.urlopen("http://python.org/";)
> print f.read()
I don't
On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> --enable-unicode=ucs2
>>
>> be replaced with:
>>
>> --enable-unicode=utf16
>>
>> and the docs be updated to reflect more accurately the variance of the
>> internal storage type.
>
> -1. This breaks existing documentati
On May 7, 2005, at 9:24 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Yes, but the important question here is why would we want that? Why
>> doesn't Python just have *one* internal representation of a Unicode
>> character? Having more than one possible definition just creates
>> proble
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Hmm, looking at the configure.in script, it seems you're right.
>>I wonder why this weird dependency on TCL was added.
>
>
> If Python is configured for UCS-2, and Tcl for UCS-4, then
> Tkinter would not work out of the box. Hence the weird depen
Shane Hathaway wrote:
> Martin v. Löwis wrote:
>
>>Shane Hathaway wrote:
>>
>>
>>>I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
>>>widely used and takes less space, while UCS4 is easier to treat as an
>>>array of characters. Maybe we can have both: unicode objects start w
Shane Hathaway wrote:
> Py_UNICODE would always be 32 bits wide.
This would break PythonWin, which relies on Py_UNICODE being
the same as WCHAR_T. PythonWin is not broken, it just hasn't
been ported to UCS-4, yet (and porting this is difficult and
will cause a performance loss).
Regards,
Martin
Martin v. Löwis wrote:
> Shane Hathaway wrote:
>
>>I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
>>widely used and takes less space, while UCS4 is easier to treat as an
>>array of characters. Maybe we can have both: unicode objects start with
>>an internal representation
I suggest using a variation on the consumer interface, as described by
Fredrik Lundh at http://effbot.org/zone/consumer.htm :
.next() -- stays .next()
.__next__(arg) -- becomes .feed(arg)
.__exit__(StopIteration, ...) -- becomes .close()
.__exit__(..,..,..) -- becomes .feed(exc_info=(..,..,..))
> Yes, but the first few steps are the same for nearly everyone, and
> people need more help taking the first few steps.
Contributions to the documentation are certainly welcome.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Shane Hathaway wrote:
> I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
> widely used and takes less space, while UCS4 is easier to treat as an
> array of characters. Maybe we can have both: unicode objects start with
> an internal representation in UTF-16, but get promoted
Nicholas Bastin wrote:
> --enable-unicode=ucs2
>
> be replaced with:
>
> --enable-unicode=utf16
>
> and the docs be updated to reflect more accurately the variance of the
> internal storage type.
-1. This breaks existing documentation and usage, and provides only
minimum value.
With --enable-u
Nicholas Bastin wrote:
> Yes, but the important question here is why would we want that? Why
> doesn't Python just have *one* internal representation of a Unicode
> character? Having more than one possible definition just creates
> problems, and provides no value.
It does provide value, there ar
Martin v. Löwis wrote:
> Shane Hathaway wrote:
>>More generally, how should a non-unicode-expert writing Python extension
>>code find out the minimum they need to know about unicode to use the
>>Python unicode API? The API reference [1] ought to at least have a list
>>of background links. I had t
Martin v. Löwis wrote:
> Define correctly. Python, in ucs2 mode, will allow to address individual
> surrogate codes, e.g. in indexing. So you get
>
>
u"\U00012345"[0]
When Python encodes characters internally in UCS-2, I would expect
u"\U00012345" to produce a UnicodeError("character can not
26 matches
Mail list logo
