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 assumptions about the size of this
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 that usable is
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 about the size of this
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 340 again --
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,
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 exception
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
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 are
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 feature
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 just
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
performance analysis
[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 get that
[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 wink.
[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_something_with(f)
[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.
It happens once
[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 of
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 following
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 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 exception name, but
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.)
I *am*
[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
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
[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 volunteers to
[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 to
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
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 that
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 counts
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
* updates
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 unambiguous,
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 makes
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 trigger the
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, because
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
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
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 Java. That
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
hard
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 to
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 interpreter
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
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 support
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, mean that
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
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 transcode
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
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 encoding with
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 fixed.
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 receive
54 matches
Mail list logo
