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-statements to pass values to iterators
> * allows generators to receiv
On May 6, 2005, at 8:11 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Well, this is a completely separate issue/problem. The internal
>> representation is UTF-16, and should be stated as such. If the
>> built-in methods actually don't work with surrogate pairs, then that
>> should be fi
On May 6, 2005, at 8:25 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Yes. Not only in my mind, but in the Python source code. If
>> Py_UNICODE is 4 bytes wide, then the encoding is UTF-32 (UCS-4),
>> otherwise the encoding is UTF-16 (*not* UCS-2).
>
> I see. Some people equate "encodi
Guido van Rossum wrote:
[SNIP]
> There's one alternative possible (still orthogonal to PEP 340):
> instead of __next__(), we could add an optional argument to the next()
> method, and forget about the next() built-in. This is more compatible
> (if less future-proof). Old iterators would raise an ex
PEP 340 contains several different ideas. This rewrite separates them into five
major areas:
- passing data into an iterator
- finalising iterators
- integrating finalisation into for loops
- the new non-looping finalising statement
- integrating all of these with generators.
The first
Nicholas Bastin wrote:
> Well, this is a completely separate issue/problem. The internal
> representation is UTF-16, and should be stated as such. If the
> built-in methods actually don't work with surrogate pairs, then that
> should be fixed.
Yes to the former, no to the latter. PEP 261 speci
Nicholas Bastin wrote:
> Yes. Not only in my mind, but in the Python source code. If
> Py_UNICODE is 4 bytes wide, then the encoding is UTF-32 (UCS-4),
> otherwise the encoding is UTF-16 (*not* UCS-2).
I see. Some people equate "encoding" with "encoding scheme";
neither UTF-32 nor UTF-16 is an
Nicholas Bastin wrote:
> What I mean is pretty clear. UCS-2 does *NOT* support surrogate pairs.
> If it did, it would be called UTF-16. If Python really supported
> UCS-2, then surrogate pairs from UTF-16 inputs would either get turned
> into two garbage characters, or the "I couldn't transc
Shane Hathaway wrote:
> Ok. Thanks for helping me understand where Python is WRT unicode. I
> can work around the issues (or maybe try to help solve them) now that I
> know the current state of affairs. If Python correctly handled UTF-16
> strings internally, we wouldn't need the UCS-4 configura
On May 6, 2005, at 7:45 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Because the encoding of that buffer appears to be different depending
>> on
>> the configure options.
>
> What makes it appear so? sizeof(Py_UNICODE) changes when you change
> the option - does that, in your mind, mea
On May 6, 2005, at 7:43 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> If this is the case, then we're clearly misleading users. If the
>> configure script says UCS-2, then as a user I would assume that
>> surrogate pairs would *not* be encoded, because I chose UCS-2, and it
>> doesn't s
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 dependency.
Regards,
Martin
_
Nicholas Bastin wrote:
> No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
> default is depends on your platform.
The truth is more complicated. If your Tcl is built for UCS-4, then
Python will also be built for UCS-4 (unless overridden by command line).
Otherwise, Python will
Nicholas Bastin wrote:
> Because the encoding of that buffer appears to be different depending on
> the configure options.
What makes it appear so? sizeof(Py_UNICODE) changes when you change
the option - does that, in your mind, mean that the encoding changes?
> If that isn't true, then someone n
Nicholas Bastin wrote:
> If this is the case, then we're clearly misleading users. If the
> configure script says UCS-2, then as a user I would assume that
> surrogate pairs would *not* be encoded, because I chose UCS-2, and it
> doesn't support that.
What do you mean by that? That the interprete
Shane Hathaway wrote:
> Then something in the Python docs ought to say why UCS-2 is not what you
> want. I still don't know; I've heard differing opinions on the subject.
> Some say you'll never need more than what UCS-2 provides. Is that
> incorrect?
That clearly depends on who "you" is.
> Mo
On May 6, 2005, at 7:05 PM, Shane Hathaway wrote:
> Nicholas Bastin wrote:
>
>> On May 6, 2005, at 5:21 PM, Shane Hathaway wrote:
>>
>>> Wait... are you saying a Py_UNICODE array contains either UTF-16 or
>>> UTF-32 characters, but never UCS-2? That's a big surprise to
>>> me. I may
>>> need t
Nicholas Bastin wrote:
> I'm not sure the Python documentation is the place to teach someone
> about unicode. The ISO 10646 pretty clearly defines UCS-2 as only
> containing characters in the BMP (plane zero). On the other hand, I
> don't know why python lets you choose UCS-2 anyhow, since it's a
Nicholas Bastin wrote:
> The important piece of information is that it is not guaranteed to be a
> particular one of those sizes. Once you can't guarantee the size, no
> one really cares what size it is.
Please trust many years of experience: This is just not true. People
do care, and they want t
Nicholas Bastin wrote:
>
> On May 6, 2005, at 5:21 PM, Shane Hathaway wrote:
>> Wait... are you saying a Py_UNICODE array contains either UTF-16 or
>> UTF-32 characters, but never UCS-2? That's a big surprise to me. I may
>> need to change my PyXPCOM patch to fit this new understanding. I tried
On May 6, 2005, at 5:21 PM, Shane Hathaway wrote:
> Nicholas Bastin wrote:
>> On May 6, 2005, at 3:42 PM, James Y Knight wrote:
>>> It means all the string operations treat strings as if they were
>>> UCS-2, but that in actuality, they are UTF-16. Same as the case in
>>> the
>>> windows APIs and
On Fri, 6 May 2005, Guido van Rossum wrote:
> There's one alternative possible (still orthogonal to PEP 340):
> instead of __next__(), we could add an optional argument to the next()
> method, and forget about the next() built-in.
I prefer your original proposal. I think this is a good time to sw
At 01:18 PM 5/6/2005 -0700, Guido van Rossum wrote:
>There's one alternative possible (still orthogonal to PEP 340):
>instead of __next__(), we could add an optional argument to the next()
>method, and forget about the next() built-in. This is more compatible
>(if less future-proof). Old iterators
Guido van Rossum wrote:
> > (to save typing, you can use an empty string or even
> > put quotes around the exception name, but that may
> > make it harder to spot the change)
>
> Yeah, but that will stop working in Python 3.0.
well, I tend to remove my debugging hacks once I've fixed
the bug. I
Nicholas Bastin wrote:
> On May 6, 2005, at 3:42 PM, James Y Knight wrote:
>>It means all the string operations treat strings as if they were
>>UCS-2, but that in actuality, they are UTF-16. Same as the case in the
>>windows APIs and Java. That is, all string operations are essentially
>>broken,
> Enhanced Iterators:
>
> ...
> > When the *initial* call to __next__() receives an argument
> > that is not None, TypeError is raised; this is likely caused
> > by some logic error.
[Jim Jewett]
> This made sense when the (Block) Iterators were Resources,
> and the first __next__() was just to t
On May 6, 2005, at 3:42 PM, James Y Knight wrote:
> On May 6, 2005, at 2:49 PM, Nicholas Bastin wrote:
>> If this is the case, then we're clearly misleading users. If the
>> configure script says UCS-2, then as a user I would assume that
>> surrogate pairs would *not* be encoded, because I chose
After reading through the code and the comments in this thread, I
propose the following in the documentation as the definition of
Py_UNICODE:
"This type represents the storage type which is used by Python
internally as the basis for holding Unicode ordinals. Extension module
developers should
On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > PEP: XXX
> > > Title: Enhanced Iterators
> >
> > Strawman question - as this is the "uncontroversial" bit, can this
> > part be acce
Enhanced Iterators:
...
> When the *initial* call to __next__() receives an argument
> that is not None, TypeError is raised; this is likely caused
> by some logic error.
This made sense when the (Block) Iterators were Resources,
and the first __next__() was just to trigger the setup.
It make
Guido van Rossum wrote:
> try_stmt: 'try' ':' suite
> (
> except_clause ':' suite)+
> ['else' ':' suite] ['finally' ':' suite]
> |
> 'finally' ':' suite
> )
>
> There is no real complexity in this grammar, it's unam
On 5/6/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > PEP: XXX
> > Title: Enhanced Iterators
>
> Strawman question - as this is the "uncontroversial" bit, can this
> part be accepted as it stands? :-)
FWIW, I'm +1 on this. Enhanced Iterators
Nicholas Bastin wrote:
> On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
>
>
>>You've got that wrong: Python let's you choose UCS-4 -
>>UCS-2 is the default.
>
>
> No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
> default is depends on your platform. If you run raw con
On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Well, busy-work or not, I took the 20 minutes to split them up, so I
> figured I might as well make them available. It was actually really
> easy to split them apart, and I think they both read better this way,
> but I'm not sure my opinion co
On May 6, 2005, at 2:49 PM, Nicholas Bastin wrote:
> If this is the case, then we're clearly misleading users. If the
> configure script says UCS-2, then as a user I would assume that
> surrogate pairs would *not* be encoded, because I chose UCS-2, and it
> doesn't support that. I would assume th
[Guido van Rossum]
> I like the solution that puts a bare "raise" at the top of the except
> clause.
Yes. Clean and simple enough. Thanks all! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
> You've got that wrong: Python let's you choose UCS-4 -
> UCS-2 is the default.
No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
default is depends on your platform. If you run raw configure, some
systems will choose UCS-
On May 6, 2005, at 3:25 AM, M.-A. Lemburg wrote:
> I don't see why you shouldn't use Py_UNICODE buffer directly.
> After all, the reason why we have that typedef is to make it
> possible to program against an abstract type - regardless of
> its size on the given platform.
Because the encoding of
On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
> You've got that wrong: Python let's you choose UCS-4 -
> UCS-2 is the default.
>
> Note that Python's Unicode codecs UTF-8 and UTF-16
> are surrogate aware and thus support non-BMP code points
> regardless of the build type: A UCS2-build of Pytho
[Guido]
> I don't think it's necessary to separate this out into a separate PEP;
> that just seems busy-work. I agree these parts are orthogonal and
> uncontroversial; a counter-PEP can suffice by stating that it's not
> countering those items nor repeating them.
[Raymond]
> If someone volunteers
[me]
> > I don't think it's necessary to separate this out into a separate PEP;
> > that just seems busy-work. I agree these parts are orthogonal and
> > uncontroversial; a counter-PEP can suffice by stating that it's not
> > countering those items nor repeating them.
[Raymond]
> If someone volunt
Phillip J. Eby wrote:
> At 01:58 PM 5/6/2005 +1000, Delaney, Timothy C (Timothy) wrote:
>
>>Personally, I'm of the opinion that we should make a significant break
>>(no pun intended ;) and have for-loops attempt to ensure that iterators
>>are exhausted.
>
>
> This is simply not backward compatib
> > I'd be willing to break these off into a separate PEP if people
think
> > it's a good idea. I've seen very few complaints about any of these
> > pieces of the proposal. If possible, I'd like to see these things
> > approved now, so that the discussion could focus more directly on
the
> > bloc
[Steven Bethard]
> So, just to make sure, if we had another PEP that contained from PEP 340[1]:
> * Specification: the __next__() Method
> * Specification: the next() Built-in Function
> * Specification: a Change to the 'for' Loop
> * Specification: the Extended 'continue' Statement
> * the yi
On 5/6/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > I don't think it "damages" any features. Are there features you still
> > think the non-looping proposal removes? (I'm not counting orthogonal
> > feautres like "continue EXPR" which could easily be added as an
> > entirely separate PEP.)
>
>
[Fredrik]
> the standard pydiom for this is to change
>
> try:
> blabla
> except IOError:
> blabla
>
> to
>
> try:
> blabla
> except "debug": # IOError:
> blabla
>
> (to save typing, you can use an empty string or even
> put quotes around the exce
[me]
> > I can't see how this would ever do something different than your version.
[Reinhold]
> Well, in the original the call to action1 was wrapped in an additional
> try-except
> block.
Ah. Francois was misquoting it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
At 01:58 PM 5/6/2005 +1000, Delaney, Timothy C (Timothy) wrote:
>Personally, I'm of the opinion that we should make a significant break
>(no pun intended ;) and have for-loops attempt to ensure that iterators
>are exhausted.
This is simply not backward compatible with existing, perfectly valid and
François Pinard wrote:
> > > f = None
> > > try:
> > > f = action1(...)
> > > ...
> > > finally:
> > > if f is not None:
> > > action2(f)
> > f = action1()
> > try:
> > ...
> > finally:
> > action2(f)
> > I can't see how this would ever do some
At 07:55 AM 5/6/2005 -0700, Guido van Rossum wrote:
>[jJ]
> > > Incidentally, would the resulting functions be a bit faster if you
> compiled
> > > the lambda instead of repeatedly eval ing it, or does the eval
> overhead still
> > > apply?
>
>[Michele]
> > Honestly, I don't care, since "eval" ha
François Pinard wrote:
> It happens once in a while that I want to comment out the except clauses
> of a try statement, when I want the traceback of the inner raising, for
> debugging purposes. Syntax forces me to also comment the `try:' line,
> and indent out the lines following the `try:' line.
Guido van Rossum wrote:
> [François Pinard]
>> It happens once in a while that I want to comment out the except clauses
>> of a try statement, when I want the traceback of the inner raising, for
>> debugging purposes. Syntax forces me to also comment the `try:' line,
>> and indent out the lines fo
[Guido van Rossum]
> [François Pinard]
>
> > It happens once in a while that I want to comment out the except
> > clauses of a try statement, when I want the traceback of the inner
> > raising, for debugging purposes. Syntax forces me to also comment
> > the `try:' line, and indent out the lines
[François Pinard]
> It happens once in a while that I want to comment out the except clauses
> of a try statement, when I want the traceback of the inner raising, for
> debugging purposes. Syntax forces me to also comment the `try:' line,
> and indent out the lines following the `try:' line. And
[Guido van Rossum]
> [Nick Coghlan]
> > > What does a try statement with neither an except clause nor a
> > > finally clause mean?
> [Greg Ewing]
>
> > I guess it would mean the same as
> >if 1:
> > ...
> I strongly disagree with this. [...]
Allow me a quick comment on this issue.
I
[Greg Ewing]
> How about user-defined keywords?
>
> Suppose you could write
>
>statement opening
>
>def opening(path, mode):
> f = open(path, mode)
> try:
>yield
> finally:
>close(f)
>
> which would then allow
>
>opening "myfile", "w" as f:
> do_
[Guido]
> ...
> I wonder how many folks call their action methods do() though.
A little Google(tm)-ing suggests it's not all that common, although it
would break Zope on NetBSD:
http://www.zope.org/Members/tino/ZopeNetBSD
I can live with that .
___
[Greg Ewing]
> How about 'do'?
>
>do opening(filename) as f:
> ...
>
>do locking(obj):
> ...
>
>do carefully(): # :-)
> ...
I've been thinking of that too. It's short, and in a nostalgic way
conveys that it's a loop, without making it too obvious. (Those too
young to
On 5/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Michele]
> > Honestly, I don't care, since "eval" happens only once at decoration time.
> > There is no "eval" overhead at calling time, so I do not expect to have
> > problems. I am waiting for volunteers to perform profiling and
> > perfor
[jJ]
> > Incidentally, would the resulting functions be a bit faster if you compiled
> > the lambda instead of repeatedly eval ing it, or does the eval overhead
> > still
> > apply?
[Michele]
> Honestly, I don't care, since "eval" happens only once at decoration time.
> There is no "eval" overhea
[Nick Coghlan]
>
> > What does a try statement with neither an except clause nor a finally
> > clause mean?
[Greg Ewing]
> I guess it would mean the same as
>
>if 1:
> ...
>
> Not particularly useful, but maybe it's not worth complexifying
> the grammar just for the sake of disallowin
On 5/6/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Thank you; this is very good.
>
> I added a link to it from http://www.python.org/moin/PythonDecoratorLibrary;
> please also consider adding a version number and publishing via PyPI.
Yes, this was in my plans. For the moment, however, this is ju
> > Yes, there has been quite a bit of interest including several ASPN
> > recipes and a wiki:
> >
> >http://www.python.org/moin/PythonDecoratorLibrary
>
> Thanks, I didn't know about that page. BTW, I notice that all the
> decorators
> in that page are improper, in the sense that they change
Guido van Rossum wrote:
>>Maybe generators are not the way to go, but could be
>>supported natively by providing a __block__ function, very similarly to
>>sequences providing an __iter__ function for for-loops?
>
> Sorry, I have no idea what you are proposing here.
I was suggesting that the featu
On 5/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Yes, there has been quite a bit of interest including several ASPN
> recipes and a wiki:
>
>http://www.python.org/moin/PythonDecoratorLibrary
Thanks, I didn't know about that page. BTW, I notice that all the decorators
in that page
On Thursday 05 May 2005 16:03, Nick Coghlan wrote:
> The discussion on the meaning of break when nesting a PEP 340 block
> statement inside a for loop has given me some real reasons to prefer PEP
> 310's single pass semantics for user defined statements
That also solves a problem with resource a
Paul Moore <[EMAIL PROTECTED]> writes:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
>> updating it with any of my ideas would be their call.
>
> I'm willing to consider an update - I don't know Michael's view.
Paul Moore wrote:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> 2. Manual protocol implementations are _significantly_ easier to write
>
> Hmm, I've not tried so I'll have to take your word for this. But I
> don't imagine writing manual implementations much - one of the key
> features
On 5/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.
>
> This could be achieved by having a separate exce
Ron Adam wrote:
A minor correction to the Block class due to re-editing.
> def __call__(self, *args):
> self.block(*args)
> self.__del__()
This should have been.
def __call__(self, *args):
try:
self.block(*args)
except Exception, self.__e
On 5/5/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/5/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > And does your proposal allow for "continue EXPR" as supported by PEP
> > 340? I can't see that it could, given that your proposal treats block
> > statements as not being loops.
>
> Read PEP
Nicholas Bastin wrote:
> On May 4, 2005, at 6:03 PM, Martin v. Löwis wrote:
>
>
>>Nicholas Bastin wrote:
>>
>>>"This type represents the storage type which is used by Python
>>>internally as the basis for holding Unicode ordinals. Extension
>>>module
>>>developers should make no assumptions abo
Fredrik Lundh wrote:
> Thomas Heller wrote:
>
>
>>AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
>>independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
>>can be used by extension writers to determine if Py_UNICODE is the same as
>>wchar_t.
>
>
> note th
Nicholas Bastin wrote:
> On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
>
>>>Nicholas Bastin wrote:
>>>
>>>
"This type represents the storage type which is used by Python
internally as the basis for holding Unicode ordinals. Extension
module
developers should make no assumptio
74 matches
Mail list logo
