Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Guido van Rossum <[EMAIL PROTECTED]> writes: > Apologies if this has been discovered and rejected already; I've had > to skip most of the discussions but this though won't leave my head... > > So PEP 310 proposes this: > > with VAR = EXPR: > BLOCK > > translated to > > VAR = EXPR\ > if hasattr(VAR, "__enter__"): > VAR.__enter__() > try: > BLOCK > finally: > VAR.__exit__() > > This equates VAR with the value of EXPR. It has a problem: what if > inside BLOCK an assignment to VAR is made -- does this affect the > finally clause or not? I think that the finally clause should use an > internal variable that isn't affected by assignments to VAR. Uh, if that's not clear from the PEP (and I haven't looked) it's an oversight. VAR is optional in PEP 310, after all. Cheers, mwh -- There's an aura of unholy black magic about CLISP. It works, but I have no idea how it does it. I suspect there's a goat involved somewhere. -- Johann Hibschman, comp.lang.scheme ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>I think we should remove the defaulting to whatever >>TCL uses and instead warn the user about a possible >>problem in case TCL is found and uses a Unicode >>width which is incompatible with Python's choice. > > -1. Martin, please reconsider... the choice is between: a) We have a cross-platform default Unicode width setting of UCS2. b) The default Unicode width is undefined and the only thing we can tell the user is: Run the configure script and then try the interpreter to check whether you've got a UCS2 or UCS4 build. Option b) is what the current build system implements and causes problems since the binary interface of the interpreter changes depending on the width of Py_UNICODE making UCS2 and UCS4 builds incompatible. I want to change the --enable-unicode switch back to always use UCS2 as default and add a new option value "tcl" which then triggers the behavior you've added to support _tkinter, ie. --enable-unicode=tcl bases the decision to use UCS2 or UCS4 on the installed TCL interpreter (if there is one). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Guido van Rossum wrote: > Apologies if this has been discovered and rejected already; I've had > to skip most of the discussions but this though won't leave my head... > > So PEP 310 proposes this: > > with VAR = EXPR: > BLOCK > > translated to > > VAR = EXPR\ > if hasattr(VAR, "__enter__"): > VAR.__enter__() > try: > BLOCK > finally: > VAR.__exit__() > > I used to dislike this, but the opposition and the proliferation of > alternative proposals have made me realize that I'd rather have this > (plus "continue EXPR" which will be moved to a separate PEP once I > have some extra time) than most of the other proposals. The User Defined Statement section of my PEP redraft suggests something very similar to this: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html It suggests more complex semantics, so that the statement template has the chance to intercept exceptions raised in the block, and can tell the difference between normal termination and exiting the block via break, continue or return statements. This is needed to support some of the use cases (like the transaction() template). All of the PEP 340 examples are written up at the end of the PEP redraft, along with some of the motivating cases for a non-looping construct. (Ignore the part in the redraft about for loops for the moment - Greg Ewing has convinced me that what I currently have gets the default behaviour backwards. And, in relation to that, the next version will require a decorator to enable __enter__() and __exit__() methods on a given generator). Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>On sre character classes: I don't think that these provide >>a good approach to XML lexical classes - custom functions >>or methods or maybe even a codec mapping the characters >>to their XML lexical class are much more efficient in >>practice. > > > That isn't my experience: functions that scan XML strings > are much slower than regular expressions. I can't imagine > how a custom codec could work, so I cannot comment on that. If all you're interested in is the lexical class of the code points in a string, you could use such a codec to map each code point to a code point representing the lexical class. Then run re as usual on the mapped Unicode string. Since the indices of the matches found in the resulting string will be the same as in the original string, it's easy to extract the corresponding data from the original string. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Greg Ewing wrote: > Unless I'm seriously mistaken, all the Python-equivalent > loop code that's been presented is only for expositional > purposes -- in real life, the logic would be embedded in > the ceval code that implements the for-loop control > bytecodes, so there would be little or no difference in > the bytecode from what is generated today. Hmm, that would obviously be more sensible. OK, I'll drop that from my list of concerns :) > It would be better to do it the other way around, and > have a different form of looping statement for when > you *don't* want finalization. The programmer knows he's > doing a partial iteration when he writes the code, > and is therefore in a position to choose the right > statement. > > For backwards compatibility, the existing for-loop > would work for partial iteration of old iterators, > but this usage would be deprecated. I actually agree, but the pain comes with generators. Doing it this way means that generators can't have an __exit__() method by default - it will need to be enabled with a decorator of some description (a future statement won't work, since it needs to be selectable on a generator by generator basis). It has to be done this way, so that old generators (without the decorator) are not inadvertently finalised by unmodified for loops (otherwise old code that isn't expecting finalisation could break severely). Hmm, with that approach, a code inspection tool like pychecker could be used to pick up the slack, and flag generators which have a yield inside a try/finally or a user defined statement without applying the "needs finalisation" decorator (assuming the compiler can't detect this for itself). OK, given the above, finalising by default definitely seems like the right thing to do - there's then the question of how to spell "don't finalise this iterator". It turns out no keyword is needed for that. Instead, an iterator that iterates over a supplied iterable suffices: class partial_iter(object): def __init__(self, iterable): self.itr = iter(iterable) def __iter__(self): yield self def next(self): return self.itr.next() Then, partial iteration over something that defines __exit__ is possible via: for item in partial_iter(itr): break print list(itr) # itr not finalised, even if it defines __exit__() That reads reasonably well, and it should be possible to reduce the overhead on for loops to a single check of a method slot in the various opcodes that can exit a for loop. So, this idea (or something like it) will go into my next draft. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator module
On 5/9/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Choices: > - submit a patch adding a __copy__ method to functions, > - submit a patch for the copy module, or > - submit a feature request, assign to me, and wait. Well, actually I am even more ambitious than that: not only I would like to be able to copy functions, but I also would like to be able to subclass FunctionType with an user-defined __copy__ method. Don't worry, I will submit the feature request ;) Michele Simionato P.S. I have added yet another example to the documentation of the decorator module, now arrived at version 0.3: http://www.phyast.pitt.edu/~micheles/python/decorator.zip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator module
On 5/10/05, Michele Simionato <[EMAIL PROTECTED]> wrote: > > Well, actually I am even more ambitious than that: not only I would like > to be able to copy functions, but I also would like to be able to subclass > FunctionType with an user-defined __copy__ method. BTW, it seems possible to copy closures, but how about *pickling* them? Is that technically feasible with a reasonable affort or is it a mess? Michele Simionato ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
On May 9, 2005, at 21:58, Guido van Rossum wrote: > Apologies if this has been discovered and rejected already; I've had > to skip most of the discussions but this though won't leave my head... Skimming rather than skipping all of the discussion burned most of my py-dev time, and it was just skimming, but I don't remember such rejections. > But what if we changed the translation slightly so that VAR gets > assigned to value of the __enter__() call: > > abc = EXPR > VAR = abc.__enter__() # I don't see why it should be > optional > try: > BLOCK > finally: > abc.__exit__() > > Now it would make more sense to change the syntax to > > with EXPR as VAR: > BLOCK > > and we have Phillip Eby's proposal. The advantage of this is that you I like this. The only aspect of other proposals that I would sorely miss here, would be the inability for abc.__exit__ to deal with exceptions raised in BLOCK (or, even better, a separate specialmethod on abc called in lieu of __exit__ upon exceptions). Or am I missing something, and would this give a way within abc.__exit__ to examine and possibly ``unraise'' such an exception...? > can write a relatively straightforward decorator, call it > @with_template, that endows a generator with the __enter__ and > __exit__ methods, so you can write all the examples (except > auto_retry(), which was there mostly to make a point) from PEP 340 > like this: > > @with_template > def opening(filename, mode="r"): > f = open(filename, mode) > yield f > f.close() > > and so on. (Note the absence of a try/finally block in the generator > -- the try/finally is guaranteed by the with-statement but not by the > generator framework.) I must be thick this morning, because this relatively straightforward decorator isn't immediately obvious to me -- care to show me how with_template gets coded? Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[Nick] > The User Defined Statement section of my PEP redraft suggests something very > similar to this: > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html > > It suggests more complex semantics, so that the statement template has the > chance to intercept exceptions raised in the block, and can tell the > difference > between normal termination and exiting the block via break, continue or return > statements. This is needed to support some of the use cases (like the > transaction() template). All of the PEP 340 examples are written up at the end > of the PEP redraft, along with some of the motivating cases for a non-looping > construct. Is that use case strong enough to require the added complexity? For a transactional wrapper, I can see that __exit__ needs to know about exceptions (though I'm unsure how much detail it needs), but what's the point of being able to tell an exception from a non-local goto (which break, continue and return really are)? I could see the following, minimal translation: oke = False abc = EXPR var = abc.__enter__() try: BLOCK oke = True finally: abc.__exit__(oke) What's your use case for giving __enter__ an opportunity to skip the block altogether? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
At 07:57 AM 5/10/2005 -0700, Alex Martelli wrote: >On May 9, 2005, at 21:58, Guido van Rossum wrote: > > But what if we changed the translation slightly so that VAR gets > > assigned to value of the __enter__() call: > > > > abc = EXPR > > VAR = abc.__enter__() # I don't see why it should be > > optional > > try: > > BLOCK > > finally: > > abc.__exit__() > > > > Now it would make more sense to change the syntax to > > > > with EXPR as VAR: > > BLOCK > > > > and we have Phillip Eby's proposal. The advantage of this is that you > >I like this. The only aspect of other proposals that I would sorely >miss here, would be the inability for abc.__exit__ to deal with >exceptions raised in BLOCK (or, even better, a separate specialmethod >on abc called in lieu of __exit__ upon exceptions). Or am I missing >something, and would this give a way within abc.__exit__ to examine >and possibly ``unraise'' such an exception...? Yeah, I'd ideally like to see __try__, __except__, __else__, and __finally__ methods, matching the respective semantics of those clauses in a try/except/finally block. > > can write a relatively straightforward decorator, call it > > @with_template, that endows a generator with the __enter__ and > > __exit__ methods, so you can write all the examples (except > > auto_retry(), which was there mostly to make a point) from PEP 340 > > like this: > > > > @with_template > > def opening(filename, mode="r"): > > f = open(filename, mode) > > yield f > > f.close() > > > > and so on. (Note the absence of a try/finally block in the generator > > -- the try/finally is guaranteed by the with-statement but not by the > > generator framework.) > >I must be thick this morning, because this relatively straightforward >decorator isn't immediately obvious to me -- care to show me how >with_template gets coded? Something like this, I guess: def with_template(f): class controller(object): def __init__(self,*args,**kw): self.iter = f(*args,**kw) def __enter__(self): return self.iter.next() def __exit__(self): self.iter.next() return controller But I'd rather see it with __try__/__except__ and passing exceptions into the generator so that the generator can use try/except/finally blocks to act on the control flow. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[Alex]
> I like this. The only aspect of other proposals that I would sorely
> miss here, would be the inability for abc.__exit__ to deal with
> exceptions raised in BLOCK (or, even better, a separate specialmethod
> on abc called in lieu of __exit__ upon exceptions). Or am I missing
> something, and would this give a way within abc.__exit__ to examine
> and possibly ``unraise'' such an exception...?
See my followup to Nick. I'm not worried about unraising exceptions.
The only way to mess with the exception from code in a finally-suite
is to raise another exception, and we can't really prevent that.
However (I forgot this in the response to Nick) unless/until we
augment generators in some way the generator can't easily see the
exception flag.
[me]
> > can write a relatively straightforward decorator, call it
> > @with_template, that endows a generator with the __enter__ and
> > __exit__ methods, so you can write all the examples (except
> > auto_retry(), which was there mostly to make a point) from PEP 340
> > like this:
> >
> > @with_template
> > def opening(filename, mode="r"):
> > f = open(filename, mode)
> > yield f
> > f.close()
> >
> > and so on. (Note the absence of a try/finally block in the generator
> > -- the try/finally is guaranteed by the with-statement but not by the
> > generator framework.)
[Alex]
> I must be thick this morning, because this relatively straightforward
> decorator isn't immediately obvious to me -- care to show me how
> with_template gets coded?
Here's a sketch:
class Wrapper(object):
def __init__(self, gen):
self.gen = gen
self.state = "initial"
def __enter__(self):
assert self.state == "initial"
self.state = "entered"
try:
return self.gen.next()
except StopIteration:
self.state = "error"
raise RuntimeError("template generator didn't yield")
def __exit__(self):
assert self.state == "entered"
self.state = "exited"
try:
self.gen.next()
except StopIteration:
return
else:
self.state = "error"
raise RuntimeError("template generator didn't stop")
def with_template(func):
def helper(*args, **kwds):
return Wrapper(func(*args, **kwds))
return helper
@with_template
def opening(filename, mode="r"):
f = open(filename) # Note that IOError here is untouched by Wrapper
yield f
f.close() # Ditto for errors here (however unlikely)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Guido van Rossum wrote: > I used to dislike this, but the opposition and the proliferation of > alternative proposals have made me realize that I'd rather have this > (plus "continue EXPR" which will be moved to a separate PEP once I > have some extra time) than most of the other proposals. Draft 1.3 of my PEP 310/PEP 340 merger is now up for public consumption: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html This is a major rewrite since version 1.2. Significant changes are: - reorder and reword things to emphasise the user defined statements, and their ability to factor out arbitrary try/except/else/finally boilerplate. - use 'do' as the keyword instead of 'stmt' (I have to say, I *really* like the way 'do' looks and reads in all of the examples) - clean up the semantics of user defined statements so as to make manual statement templates as easy to write as those in PEP 310 - give iterator finalisation its own slot, __finish__() (distinct from the __exit__() of statement templates) - define sensible automatic finalisation semantics for iterative loops - fill out the Rejected Options section meaningfully, with justifications for rejecting certain options - makes the PEP more self-contained, with significantly fewer references to PEP 340. These changes try to take into account the feedback I got on the previous drafts, as well as fixing a few problems I noticed myself. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[Phillip J. Eby]
> Yeah, I'd ideally like to see __try__, __except__, __else__, and
> __finally__ methods, matching the respective semantics of those clauses in
> a try/except/finally block.
What's your use case for adding this complexity? I'm going for simple
here unless there's a really strong use case. Anyway, a wrapped
generator wrapper can't do with all those distinctions unless we
augment the generator somehow ("continue EXPR" would suffice).
(Your decorator is equivalent to mine, but I don't like creating a new
class each time.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Guido van Rossum wrote: > [Nick] > Is that use case strong enough to require the added complexity? For a > transactional wrapper, I can see that __exit__ needs to know about > exceptions (though I'm unsure how much detail it needs), but what's > the point of being able to tell an exception from a non-local goto > (which break, continue and return really are)? The only real reason the statement template can tell the difference is because those non-local goto's all result in TerminateBlock being passed in as the exception (that's why the __exit__ method can't really tell the difference between those statements and the user code raising TerminateBlock, and also why TerminateBlock can't be suppressed by the statement template). As far as use cases go, any case where we want the statement template to be able to manipulate the exception handling requires that this information be passed in to the __exit__() method. The current examples given in the PEP are transaction() and auto_retry(), but others have been suggested over the course of the discussion. One suggestion was for automatically logging exceptions, which requires access to the full state of the current exception. I go into the motivation behind this a bit more in the updated draft I just posted (version 1.3). The basic idea is to allow factoring out of arbitrary try/except/else/finally code into a statement template, and use a 'do' statement to provide the contents of the 'try' clause. If the exception information isn't passed in, then we can really only factor out try/finally statements, which is far less interesting. > What's your use case for giving __enter__ an opportunity to skip the > block altogether? I realised that I don't have one - so the idea doesn't appear in the updated draft. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Nick Coghlan wrote: > Draft 1.3 of my PEP 310/PEP 340 merger is now up for public consumption: > http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html This draft was meant to drop the idea of __enter__() raising TerminateBlock preventing execution of the statement body. I dropped it out of the code describing the semantics, but the idea is still mentioned in the text. I'll probably do another draft to fix that, and various ReST problems tomorrow night. I'll also add in a justification for why I chose the single __exit__ method over separate __else__, __except__ and __finally__ methods. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
At 08:51 AM 5/10/2005 -0700, Guido van Rossum wrote:
>[Phillip J. Eby]
> > Yeah, I'd ideally like to see __try__, __except__, __else__, and
> > __finally__ methods, matching the respective semantics of those clauses in
> > a try/except/finally block.
>
>What's your use case for adding this complexity?
It makes it much easier to mentally translate a given
try/except/else/finally usage to a "resource" or "block controller" or
whatever it is we're calling these things now. You should almost be able
to just stick 'def __' and '__(self):' and then munge the whole thing into
a class.
Of course, it's not *really* that simple, because __try__ doesn't exactly
correspond to 'try:', and it has to return something, but it sure is
simpler than the mental gymnastics I'd go through to convert
except/else/finally into "if" statements inside an __exit__.
Granted, if we end up with __enter__ and __exit__, I'll just write a
resource mixin class whose __exit__ calls a stubbed-out __except__,
__else__, and __finally__. Then I won't have to figure out how to write
__exit__ methods all the time. Which is great for me, but I was thinking
that this interface would reduce complexity for people trying to learn how
to write these things.
I wasn't advocating this before because PEP 340's use of generators allowed
you to directly use try/except/else/finally. But, the new approach seems
targeted at a wider set of use cases that don't include generators. IOW,
it's likely you'll be adding resource-finalization methods to actual
resource classes, and grafting generators into them to implement
__enter__/__exit__ seems more complex at first glance than just letting
people add the methods directly; e.g.:
def __enter__(self):
self.handler = self._resource_control()
return self.handler.__enter__()
def __exit__(self):
self.handler.__exit__()
@with_template
def _resource_control(self):
f = self.open("blah")
try:
yield f
finally:
f.close()
versus this rather more "obvious way" to do it:
def __try__(self):
self.f = self.open("blah")
return self.f
def __finally__(self):
self.f.close()
But I suppose you could encapsulate either pattern as a mixin class, so I
suppose this could be treated as a matter for examples in documentation
rather than as an implementation aspect. It's just that if __exit__ has to
probe exception state or other wizardry, it's going to be harder for
non-wizards to use, and that's what I was reacting to here. Anyway, I see
now that documentation and simple mixins could address it, so if you think
it's best handled that way, so be it.
> I'm going for simple
>here unless there's a really strong use case. Anyway, a wrapped
>generator wrapper can't do with all those distinctions unless we
>augment the generator somehow ("continue EXPR" would suffice).
You'd use only __try__, __except__, and __else__ to wrap a generator. For
some other use cases you'd only use __try__ and __finally__, or __try__ and
__except__, or __try__ and __else__. I don't know of any use cases where
you'd want to use all four simultaneously on the same controller.
>(Your decorator is equivalent to mine, but I don't like creating a new
>class each time.)
Mine was just a sketch to show the idea anyway; I'd be surprised if it
doesn't have at least one bug.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)
M.-A. Lemburg wrote: > Martin, please reconsider... the choice is between: The point is that this all was discussed, and decided the other way 'round. There is no point in going back and forth between the two choices: http://mail.python.org/pipermail/python-dev/2003-June/036461.html If we remove the code, people will *again* report that _tkinter stops building on Redhat (see #719880). I see no value in breaking what works now. > a) We have a cross-platform default Unicode width >setting of UCS2. It is hardly the default anymore cross-platform. Many installations on Linux are built as UCS-4 now - no matter what configure does. > b) The default Unicode width is undefined and the only >thing we can tell the user is: > >Run the configure script and then try the interpreter >to check whether you've got a UCS2 or UCS4 build. It's not at all undefined. There is a precise, deterministic, repeatable algorithm that determines the default, and if people want to know, we can tell them. > I want to change the --enable-unicode switch back to > always use UCS2 as default and add a new option value > "tcl" which then triggers the behavior you've added to > support _tkinter, ie. > > --enable-unicode=tcl > > bases the decision to use UCS2 or UCS4 on the installed > TCL interpreter (if there is one). Please don't - unless you also go back and re-open the bug reports, change the documentation, tell the Linux packagers that settings have changed, and so on. Why deliberately break what currently works? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote: >> Wow, what an inane way of looking at it. I don't know what world you >> live in, but in my world, users read the configure options and suppose >> that they mean something. In fact, they *have* to go off on their own >> to assume something, because even the documentation you refer to above >> doesn't say what happens if they choose UCS-2 or UCS-4. A logical >> assumption would be that python would use those CEFs internally, and >> that would be incorrect. > > Certainly. That's why the documentation should be improved. Changing > the option breaks existing packaging systems, and should not be done > lightly. I'm perfectly happy to continue supporting --enable-unicode=ucs2, but not displaying it as an option. Is that acceptable to you? -- Nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
M.-A. Lemburg wrote: > If all you're interested in is the lexical class of the code points > in a string, you could use such a codec to map each code point > to a code point representing the lexical class. How can I efficiently implement such a codec? The whole point is doing that in pure Python (because if I had to write an extension module, I could just as well do the entire lexical analysis in C, without any regular expressions). Any kind of associative/indexed table for this task consumes a lot of memory, and takes quite some time to initialize. Regards, Martint ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
Nicholas Bastin wrote: > I'm perfectly happy to continue supporting --enable-unicode=ucs2, but > not displaying it as an option. Is that acceptable to you? It is. Somewhere, the code should say that this is for backwards compatibility, of course (so people won't remove it too easily; if there is a plan for obsoleting this setting, it should be done in a phased manner). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
> No, as except clauses can only occur before the finally clause, and execution > should not go backwards. This restriction feels a bit arbitrary. I can guarantee someone is going to flatten this: try: try: A finally: B except IOError: C A more flexible approach would be to allow finally at the beginning or ending of the try statement. A more flexible approach would be to allow both, or even finally clauses mixed in. To me, that's the ugly portion of this proposal, it's quite arbitrary. And the alternatives I posted have their own brands of ugly. Concisely, this is an arbitrary shortcut for an idiom that already exists. It seems to me that this shortcut would be redundant if PEP 340 or something with similar functionality was accepted. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
On May 10, 2005, at 2:48 PM, Nicholas Bastin wrote: > On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote: > > >>> Wow, what an inane way of looking at it. I don't know what world >>> you >>> live in, but in my world, users read the configure options and >>> suppose >>> that they mean something. In fact, they *have* to go off on >>> their own >>> to assume something, because even the documentation you refer to >>> above >>> doesn't say what happens if they choose UCS-2 or UCS-4. A logical >>> assumption would be that python would use those CEFs internally, and >>> that would be incorrect. >>> >> >> Certainly. That's why the documentation should be improved. Changing >> the option breaks existing packaging systems, and should not be done >> lightly. >> > > I'm perfectly happy to continue supporting --enable-unicode=ucs2, > but not displaying it as an option. Is that acceptable to you? > If you're going to call python's implementation UTF-16, I'd consider all these very serious deficiencies: - unicodedata doesn't work for 2-char strings containing a surrogate pairs, nor integers. Therefore it is impossible to get any data on chars > 0x. - there are no methods for determining if something is a surrogate pair and turning it into a integer codepoint. - Given that unicodedata doesn't work, I doubt also that .toupper/etc work right on surrogate pairs, although I haven't tested. - As has been noted before, the regexp engine doesn't properly treat surrogate pairs as a single unit. - Is there a method that is like unichr but that will work for codepoints > 0x? I'm sure there's more as well. I think it's a mistake to consider python to be implementing UTF-16 just because it properly encodes/ decodes surrogate pairs in the UTF-8 codec. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python continually calling sigprocmask() on FreeBSD 5
Hello, While investigating why the script used in http://docs.freebsd.org/ cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much system time on FreeBSD 5, I noticed that python is continually calling sigprocmask(), as can be seen from the following ktrace(1) dump: 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c) 673 python 0.05 RET sigprocmask 0 673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c) 673 python 0.05 RET sigprocmask 0 etc.. This is using Python 2.4.1. Any clue about why this is happening? (Please include me to the recipients for any reply, as I'm not subscribed) Bye, -- Suleiman Souhlal | [EMAIL PROTECTED] The FreeBSD Project | [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
[Timothy Fitz] > A more flexible approach would be to allow finally at the beginning or > ending of the try statement. A more flexible approach would be to > allow both, or even finally clauses mixed in. -1000. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 332 open (+10) / 2834 closed ( +2) / 3166 total (+12) Bugs: 927 open ( +7) / 4959 closed ( +7) / 5886 total (+14) RFE : 186 open ( +0) / 157 closed ( +1) / 343 total ( +1) New / Reopened Patches __ Feature enhancement for C socket module (2005-05-03) http://python.org/sf/1194378 opened by Heiko Wundram pydoc requires o.__nonzero__() = True (2005-05-03) http://python.org/sf/1194449 opened by Jay T Miller [AST] throw SyntaxError in "from x import y," (2005-05-03) http://python.org/sf/1194895 opened by logistix simple callback system for Py_FatalError (2005-05-05) http://python.org/sf/1195571 opened by m utku in IDLE, assume new text files are python source by default (2005-05-06) http://python.org/sf/1196895 opened by Jeff Shute smarter behaviour for home key in IDLE (2005-05-06) http://python.org/sf/1196903 opened by Jeff Shute change recall in IDLE shell to not overwrite current command (2005-05-06) http://python.org/sf/1196917 opened by Jeff Shute allow using normal indent width in shell in IDLE (2005-05-06) http://python.org/sf/1196946 opened by Jeff Shute _ssl.mak Makefile patch (Win32) (2005-05-07) http://python.org/sf/1197150 opened by Joachim Kessel Add proxies arg to urllib.urlretrieve (2005-05-07) http://python.org/sf/1197207 opened by John Dubery test_locale fix on modern linux (2005-05-07) http://python.org/sf/1197218 opened by Anthony Baxter Cygwin case-sensitive import patch (2005-05-07) http://python.org/sf/1197318 opened by Jason Tishler Patches Closed __ Minimal cleanup of run.py (2005-04-26) http://python.org/sf/1190163 closed by kbk Decimal interaction with __rop__ (2005-03-19) http://python.org/sf/1166602 closed by facundobatista New / Reopened Bugs ___ parsedate and Y2K (2005-05-02) http://python.org/sf/1194222 opened by Mark Nottingham Minor bug in urllib docs (2005-05-03) http://python.org/sf/1194249 opened by Georg Brandl Reading from a killed shell script with popen* under linux (2005-05-03) http://python.org/sf/1194328 opened by Vinz ImportError: No module named os (2005-05-03) CLOSED http://python.org/sf/1194497 opened by Will L G [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings (2005-05-04) http://python.org/sf/1195576 opened by logistix SystemError: error return without exception set (2005-05-05) http://python.org/sf/1195984 opened by Niraj Bajpai Error: ... ossaudiodev.c, line 48: Missing type specifier (2005-05-05) http://python.org/sf/1196154 opened by Will L G WeakValueDictionary.__init__ is backwards (2005-05-05) http://python.org/sf/1196315 opened by Pavel Pergamenshchik string.rstrip strips more than supposed to in some cases (2005-05-06) CLOSED http://python.org/sf/1196824 opened by Francois Payette trivial bug in error message text (2005-05-06) http://python.org/sf/1196980 opened by Jeff Shute % gives wrong results (2005-05-08) CLOSED http://python.org/sf/1197806 opened by Jonathan Installation path sent to configure (2005-05-09) http://python.org/sf/1197883 opened by Björn Lindqvist time module ignores timezone changes (2005-05-09) CLOSED http://python.org/sf/1198275 opened by David Lambert string.Template not flexible enough to subclass (regexes) (2005-05-09) http://python.org/sf/1198569 opened by Ian Bicking subprocess _active.remove(self) self not in list _active (2005-05-10) http://python.org/sf/1199282 opened by cheops Bugs Closed ___ SimpleHTTPServer sends wrong c-length and locks up client (2005-04-26) http://python.org/sf/1190580 closed by alexanderweb ImportError: No module named os (2005-05-03) http://python.org/sf/1194497 closed by rhettinger Error in section 4.2 of Python Tutorial (2005-05-02) http://python.org/sf/1194209 closed by rhettinger Error in section 4.2 of Python Tutorial (2005-05-02) http://python.org/sf/1194209 closed by rhettinger string.rstrip strips more than supposed to in some cases (2005-05-06) http://python.org/sf/1196824 closed by goodger % gives wrong results (2005-05-08) http://python.org/sf/1197806 closed by mwh time module ignores timezone changes (2005-05-09) http://python.org/sf/1198275 closed by bcannon calendar.weekheader not found in __all__ (2005-05-02) http://python.org/sf/1193890 closed by rhettinger RFE Closed __ logging module root logger name (2005-04-27) http://python.org/sf/1190689 closed by vsajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/opti
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
Guido van Rossum wrote: > Now it would make more sense to change the syntax to > > with EXPR as VAR: > BLOCK > > and we have Phillip Eby's proposal. Change the 'with' to 'do' and I'd be +1 on this. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Nick Coghlan wrote: > Hmm, with that approach, a code inspection tool like pychecker could be used > to > pick up the slack, and flag generators which have a yield inside a > try/finally > or a user defined statement without applying the "needs finalisation" > decorator What about giving them an __exit__ method if and only if they have a yield inside a try/finally? Old generators won't be doing that, because it's currently illegal. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
Greg Ewing wrote: > Nick Coghlan wrote: >> Hmm, with that approach, a code inspection tool like pychecker could >> be used to pick up the slack, and flag generators which have a yield >> inside a try/finally or a user defined statement without applying >> the "needs finalisation" decorator > > What about giving them an __exit__ method if and only > if they have a yield inside a try/finally? Old generators > won't be doing that, because it's currently illegal. It's possible to create a generator that does not contain a finally, but still needs cleanup. def gen(): try: yield except: print 'cleanup' raise Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
