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
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: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
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
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/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
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
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.
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
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
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
> > 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
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
[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
[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
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
[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
[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 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 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
[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]
> [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
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
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.
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:
> > > 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 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
[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/)
[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
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.)
>
>
[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
> > 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
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
[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
[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
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
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.
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-
[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 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
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
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, 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
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
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
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
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 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
> 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
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,
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
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
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
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
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
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:
> 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
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
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
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
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:
> 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
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
_
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
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
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
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
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:
> 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
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
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
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
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 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
74 matches
Mail list logo
