[Python-Dev] Pre-PEP: Unifying try-except and try-finally
Hello,
after proposing this here (albeit deep in the PEP 340 thread) and
getting a somewhat affirmatory response from Guido, I have written
something that could become a PEP if sufficiently hatched...
---
PEP: XXX
Title: Unifying try-except and try-finally
Version: $Revision: $
Last-Modified: $Date: $
Author: Reinhold Birkenfeld <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 04-May-2005
Post-History:
Abstract
This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-except-finally blocks. This
means in short that it would be valid to write
try:
except Exception:
finally:
Rationale/Proposal
There are many use cases for the try-except statement and
for the try-finally statement per se; however, often one needs
to catch exceptions and execute some cleanup code afterwards.
It is slightly annoying and not very intelligible that
one has to write
f = None
try:
try:
f = open(filename)
text = f.read()
except IOError:
print 'An error occured'
finally:
if f:
f.close()
So it is proposed that a construction like this
try:
except Ex1:
else:
finally:
be exactly the same as the legacy
try:
try:
except Ex1:
else:
finally:
This is backwards compatible, and every try statement that is
legal today would continue to work.
Changes to the grammar
The grammar for the try statement, which is currently
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] | 'try' ':' suite 'finally' ':' suite)
would have to become
try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] ['finally' ':' suite] |
'try' ':' suite (except_clause ':' suite)*
['else' ':' suite] 'finally' ':' suite)
Implementation
As the PEP author currently does not have sufficient knowledge
of the CPython implementation, he is unfortunately not able
to deliver one.
References
None yet.
Copyright
This document has been placed in the public domain.
---
Reinhold
--
Mail address is perfectly valid!
___
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] Py_UNICODE madness
Nicholas Bastin wrote: > The documentation for Py_UNICODE states the following: > > "This type represents a 16-bit unsigned storage type which is used by > Python internally as basis for holding Unicode ordinals. On platforms > where wchar_t is available and also has 16-bits, Py_UNICODE is a > typedef alias for wchar_t to enhance native platform compatibility. On > all other platforms, Py_UNICODE is a typedef alias for unsigned > short." > > However, we have found this not to be true on at least certain RedHat > versions (maybe all, but I'm not willing to say that at this point). > pyconfig.h on these systems reports that PY_UNICODE_TYPE is wchar_t, > and PY_UNICODE_SIZE is 4. Needless to say, this isn't consistent with > the docs. It also creates quite a few problems when attempting to > interface Python with other libraries which produce unicode data. > > Is this a bug, or is this behaviour intended? It's a documentation bug. The above was true in Python 2.0 and still is for standard Python builds. The optional 32-bit support was added later on (in Python 2.1 IIRC) and is only used if Python is compiled with --enable-unicode=ucs4. Unfortunately, RedHat and others have made the UCS4 build their default which caused and is still causing lots of problems with Python extensions shipped as binaries, e.g. RPMs or other packages. > It turns out that at some point in the past, this created problems for > tkinter as well, so someone just changed the internal unicode > representation in tkinter to be 4 bytes as well, rather than tracking > down the real source of the problem. > > Is PY_UNICODE_TYPE always going to be guaranteed to be 16 bits, or is > it dependent on your platform? (in which case we can give up now on > Python unicode compatibility with any other libraries). Depends on the way Python was compiled. > At the very > least, if we can't guarantee the internal representation, then the > PyUnicode_FromUnicode API needs to go away, and be replaced with > something capable of transcoding various unicode inputs into the > internal python representation. We have PyUnicode_Decode() for that. PyUnicode_FromUnicode is useful and meant for working directly on Py_UNICODE buffers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 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: Breaking out.
On 5/3/05, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> We could avoid explaining to a newbie why the following code doesn't
> work if "opening" could be implemented in way that it works.
>
> for filename in filenames:
> block opening(filename) as file:
> if someReason: break
My initial feeling was that this is a fairly major issue, not just
from an education POV, but also because it would be easy to imagine
someone converting
f = open(name)
...
close(f)
into
opening(name) as f:
...
as part of a maintenance fix (an exception fails to close the file) or
tidy-up (upgrading code to conform to new best practices). But when I
tried to construct a plausible example, I couldn't find a case which
made real-life sense. For example, with Nicolas' original example:
for name in filenames:
opening(name) as f:
if condition: break
I can't think of a reasonable condition which wouldn't involve reading
the file - which either involves an inner loop (and we already can't
break out of two loops, so the third one implied by the opening block
makes things no worse), or needs the whole file reading (which can be
done via f = open(); data = f.read(); f.close() and the opening block
doesn't actually help...)
So I believe the issue is less serious than I supposed at first - it's
certainly a teaching issue, but might not come up often enough in real
life to matter.
Oh, and by the way - I prefer the keywordless form of the block
statement (as used in my examples above). But it may exacerbate the
issue with break unless we have a really strong name for these
constructs ("break exits the innermost enclosing for, while, or um,
one of those things which nearly used the block keyword...") Actually,
maybe referring to them as "block statements", but using no keyword,
is perfectly acceptable. As I write, I'm finding it more and more
natural.
Paul.
___
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] Need to hook Py_FatalError
Hi, Josiah Carlson <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >>> strip >> IMHO this should be left to hooker(apparerently not right word, but you >> get the point :) ). If he allocates more mem. or does heavy stuff, that >> will just fail. Anyway abort() is a failure too. Either abort() will >> end the process or OS will on such a critical error. > > I'm not talking about doing memory-intensive callbacks, I'm talking > about the function call itself. > >>From what I understand, any function call in Python requires a memory > allocation. This is trivially true in the case of rentrant Python calls; > which requires the allocation of a frame object from heap memory, and in > the case of all calls, from C stack memory. If you cannot allocate a > frame for __del__ method calling (one of the error conditions), you > certainly aren't going to be able to call a Python callback (no heap > memory), and may not have enough stack memory required by your logging > function; even if it is written in C (especially if you construct a > nontrivial portion of the message in memory before it is printed). > > If I'm wrong, I'd like to hear it, but I'm still waiting for your patch > on sourceforge. > - Josiah Wait a minute I guess I wasn't clear on that: The callback will be only in C level smtg like "PySetFatalError_CallBack" , there will be no way to hook it from Python because as you said Python may have crashed hard like "Can't initialize type". Best regards. ___ 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] Need to hook Py_FatalError
Hi, James William Pye <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > On Tue, 2005-05-03 at 13:39 -0700, Josiah Carlson wrote: > >> If I'm wrong, I'd like to hear it, but I'm still waiting for your patch >> on sourceforge. > > Well, if he lost/loses interest for whatever reason, I'd be willing to > provide. > > Although, if m.u.k. is going to write it, please be sure to include a > CPP macro/define, so that embedders could recognize the feature without > having to run explicit checks or do version based fingerprinting. (I'd > be interested to follow the patch if you(muk) put it up!) > > Hrm, although, I don't think it would be wise to allow extension modules > to set this. IMO, there should be some attempt to protect it; ie, once > it's initialized, don't allow reinitialization, as if the embedder is > handling it, it should be handled through the duration of the process. > So, a static function pointer in pythonrun.c initialized to NULL, a > protective setter that will only allow setting if the pointer is NULL, > and Py_FatalError calling the pointer if pointer != Py_FatalError. > > Should [Py_FatalError] fall through if the hook didn't terminate the > process to provide some level of warranty that the process will indeed > die? > > Sound good? I haven't lost interest, I expect to publish at most in a couple of days at SourceForge. The reinit. issue: The old way of returning old callback when a new callback is set sounds OK. Or better way: there may be an array to hold all the callbacks, Py_FatalError iterates and call each. M. Utku Karatas Best regards. ___ 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 -- concept clarification
James Y Knight wrote: > On May 3, 2005, at 12:53 PM, Guido van Rossum wrote: > >>def saving_stdout(f): >>save_stdout = sys.stdout >>try: >>sys.stdout = f >>yield >>finally: >>sys.stdout = save_stdout > > > I hope you aren't going to be using that in any threaded program. sys.stdout is a global - threading issues are inherent in monkeying with it. At least this approach allows all code that redirects stdout to be easily serialised: def redirect_stdout(f, the_lock=Lock()): locking(the_lock): save_stdout = sys.stdout try: sys.stdout = f yield finally: sys.stdout = save_stdout Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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 -- concept clarification
Tim Peters wrote:
> I don't think anyone has mentioned this yet, so I will: library
> writers using Decimal (or more generally HW 754 gimmicks) have a need
> to fiddle lots of thread-local state ("numeric context"), and must
> restore it no matter how the routine exits. Like "boost precision to
> twice the user's value over the next 12 computations, then restore",
> and "no matter what happens here, restore the incoming value of the
> overflow-happened flag". It's just another instance of temporarily
> taking over a shared resource, but I think it's worth mentioning that
> there are a lot of things "like that" in the world, and to which
> decorators don't really sanely apply.
To turn this example into PEP 340 based code:
# A template to be provided by the decimal module
# Context is thread-local, so there is no threading problem
def in_context(context):
old_context = getcontext()
try:
setcontext(context)
yield
finally:
setcontext(old_context)
Used as follows:
block decimal.in_context(Context(prec=12)):
# Perform higher precision operations here
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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] anonymous blocks
Guido van Rossum wrote: > Fredrik, what does your intuition tell you? having been busy with other stuff for nearly a week, and seeing that the PEP is now at version 1.22, my intuition tells me that it's time to read the PEP again before I have any opinion on anything ;-) ___ 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 -- concept clarification
Phillip J. Eby wrote:
> This and other examples from the PEP still have a certain awkwardness of
> phrasing in their names. A lot of them seem to cry out for a "with"
> prefix, although maybe that's part of the heritage of PEP 310. But Lisp
> has functions like 'with-open-file', so I don't think that it's *all* a PEP
> 310 influence on the examples.
I've written up a few examples in the course of the discussion, and the more of
them I have written, the more the keywordless syntax has grown on me.
No meaningful name like 'with' or 'in' is appropriate for all possible block
iterators, which leaves only keyword-for-the-sake-of-a-keyword options like
'block' or 'suite'. With block statements viewed as user-defined blocks,
leaving
the keyword out lets the block iterator be named whatever is appropriate to
making the block statement read well. If a leading 'with' is needed, just
include it in the name.
That is, instead of a 'block statement with the locking block iterator', you
write a 'locking statement'. Instead of a block statement with the opening
block
iterator', you write an 'opening statement'.
The benefit didn't stand out for me until writing examples with real code
around
the start of the block statement. Unlike existing statements, the keyword is
essentially irrelevant in understanding the implications of the statement - the
important thing is the block iterator being used. That is hard to see when the
keyword is the only thing dedented from the contained suite.
Consider some of the use cases from the PEP, but put inside function
definitions
to make it harder to pick out the name of the block iterator:
def my_func():
block locking(the_lock):
do_some_operation_while_holding_the_lock()
Versus:
def my_func():
locking(the_lock):
do_some_operation_while_holding_the_lock()
And:
def my_func(filename):
block opening(filename) as f:
for line in f:
print f
Versus:
def my_func(filename):
opening(filename) as f:
for line in f:
print f
And a few more without the contrast:
def my_func():
do_transaction():
db.delete_everything()
def my_func():
auto_retry(3, IOError):
f = urllib.urlopen("http://python.org/peps/pep-0340.html";)
print f.read()
def my_func():
opening(filename, "w") as f:
with_stdout(f):
print "Hello world"
When Guido last suggested this, the main concern seemed to be that the
documentation for every block iterator would need to explain the semantics of
block statements, since the block iterator name is the only name to be looked
up
in the documentation. But they don't need to explain the general semantics,
they
only need to explain _their_ semantics, and possibly provide a pointer to the
general block statement documentation. That is, explain _what_ the construct
does (which is generally straightforward), not _how_ it does it (which is
potentially confusing).
E.g.
def locking(the_lock):
"""Executes the following nested block while holding the supplied lock
Ensures the lock is acquired before entering the block and
released when the block is exited (including via exceptions
or return statements).
If None is supplied as the argument, no locking occurs.
"""
if the_lock is None:
yield
else:
the_lock.acquire()
try:
yield
finally:
the_lock.release()
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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 -- concept clarification
> At 05:17 PM 5/3/05 -0700, Guido van Rossum wrote: >>But I kind of doubt that it's an issue; you'd have to have a >>try/except catching StopIteration around a yield statement that >>resumes the generator before this becomes an issue, and that sounds >>extremely improbable. The specific offending construct is: yield itr.next() Wrapping that in StopIteration can be quite convenient, and is probably too common to ignore - Phillip's examples reminded me that some my _own_ code uses this trick. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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 -- concept clarification
Delaney, Timothy C (Timothy) wrote: > Guido van Rossum wrote: > > >>I'd like the block statement to be defined exclusively in terms of >>__exit__() though. > > > This does actually suggest something to me (note - just a thought - no > real idea if it's got any merit). > > Are there any use cases proposed for the block-statement (excluding the > for-loop) that do *not* involve resource cleanup (i.e. need an > __exit__)? > > This could be the distinguishing feature between for-loops and > block-statements: > > 1. If an iterator declares __exit__, it cannot be used in a for-loop. >For-loops do not guarantee resource cleanup. > > 2. If an iterator does not declare __exit__, it cannot be used in a > block-statement. >Block-statements guarantee resource cleanup. > > This gives separation of API (and thus purpose) whilst maintaining the > simplicity of the concept. Unfortunately, generators then become a pain > :( We would need additional syntax to declare that a generator was a > block generator. Ah, someone else did post this idea first :) To deal with the generator issue, one option would be to follow up on Phillip's idea of a decorator to convert a generator (or perhaps any standard iterator) into a block iterator. I think this would also do wonders for emphasising the difference between for loops and block statements. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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: Breaking out.
Paul Moore wrote: > Oh, and by the way - I prefer the keywordless form of the block > statement (as used in my examples above). But it may exacerbate the > issue with break unless we have a really strong name for these > constructs "may" exacerbate? Something of an understatement, unfortunately. 'break' and 'continue' are going to be useless in most block statements, and in most of the cases where that is true, one would expect them to break out of a surrounding loop. Reconsidering the non-looping semantics I discussed way back at the start of this exercise, this is what using auto_retry would look like with a single-pass block statement: for attempt in auto_retry(3, IOError): attempt: # Do something! # Including break and continue to get on with the next attempt! (Now that's what I call a user defined statement - we're iterating over a list of them!) Anyway, auto_retry and the block statements it returns could be implemented as: def suppressing(exc=Exception, on_success=None): """Suppresses the specified exception in the following block""" try: yield except exc: pass else: if on_success is not None: on_success() def just_do_it(): """Simply executes the following block""" yield def auto_retry(times, exc=Exception): """Generates the specified number of attempts""" class cb(): succeeded = False def __init__(self): cb.succeeded = True for i in xrange(times-1): yield suppressing(exc, cb) if cb.succeeded: break else: yield just_do_it() (Prettier than my last attempt at writing this, but still not very pretty. However, I'm willing to trade the need for that callback in the implementation of auto_retry to get non-surprising behaviour from break and continue, as the latter is visible to the majority of users, but the former is not) Note that the code above works, even *if* the block statement is a looping construct, making a mess out of TOOWTDI. Making it single pass also simplifies the semantics of the block statement (using VAR1 and EXPR1 from PEP 340): finalised = False block_itr = EXPR1 try: try: VAR1 = block_itr.next() except StopIteration: # Can still choose not to run the block at all finalised = True except: # There was an exception. Handle it or just reraise it. finalised = True exc = sys.exc_info() ext = getattr(block_itr, "__exit__", None) if ext is not None: ext(*exc) # May re-raise *exc else: raise *exc # Well, the moral equivalent :-) finally: if not finalised: # The block finished cleanly, or exited via # break, return or continue. Clean up the iterator. ext = getattr(block_itr, "__exit__", None) if ext is not None: try: ext(StopIteration) except StopIteration: pass With single-pass semantics, an iterator used in a block statement would have it's .next() method called exactly once, and it's __exit__ method called exactly once if the call to .next() does not raise StopIteration. And there's no need to mess with the meaning of break, return or continue - they behave as usual, affecting the surrounding scope rather than the block statement. The only new thing needed is an __exit__ method on generators (and the block syntax itself, of course). Looks like I've come full circle, and am back to arguing for semantics closer to those in PEP 310. But I have a better reason now :) > Actually, > maybe referring to them as "block statements", but using no keyword, > is perfectly acceptable. As I write, I'm finding it more and more > natural. Same here. Especially if the semantics are tweaked so that it *is* a straightforward statement instead of a loop. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] Py_UNICODE madness
On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote: >> At the very least, if we can't guarantee the internal representation, >> then the PyUnicode_FromUnicode API needs to go away, and be replaced >> with something capable of transcoding various unicode inputs into the >> internal python representation. > > We have PyUnicode_Decode() for that. PyUnicode_FromUnicode is > useful and meant for working directly on Py_UNICODE buffers. Is this API documented anywhere? (It's not in the Unicode Object section of the API doc). Also, this is quite inefficient if the source data is in UTF-16, because it appears that I'll have to transcode my data to utf-8 before I can pass it to this function, but I guess I'll have to live with that. -- 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
[Python-Dev] Python Language track at Europython, still possibilities to submit talks
I'm the track chair of the Python Language track at Europython (27-29 June, Göteborg, Sweden) . The general deadlline for talk submission has been extended until the 7th of May. There are still open slots for the language track. So if someone with (core) language interests is or may be interested in partecipating, there's still the possibility to submit talks about idioms, patterns, recent new additions to language (for example new 2.4 features), or other language related topics. http://www.europython.org/sections/tracks_and_talks/propose_a_talk/#language http://www.europython.org/sections/tracks_and_talks/propose_a_talk/ http://www.europython.org Regards, Samuele Pedroni, Python Language Track chair. ___ 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] Need to hook Py_FatalError
On Wed, 2005-05-04 at 09:46 +, M.Utku K. wrote: > The reinit. issue: The old way of returning old callback when a new > callback is set sounds OK. Or better way: there may be an array to hold all > the callbacks, Py_FatalError iterates and call each. Why should reinitialization be allowed at all? Seems to me that this feature should be exclusively reserved for an embedding application to handle the fatal in an application specific way; ie ereport(FATAL,()) in PostgreSQL, which quickly exits after some cleanup. Why should an extension module be allowed to set this, or reset it? -- Regards, James William Pye ___ 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: Breaking out.
On May 4, 2005, at 01:57, Paul Moore wrote: > tried to construct a plausible example, I couldn't find a case which > made real-life sense. For example, with Nicolas' original example: > > for name in filenames: > opening(name) as f: > if condition: break > > I can't think of a reasonable condition which wouldn't involve reading > the file - which either involves an inner loop (and we already can't > break out of two loops, so the third one implied by the opening block > makes things no worse), or needs the whole file reading (which can be Looking for a file with a certain magicnumber in its 1st two bytes...? for name in filenames: opening(name) as f: if f.read(2) == 0xFEB0: break This does seem to make real-life sense to me... 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] PEP 340: Breaking out.
On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On May 4, 2005, at 01:57, Paul Moore wrote: > > > > I can't think of a reasonable condition which wouldn't involve reading > > the file - which either involves an inner loop (and we already can't > > break out of two loops, so the third one implied by the opening block > > makes things no worse), or needs the whole file reading (which can be > > Looking for a file with a certain magicnumber in its 1st two bytes...? > > for name in filenames: > opening(name) as f: > if f.read(2) == 0xFEB0: break > > This does seem to make real-life sense to me... Yes, that'd do. I can't say I think it would be common, but it's a valid case. And the workaround is the usual messy flag variable: for name in filenames: found = False opening(name) as f: if f.read(2) == 0xFEB0: found = True if found: break Yuk. Paul. ___ 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: Breaking out.
On 5/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > With single-pass semantics, an iterator used in a block statement would have > it's .next() method called exactly once, and it's __exit__ method called > exactly > once if the call to .next() does not raise StopIteration. And there's no need > to > mess with the meaning of break, return or continue - they behave as usual, > affecting the surrounding scope rather than the block statement. > > The only new thing needed is an __exit__ method on generators (and the block > syntax itself, of course). Makes me wonder if we shouldn't just return to the __enter__() and __exit__() names of PEP 310[1] where for a generator __enter__() is just an alias for next(). We could even require Phillip J. Eby's "blockgenerator" decorator to rename next() to __enter__(), and add the appropriate __exit__() method. Something like: class blockgen(object): def __init__(self, gen): self.gen = gen def __enter__(self): self.gen.next() def __exit__(self): # cause finally blocks to be executed def blockgenerator(genfunc): def getblockgen(*args, **kwargs): return blockgen(genfunc(*args, **kwargs)) return getblockgen to be used like: @blockgenerator def locking(lock): lock.acquire() try: yield finally: lock.release() 'Course, it might be even nicer if try/finally around a yield could only be used with block generators... To get a syntax error, we'd have to replace the decorator with a new syntax, e.g. Tim Delaney's "resource" instead of "def" syntax or maybe using something like "blockyield" or "resourceyield" instead of "yield" (though these are probably too long)... Steve [1]http://www.python.org/peps/pep-0310.html -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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] Need to hook Py_FatalError
James William Pye <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > On Wed, 2005-05-04 at 09:46 +, M.Utku K. wrote: >> The reinit. issue: The old way of returning old callback when a new >> callback is set sounds OK. Or better way: there may be an array to hold >> all the callbacks, Py_FatalError iterates and call each. > > Why should reinitialization be allowed at all? Seems to me that this > feature should be exclusively reserved for an embedding application to > handle the fatal in an application specific way; ie ereport(FATAL,()) in > PostgreSQL, which quickly exits after some cleanup. Why should an > extension module be allowed to set this, or reset it? What if more than one extension needs it ? Curently Im doing callback_type SetCallBack(callback_type newfunc) This will set the callback to newfunc and return the old one. Extension developer may discard or call them at his own will. What do you think? ___ 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] Py_UNICODE madness
Nicholas Bastin wrote: > > On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote: > >>> At the very least, if we can't guarantee the internal representation, >>> then the PyUnicode_FromUnicode API needs to go away, and be replaced >>> with something capable of transcoding various unicode inputs into the >>> internal python representation. >> >> >> We have PyUnicode_Decode() for that. PyUnicode_FromUnicode is >> useful and meant for working directly on Py_UNICODE buffers. > > > Is this API documented anywhere? (It's not in the Unicode Object > section of the API doc). Also, this is quite inefficient if the source > data is in UTF-16, because it appears that I'll have to transcode my > data to utf-8 before I can pass it to this function, but I guess I'll > have to live with that. Not at all. You pass in the pointer, the function does the rest: http://docs.python.org/api/builtinCodecs.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 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] Py_UNICODE madness
On May 4, 2005, at 1:39 PM, M.-A. Lemburg wrote: > Nicholas Bastin wrote: >> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote: At the very least, if we can't guarantee the internal representation, then the PyUnicode_FromUnicode API needs to go away, and be replaced with something capable of transcoding various unicode inputs into the internal python representation. >>> >>> >>> We have PyUnicode_Decode() for that. PyUnicode_FromUnicode is >>> useful and meant for working directly on Py_UNICODE buffers. >> Is this API documented anywhere? (It's not in the Unicode Object >> section of the API doc). Also, this is quite inefficient if the >> source data is in UTF-16, because it appears that I'll have to >> transcode my data to utf-8 before I can pass it to this function, but >> I guess I'll have to live with that. > > Not at all. You pass in the pointer, the function does the rest: Ah, I missed the codec registry lookup. Thanks. I'll change the Py_UNICODE doc, if anyone has a suggestion as to what to change it *to*... -- 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
[Python-Dev] New Py_UNICODE doc
The current documentation for Py_UNICODE states: "This type represents a 16-bit unsigned storage type which is used by Python internally as basis for holding Unicode ordinals. On platforms where wchar_t is available and also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short." I propose changing this to: "This type represents the storage type which is used by Python internally as the basis for holding Unicode ordinals. On platforms where wchar_t is available, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short. Extension module developers should make no assumptions about the size of this type on any given platform." If no one has a problem with that, I'll make the change in CVS. -- 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
Nicholas Bastin <[EMAIL PROTECTED]> writes: > The current documentation for Py_UNICODE states: > > "This type represents a 16-bit unsigned storage type which is used by > Python internally as basis for holding Unicode ordinals. On platforms > where wchar_t is available and also has 16-bits, Py_UNICODE is a > typedef alias for wchar_t to enhance native platform compatibility. On > all other platforms, Py_UNICODE is a typedef alias for unsigned > short." > > I propose changing this to: > > "This type represents the storage type which is used by Python > internally as the basis for holding Unicode ordinals. On platforms > where wchar_t is available, Py_UNICODE is a typedef alias for wchar_t > to enhance native platform compatibility. On all other platforms, > Py_UNICODE is a typedef alias for unsigned short. Extension module > developers should make no assumptions about the size of this type on > any given platform." > > If no one has a problem with that, I'll make the change in CVS. 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. At least that's my understanding, so the above seems still wrong. And +1 for trying to clean up this confusion. Thomas ___ 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] Need to hook Py_FatalError
On Wed, May 04, 2005 at 03:29:33PM +, M.Utku K. wrote:
> James William Pye <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
> > Why should reinitialization be allowed at all? Seems to me that this
> > feature should be exclusively reserved for an embedding application to
> > handle the fatal in an application specific way; ie ereport(FATAL,()) in
> > PostgreSQL, which quickly exits after some cleanup. Why should an
> > extension module be allowed to set this, or reset it?
>
> What if more than one extension needs it ?
I agree with James; As I imagine this feature, it is for programs that
embed Python, not for extensions. Whether the hook would be written to
prevent this from being done, or whether it would just be documented as
"for embedders only", I don't care.
In my own application, I didn't use a setter function, I just created a
new global variable. This works fine for me. It doesn't prevent the
(abusive, in my view) hooking of the error handler by any old extension,
but since my application doesn't currently import shared modules it
doesn't matter.
--- /tmp/Python-2.3/Python/pythonrun.c 2003-07-15 20:54:38.0 -0500
+++ ./pythonrun.c 2005-04-11 13:32:39.0 -0500
@@ -1435,9 +1435,14 @@
/* Print fatal error message and abort */
+void (*Py_FatalErrorHandler)(const char *msg) = NULL;
void
Py_FatalError(const char *msg)
{
+if(Py_FatalErrorHandler != NULL) {
+Py_FatalErrorHandler(msg);
+fprintf(stderr, "PyFatalErrorHandler returned\n");
+}
fprintf(stderr, "Fatal Python error: %s\n", msg);
#ifdef MS_WINDOWS
OutputDebugString("Fatal Python error: ");
pgpmJ9g1tfE0g.pgp
Description: PGP signature
___
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: Breaking out.
Paul Moore wrote: > On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote: >> >> On May 4, 2005, at 01:57, Paul Moore wrote: >> > >> > I can't think of a reasonable condition which wouldn't involve reading >> > the file - which either involves an inner loop (and we already can't >> > break out of two loops, so the third one implied by the opening block >> > makes things no worse), or needs the whole file reading (which can be >> >> Looking for a file with a certain magicnumber in its 1st two bytes...? >> >> for name in filenames: >> opening(name) as f: >> if f.read(2) == 0xFEB0: break >> >> This does seem to make real-life sense to me... > > Yes, that'd do. I can't say I think it would be common, but it's a > valid case. And the workaround is the usual messy flag variable: > > for name in filenames: > found = False > opening(name) as f: > if f.read(2) == 0xFEB0: found = True > if found: break Is there anything we could do about this? Reinhold -- Mail address is perfectly valid! ___ 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] "begin" as keyword for pep 340
I'm a bit surpised that no one has yet [1] suggested "begin" as a keyword instead "block" as it seems to express the intent of blocks and is concise and readable. For example, here are the examples in PEP 340 rewritten using "begin": begin locking(): ... begin opening(path) as f: #how about: begin using_file(path) as f: ... begin transaction(db): ... begin auto_retry(3): ... begin redirecting_stdout: Probably the biggest problem with "begin" is that it is relatively common as an identify. For example, Greping through Python's Lib directory, begin is used as a method name twice (in httplib and idlelib.pyshell) and as a local twice (in mhlib and pyassemb). However, i can't think of many instances where there would be ambiguity in usage -- could 'begin' be a pseudo-identifier like "as" for some transitional time? -- adam [1] (Or maybe GMail's search has failed me ;) ___ 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] my first post: asking about a "decorator" module
My first post to python-dev, but I guess my name is not completely unknown in this list ;) Actually, I have been wondering about subscribing to python-dev for at least a couple of years, but never did it, because of the limited amount of time I have to follow all the interesting mailing lists in the world. However, in the last few months I have been involved with teaching Python and I have decided to follow more closely the development to keep myself updated on what is going on. Plus, I have some ideas I would like to share with people in this list. One of them concerns decorators. Are there plans to improve decorators support in future Python versions? By "improving decorator support" I mean for instance a module in the standard library providing some commonly used decorators such as ``memoize``, or utilities to create and compose decorators, and things like that. I have been doing some work on decorators lately and I would be willing to help is there is a general interest about a "decorator" module. Actually, I have already a good candidate function for that module, and plenty of recipes. I submitted an early version of the idea some time ago on c.l.py http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/60f22ed33af5dbcb/5f870d271456ccf3?q=simionato+decorate&rnum=1&hl=en#5f870d271456ccf3 but I could as well flesh it out and deliver a module people can play with and see if they like it. This is especially interesting in this moment, since decorators may address many of the use cases of PEP 340 (not all of them). I need to write down some documentation, but it could be done by tomorrow. What do people think? 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] "begin" as keyword for pep 340
Adam Souzis wrote: > I'm a bit surpised that no one has yet [1] suggested "begin" as a > keyword instead "block" as it seems to express the intent of blocks > and is concise and readable. For example, here are the examples in > PEP 340 rewritten using "begin": > > begin locking(): >... I don't know, but I always would expect "end" to follow each begin somewhere... the-good-old-pascal-days-ly yours, Reinhold PS: What about "using"? Too C#-ish? -- Mail address is perfectly valid! ___ 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 <[EMAIL PROTECTED]> writes: > The current documentation for Py_UNICODE states: > > "This type represents a 16-bit unsigned storage type which is used by > Python internally as basis for holding Unicode ordinals. On platforms > where wchar_t is available and also has 16-bits, Py_UNICODE is a > typedef alias for wchar_t to enhance native platform compatibility. On > all other platforms, Py_UNICODE is a typedef alias for unsigned > short." > > I propose changing this to: > > "This type represents the storage type which is used by Python > internally as the basis for holding Unicode ordinals. On platforms > where wchar_t is available, Py_UNICODE is a typedef alias for wchar_t > to enhance native platform compatibility. This just isn't true. Have you read ./configure --help recently? > On all other platforms, Py_UNICODE is a typedef alias for unsigned > short. Extension module developers should make no assumptions about > the size of this type on any given platform." I like this last sentence, though. > If no one has a problem with that, I'll make the change in CVS. I have a problem with replacing one lie with another :) Cheers, mwh -- Just put the user directories on a 486 with deadrat7.1 and turn the Octane into the afforementioned beer fridge and keep it in your office. The lusers won't notice the difference, except that you're more cheery during office hours. -- Pim van Riezen, asr ___ 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
Nice one. Should be a piece of cake to implement. Please talk to
[EMAIL PROTECTED] about getting it checked into the PEP database.
I'm +1 on accepting this now -- anybody against?
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after proposing this here (albeit deep in the PEP 340 thread) and
> getting a somewhat affirmatory response from Guido, I have written
> something that could become a PEP if sufficiently hatched...
>
> ---
>
> PEP: XXX
> Title: Unifying try-except and try-finally
> Version: $Revision: $
> Last-Modified: $Date: $
> Author: Reinhold Birkenfeld <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/plain
> Created: 04-May-2005
> Post-History:
>
> Abstract
>
> This PEP proposes a change in the syntax and semantics of try
> statements to allow combined try-except-finally blocks. This
> means in short that it would be valid to write
>
> try:
>
> except Exception:
>
> finally:
>
>
> Rationale/Proposal
>
> There are many use cases for the try-except statement and
> for the try-finally statement per se; however, often one needs
> to catch exceptions and execute some cleanup code afterwards.
> It is slightly annoying and not very intelligible that
> one has to write
>
> f = None
> try:
> try:
> f = open(filename)
> text = f.read()
> except IOError:
> print 'An error occured'
> finally:
> if f:
> f.close()
>
> So it is proposed that a construction like this
>
> try:
>
> except Ex1:
>
>
> else:
>
> finally:
>
>
> be exactly the same as the legacy
>
> try:
> try:
>
> except Ex1:
>
>
> else:
>
> finally:
>
>
> This is backwards compatible, and every try statement that is
> legal today would continue to work.
>
> Changes to the grammar
>
> The grammar for the try statement, which is currently
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] | 'try' ':' suite 'finally' ':' suite)
>
> would have to become
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] ['finally' ':' suite] |
>'try' ':' suite (except_clause ':' suite)*
>['else' ':' suite] 'finally' ':' suite)
>
> Implementation
>
> As the PEP author currently does not have sufficient knowledge
> of the CPython implementation, he is unfortunately not able
> to deliver one.
>
> References
>
> None yet.
>
> Copyright
>
> This document has been placed in the public domain.
>
> ---
> Reinhold
>
> --
> Mail address is perfectly valid!
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--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] PEP 340: propose to get rid of 'as' keyword
I have not read every email about this subject, so sorry if this has already been mentioned. In PEP 340 I read: block EXPR1 as VAR1: BLOCK1 I think it would be much clearer this (plus you save one keyword): block VAR1 = EXPR1: BLOCK1 Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ 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 4, 2005, at 1:02 PM, Michael Hudson wrote: > Nicholas Bastin <[EMAIL PROTECTED]> writes: > >> The current documentation for Py_UNICODE states: >> >> "This type represents a 16-bit unsigned storage type which is used by >> Python internally as basis for holding Unicode ordinals. On platforms >> where wchar_t is available and also has 16-bits, Py_UNICODE is a >> typedef alias for wchar_t to enhance native platform compatibility. >> On >> all other platforms, Py_UNICODE is a typedef alias for unsigned >> short." >> >> I propose changing this to: >> >> "This type represents the storage type which is used by Python >> internally as the basis for holding Unicode ordinals. On platforms >> where wchar_t is available, Py_UNICODE is a typedef alias for wchar_t >> to enhance native platform compatibility. > > This just isn't true. Have you read ./configure --help recently? Ok, so the above statement is true if the user does not set --enable-unicode=ucs[24] (was reading the whar_t test in configure.in, and not the generated configure help). Alternatively, we shouldn't talk about the size at all, and just leave the first and last sentences: "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 type on any given platform." -- 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] PEP 340 -- loose ends
[ Guido ]: > 1. Decide on a keyword to use, if any. Shouldn't be the other way around ? Decide to use *no* keyword, if that could be avoided. In my large inexperience *no keyword* is much better (if feasible): 1) No name conflicts with previous code: block, blocktemplate, whatever 2) ':' is already a block (broader sense) indication 3) Improved readbility: <> def locking_opening(lock, filename, mode="r"): block locking(lock): block opening(filename) as f: yield f <> def locking_opening(lock, filename, mode="r"): locking(lock): opening(filename) as f: yield f 4) Better to make the language parser more complex than the language exposed to end-users Following the PEP and this thread, it seems to me that __no keyword__ is less preferable than __some keyword__(=='block' so far), and I wonder why is not the reverse. Perhaps I missed something ? Besides, I think this solves many issues AOP was trying to tackle in a much cleaner, elegant -- therefore pythonic -- way. Outstanding. best regards, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.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] Pre-PEP: Unifying try-except and try-finally
On Wed, 2005-05-04 at 13:09, Guido van Rossum wrote: > Nice one. Should be a piece of cake to implement. Please talk to > [EMAIL PROTECTED] about getting it checked into the PEP database. +1! -Barry signature.asc Description: This is a digitally signed message part ___ 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
[ Guido ]: > Nice one. Should be a piece of cake to implement. Please talk to > [EMAIL PROTECTED] about getting it checked into the PEP database. > > I'm +1 on accepting this now -- anybody against? +1 Last week, while I was giving a Python course (in Rio de Janeiro-Brazil) some students attempted to use try/except/finally blocks. I had to dig the grammar to prove to them that it was __not already__ supported. cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.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] my first post: asking about a "decorator" module
> Are there plans to improve decorators support in future Python versions? > By "improving decorator support" I mean for instance a module in the > standard > library providing some commonly used decorators such as ``memoize``, > or utilities to create and compose decorators, and things like that. Ultimately, some of these will likely end-up in the library. For the time being, I think it best that these get posted and evolve either as Wiki entries or as ASPN entries. The best practices and proven winners have yet to emerge. Solidifying first attempts is likely not a good idea. Putting tools in the standard library should be the last evolutionary step, not the first. Raymond Hettinger ___ 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] Need to hook Py_FatalError
On Wed, 2005-05-04 at 15:29 +, M.Utku K. wrote: > Extension developer may discard or call them at his own will. That's the issue, an extension developer shouldn't be able to discard it, as I, the embedder, do not want my hook to be clobbered. The extension developer doesn't set the context of the application, the embedder does. > What if more than one extension needs it ? Firstly, I don't think it is likely an extension module *by itself* would ever have to initialize something that would *require* some form of cleanup if the app were to fatal out. If it did, I imagine that it would be suspect of poor design, any exceptions likely to be few and far between. Now, that doesn't mean its use during the process might not create some state or side effect where cleanup would be nice. Although, chances are that such cleanup should occur during normal operations, and be handled via a Python exception, something that a fatal is not. -- Regards, James William Pye signature.asc Description: This is a digitally signed message part ___ 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: propose to get rid of 'as' keyword
Gustavo J. A. M. Carneiro wrote: > I have not read every email about this subject, so sorry if this has > already been mentioned. > > In PEP 340 I read: > > block EXPR1 as VAR1: > BLOCK1 > > I think it would be much clearer this (plus you save one keyword): > > block VAR1 = EXPR1: > BLOCK1 clearer for whom? where else is this construct used in Python? ___ 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
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 more than just "same size"; it also implies that widechar predicates (iswalnum etc) works properly with Unicode characters, under all locales. ___ 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 -- loose ends
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than __some keyword__(=='block' so far), and I wonder
> why is not the reverse. Perhaps I missed something ?
There is one problem with using no keyword: You cannot use arbitrary expressions
in the new statement. Consider:
resource = opening("file.txt")
block resource:
(...)
resource = opening("file.txt")
resource:
(...)
The latter would have to be forbidden.
(Seeing these examples, I somehow strongly dislike "block";
"with" or "using" seem really better)
Reinhold
--
Mail address is perfectly valid!
___
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
[Guido] > I'm +1 on accepting this now -- anybody against? I'm curious to know if you (Guido) remember why you removed this feature in Python 0.9.6? From the HISTORY file: """ New features in 0.9.6: - stricter try stmt syntax: cannot mix except and finally clauses on 1 try """ IIRC (and I may well not), half of people guessed wrong about whether an exception raised in an "except:" suite would or would not skip execution of the same-level "finally:" suite. try: 1/0 except DivisionByZero: 2/0 finally: print "yes or no?" The complementary question is whether an exception in the "finally:" suite will be handled by the same-level "except:" suites. There are obvious answers to both, of course. The question is whether they're the _same_ obvious answers across responders <0.7 wink>. ___ 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: propose to get rid of 'as' keyword
On May 4, 2005, at 2:29 PM, Fredrik Lundh wrote: > Gustavo J. A. M. Carneiro wrote: > > >> I have not read every email about this subject, so sorry if this >> has >> already been mentioned. >> >> In PEP 340 I read: >> >> block EXPR1 as VAR1: >> BLOCK1 >> >> I think it would be much clearer this (plus you save one keyword): >> >> block VAR1 = EXPR1: >> BLOCK1 >> > > clearer for whom? where else is this construct used in Python? It might be more clear to have the "var" on the left. The only place it's used on the right (that I know of) is in import statements when using the "as" clause. Assignment, for loops, generator expressions, list comprehensions, etc. always have the var on the left. -bob ___ 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 -- loose ends
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
Can you explain why it would have to be forbidden please?
Thanks,
Noam
___
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: Breaking out.
Alex Martelli wrote: > Looking for a file with a certain magicnumber in its 1st two bytes...? > > for name in filenames: > opening(name) as f: > if f.read(2) == 0xFEB0: break > > This does seem to make real-life sense to me... I'd like to suggest a small language enhancement that would fix this example. Allow the break and continue statements to use a keyword, either "for" or "while", to state that the code should break out of both the block statement and the innermost "for" or "while" statement. The example above would change to: for name in filenames: opening(name) as f: if f.read(2) == 0xFEB0: break for This could be a separate PEP if necessary. When a "break for" is used in a block statement, it should raise a new kind of exception, BreakForLoop, and the block statement should propagate the exception. When used outside a block statement, "break for" can use existing Python byte code to jump directly to the next appropriate statement. Shane ___ 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
"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > 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 more than just "same size"; it also implies that > widechar > predicates (iswalnum etc) works properly with Unicode characters, under all > locales. Ok, so who is going to collect the wisdom of this thread into the docs? Thomas ___ 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] Need to hook Py_FatalError
Hi all, > strip. > What if more than one extension needs it ? > Curently Im doing > > callback_type SetCallBack(callback_type newfunc) > > This will set the callback to newfunc and return the old one. Extension > developer may discard or call them at his own will. What do you think? > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.g > mane.org > Ok then, it will be a one shot callback registration. By the way declaration of the func ( void SetFatalError_Callback(PyFatalError_Func func) ) is in "pyerrors.h" but implemenatiton is is in "Pythonrun.c". Is it OK? Im listening for more. Best regards. ___ 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: propose to get rid of 'as' keyword
Gustavo J. A. M. Carneiro wrote: > In PEP 340 I read: > > block EXPR1 as VAR1: > BLOCK1 > > I think it would be much clearer this (plus you save one keyword): > > block VAR1 = EXPR1: > BLOCK1 I think you misunderstood the statement. EXPR1 creates an iterator, then VAR1 iterates over the values returns by the iterator. VAR1 never sees the iterator. Using your syntax would reinforce the misinterpretation that VAR1 sees the iterator. Shane ___ 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 -- loose ends
[ Senra ]:
> > [ Guido ]:
> > > 1. Decide on a keyword to use, if any.
> >
> > Shouldn't be the other way around ?
> > Decide to use *no* keyword, if that could be avoided.
[ Reinhold ]:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
I'm not quite sure why, but there seem to be a
workaround (forseen in PEP 340). And people seem
to be "using" this already <0.5 wink>:
[Alex Martelli]:
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
Moreover, an anonymous block should have
no <> (neither 'block', 'with', 'using')
to be true anonymous <1.0-Tim-Peter'ly wink>
cheers,
Senra
--
Rodrigo Senra
--
MSc Computer Engineerrodsenra(at)gpr.com.br
GPr Sistemas Ltdahttp://www.gpr.com.br/
Personal Blog http://rodsenra.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] PEP 340: propose to get rid of 'as' keyword
Shane Hathaway wrote: > Gustavo J. A. M. Carneiro wrote: > >> In PEP 340 I read: >> >>block EXPR1 as VAR1: >>BLOCK1 >> >> I think it would be much clearer this (plus you save one keyword): >> >>block VAR1 = EXPR1: >>BLOCK1 > > > I think you misunderstood the statement. EXPR1 creates an iterator, > then VAR1 iterates over the values returns by the iterator. VAR1 never ^^ returned by > sees the iterator. Using your syntax would reinforce the > misinterpretation that VAR1 sees the iterator. ___ 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] "begin" as keyword for pep 340
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> PS: What about "using"? Too C#-ish?
Another idea from a hobbyist programmer: "holding" or mabe just
"hold". Like this:
hold locked(myLock):
# Code here executes with myLock held. The lock is
# guaranteed to be released when the block is left (even
# if via return or by an uncaught exception).
hold opened("/etc/passwd") as f:
for line in f:
print line.rstrip()
___
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] Need to hook Py_FatalError
"M.Utku K." <[EMAIL PROTECTED]> wrote in news:Xns964CE11B16061token@ 80.91.229.5: > _Callback(PyFatalError_Func func) ) > is in "pyerrors.h" but implemenatiton is > is in "Pythonrun.c". Is it OK? Im listening for more. > Sorry, just checked decl. will be in "pydebug.h" ___ 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
Guido> Nice one. Should be a piece of cake to implement. Please talk to Guido> [EMAIL PROTECTED] about getting it checked into the PEP database. Guido> I'm +1 on accepting this now -- anybody against? I'm not against it, but I thought there were ambiguity reasons that this construct wasn't already implemented. I'm pretty sure people have asked about it before but been rebuffed. Here's a message with Reinhold's fingerprints on it: http://mail.python.org/pipermail/python-list/2004-June/227008.html Here's another one: http://mail.python.org/pipermail/python-list/2003-November/193159.html Both reference other articles which presumably have more details about the reasoning, but I was unable to find them with a quick search. Skip ___ 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: Breaking out.
On Wed, 4 May 2005, Shane Hathaway wrote: > I'd like to suggest a small language enhancement that would fix this > example. Allow the break and continue statements to use a keyword, > either "for" or "while", to state that the code should break out of both > the block statement and the innermost "for" or "while" statement. The > example above would change to: > > for name in filenames: > opening(name) as f: > if f.read(2) == 0xFEB0: > break for This is very elegant. It works beautifully with "break", though at first that natural analogs "continue for", "continue while" appear to conflict with Guido's proposed extension to "continue". But if we choose the keyword "with" to introduce an anonymous block, it comes out rather nicely: continue with 2 That's easier to read than "continue 2", in my opinion. (If it's not too cute for you.) Anyway, i like the general idea of letting the programmer specify exactly which block to break/continue, instead of leaving it looking ambiguous. Explicit is better than implicit, right? -- ?!ng ___ 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: Breaking out.
[ Shane Hathaway ]: > I'd like to suggest a small language enhancement that would fix this > example. Allow the break and continue statements to use a keyword, > either "for" or "while", to state that the code should break out of both > the block statement and the innermost "for" or "while" statement. The > example above would change to: > > for name in filenames: > opening(name) as f: > if f.read(2) == 0xFEB0: > break for > > This could be a separate PEP if necessary. When a "break for" is used > in a block statement, it should raise a new kind of exception, > BreakForLoop, and the block statement should propagate the exception. > When used outside a block statement, "break for" can use existing Python > byte code to jump directly to the next appropriate statement. What about nested blocks ? When they act as iterators that would be desireable too. What to do then: - baptize blocks -> break - keep them anonymous -> break #enclosing_scope_counter - do not support them cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.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] Pre-PEP: Unifying try-except and try-finally
On Wed, 2005-05-04 at 14:41, Tim Peters wrote: > IIRC (and I may well not), half of people guessed wrong about whether > an exception raised in an "except:" suite would or would not skip > execution of the same-level "finally:" suite. It would not, obviously . > try: > 1/0 > except DivisionByZero: > 2/0 > finally: > print "yes or no?" > > The complementary question is whether an exception in the "finally:" > suite will be handled by the same-level "except:" suites. It would not, obviously . > There are obvious answers to both, of course. The question is whether > they're the _same_ obvious answers across responders <0.7 wink>. It only matters that it's the same obvious answers across all responders who are right. :) -Barry signature.asc Description: This is a digitally signed message part ___ 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: Breaking out.
Ka-Ping Yee wrote: > On Wed, 4 May 2005, Shane Hathaway wrote: >> >>for name in filenames: >>opening(name) as f: >>if f.read(2) == 0xFEB0: >>break for > > > This is very elegant. Thanks. > It works beautifully with "break", though at > first that natural analogs "continue for", "continue while" appear to > conflict with Guido's proposed extension to "continue". > > But if we choose the keyword "with" to introduce an anonymous block, > it comes out rather nicely: > > continue with 2 > > That's easier to read than "continue 2", in my opinion. (If it's not > too cute for you.) Or perhaps: continue yield 2 This would create some symmetry, since generators will retrieve the value passed by a continue statement using a yield expression. Shane ___ 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
[Tim] > I'm curious to know if you (Guido) remember why you removed this > feature in Python 0.9.6? From the HISTORY file: > > """ > New features in 0.9.6: > - stricter try stmt syntax: cannot mix except and finally clauses on 1 try > """ > > IIRC (and I may well not), half of people guessed wrong about whether > an exception raised in an "except:" suite would or would not skip > execution of the same-level "finally:" suite. > > try: > 1/0 > except DivisionByZero: > 2/0 > finally: > print "yes or no?" > > The complementary question is whether an exception in the "finally:" > suite will be handled by the same-level "except:" suites. No. The rule of thumb is that control only passes forward. > There are obvious answers to both, of course. The question is whether > they're the _same_ obvious answers across responders <0.7 wink>. I think the main person confused was me. :-) In addition, at the time I don't think I knew Java -- certainly I didn't know it well enough to realize that it gives this construct the meaning proposed by Reinhold's PEP. -- --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] PEP 340 -- loose ends
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt")
>> block resource:
>> (...)
>>
>> resource = opening("file.txt")
>> resource:
>> (...)
>>
>> The latter would have to be forbidden.
>
> Can you explain why it would have to be forbidden please?
Well, with it you could create suites with _any_ introducing
identifier. Consider:
with:
(...)
synchronized:
(...)
try:
(...)
transaction:
(...)
Do you understand my concern? It would be very, very hard to discern
these "user-defined statements" from real language constructs.
Reinhold
--
Mail address is perfectly valid!
___
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
Tim Peters wrote: > [Guido] >> I'm +1 on accepting this now -- anybody against? > > I'm curious to know if you (Guido) remember why you removed this > feature in Python 0.9.6? From the HISTORY file: > > """ > New features in 0.9.6: > - stricter try stmt syntax: cannot mix except and finally clauses on 1 try > """ > > IIRC (and I may well not), half of people guessed wrong about whether > an exception raised in an "except:" suite would or would not skip > execution of the same-level "finally:" suite. With the arrival of Java and C#, which both have this feature, I think the wrong guesses are minimized. I think the behaviour of the "else" clause is much harder to guess, mainly when used with the looping constructs. > try: > 1/0 > except DivisionByZero: > 2/0 > finally: > print "yes or no?" > > The complementary question is whether an exception in the "finally:" > suite will be handled by the same-level "except:" suites. No, as except clauses can only occur before the finally clause, and execution should not go backwards. > There are obvious answers to both, of course. The question is whether > they're the _same_ obvious answers across responders <0.7 wink>. Reinhold -- Mail address is perfectly valid! ___ 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 -- loose ends
Reinhold Birkenfeld wrote:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions in the new statement.
[...]
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
Noam Raphael wrote:
> Can you explain why it would have to be forbidden please?
Reinhold Birkenfeld wrote:
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
>
> with:
> (...)
>
> synchronized:
> (...)
>
> try:
> (...)
>
> transaction:
> (...)
>
> Do you understand my concern? It would be very, very hard to discern
> these "user-defined statements" from real language constructs.
I think part of the debate is about whether that's good or bad.
I happen to agree with you -- i think a keyword is necessary --
but i believe some people see an advantage in having the flexibility
to make a "real-looking" construct.
As i see it the argument boils down to: Python is not Lisp.
There are good reasons why the language has keywords, why it
distinguishes statements from expressions, uses indentation, and
so on. All of these properties cause Python programs to be made
of familiar and easily recognizable patterns instead of degenerating
into a homogeneous pile of syntax.
-- ?!ng
___
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 -- loose ends
Ka-Ping Yee wrote: > Reinhold Birkenfeld wrote: >> Well, with it you could create suites with _any_ introducing >> identifier. Consider: >> >> with: >> (...) >> >> synchronized: >> (...) >> >> try: >> (...) >> >> transaction: >> (...) >> >> Do you understand my concern? It would be very, very hard to discern >> these "user-defined statements" from real language constructs. > > I think part of the debate is about whether that's good or bad. > I happen to agree with you -- i think a keyword is necessary -- > but i believe some people see an advantage in having the flexibility > to make a "real-looking" construct. Yes. But it would only be crippled, as the "keyword" would have to be a pre-constructed generator instance which cannot be easily reused as a library export (at least, it is not intended this way). > As i see it the argument boils down to: Python is not Lisp. > > There are good reasons why the language has keywords, why it > distinguishes statements from expressions, uses indentation, and > so on. All of these properties cause Python programs to be made > of familiar and easily recognizable patterns instead of degenerating > into a homogeneous pile of syntax. Big ACK. Reinhold -- Mail address is perfectly valid! ___ 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 -- loose ends
Reinhold Birkenfeld wrote:
> Noam Raphael wrote:
>
>>On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>>resource = opening("file.txt")
>>>resource:
>>>(...)
>>>
>>>The latter would have to be forbidden.
>>
>>Can you explain why it would have to be forbidden please?
>
>
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
> [...]
>
> transaction:
> (...)
>
>
> Do you understand my concern? It would be very, very hard to discern
> these "user-defined statements" from real language constructs.
For each block statement, it is necessary to create a *new* iterator,
since iterators that have stopped are required to stay stopped. So at a
minimum, used-defined statements will need to call something, and thus
will have parentheses. The parentheses might be enough to make block
statements not look like built-in keywords.
PEP 340 seems to punish people for avoiding the parentheses:
transaction = begin_transaction()
transaction:
db.execute('insert 3 into mytable')
transaction:
db.execute('insert 4 into mytable')
I expect that only '3' would be inserted in mytable. The second use of
the transaction iterator will immediately raise StopIteration.
Shane
___
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 -- loose ends
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might be enough to make block
> statements not look like built-in keywords.
>
> PEP 340 seems to punish people for avoiding the parentheses:
>
> transaction = begin_transaction()
>
> transaction:
> db.execute('insert 3 into mytable')
>
> transaction:
> db.execute('insert 4 into mytable')
>
> I expect that only '3' would be inserted in mytable. The second use of
> the transaction iterator will immediately raise StopIteration.
Yes, but wouldn't you think that people would misunderstand it in this way?
Reinhold
--
Mail address is perfectly valid!
___
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
Guido van Rossum wrote: > Nice one. Should be a piece of cake to implement. Please talk to > [EMAIL PROTECTED] about getting it checked into the PEP database. > > I'm +1 on accepting this now -- anybody against? > I'm +1. A couple of us discussed this at PyCon during the last day of the sprints and we all thought that it could be done, but none of us felt strong enough to write the PEP immediately. So thanks to Reinhold for picking up our slack. =) -Brett ___ 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
[Reinhold Birkenfeld] > ... > I think the behaviour of the "else" clause is much harder to guess, > mainly when used with the looping constructs. No, that's obvious . What about `else` mixed with try/except/finally? try: A except: B else: C finally: D If A executes without exception, does D execute before or after C? I'm not saying we can't make up reasonable answers. I'm saying they look more-or-less arbitrary, while the current nested forms are always clear. ___ 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 -- loose ends
Reinhold Birkenfeld wrote:
> Shane Hathaway wrote:
>
>
>>For each block statement, it is necessary to create a *new* iterator,
>
>
> Right.
>
>
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
>>will have parentheses. The parentheses might be enough to make block
>>statements not look like built-in keywords.
>>
>>PEP 340 seems to punish people for avoiding the parentheses:
>>
>>transaction = begin_transaction()
>>
>>transaction:
>>db.execute('insert 3 into mytable')
>>
>>transaction:
>>db.execute('insert 4 into mytable')
>>
>>I expect that only '3' would be inserted in mytable. The second use of
>>the transaction iterator will immediately raise StopIteration.
>
>
> Yes, but wouldn't you think that people would misunderstand it in this way?
Yes, they might. Just to be clear, the risk is that people will try to
write statements without parentheses and get burned because their code
doesn't get executed, right?
A possible workaround is to identify iterators that have already
finished. StopIteration doesn't distinguish between an iterator that
never yields any values from an iterator that has yielded all of its
values. Maybe there should be a subclass of StopIteration like
"AlreadyStoppedIteration". Then, if a block statement gets an
AlreadyStoppedIteration exception from its iterator, it should convert
that to an error like "InvalidBlockError".
Shane
___
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: propose to get rid of 'as' keyword
On Wed, 2005-05-04 at 13:08 -0600, Shane Hathaway wrote: > Gustavo J. A. M. Carneiro wrote: > > In PEP 340 I read: > > > > block EXPR1 as VAR1: > > BLOCK1 > > > > I think it would be much clearer this (plus you save one keyword): > > > > block VAR1 = EXPR1: > > BLOCK1 > > I think you misunderstood the statement. EXPR1 creates an iterator, > then VAR1 iterates over the values returns by the iterator. VAR1 never > sees the iterator. Using your syntax would reinforce the > misinterpretation that VAR1 sees the iterator. In that case, block VAR1 in EXPR1: BLOCK1 And now I see how using 'for' statements (perhaps slightly changed) turned up in the discussion. Sorry for the noise. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ 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
Tim> What about `else` mixed with try/except/finally? Tim> try: Tim> A Tim> except: Tim> B Tim> else: Tim> C Tim> finally: Tim> D Tim> If A executes without exception, does D execute before or after C? According to Guido, execution is A, C, D in the normal case and A, B, D in the exceptional case. Execution never jumps back. Tim> I'm not saying we can't make up reasonable answers. I'm saying Tim> they look more-or-less arbitrary, while the current nested forms Tim> are always clear. As far as arbitrary answers go, execution only in the forward direction seems more reasonable than jumping forward and back. Skip ___ 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
Tim Peters wrote: > [Reinhold Birkenfeld] >> ... >> I think the behaviour of the "else" clause is much harder to guess, >> mainly when used with the looping constructs. > > No, that's obvious . OK, I'm persuaded. Well you wield the Force, master. > What about `else` mixed with try/except/finally? > > try: > A > except: > B > else: > C > finally: > D > > If A executes without exception, does D execute before or after C? Given the order of the clauses, is it so ambiguous? Reinhold -- Mail address is perfectly valid! ___ 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: Breaking out.
On Wed, May 04, 2005, Paul Moore wrote: > > Yes, that'd do. I can't say I think it would be common, but it's a > valid case. And the workaround is the usual messy flag variable: > > for name in filenames: > found = False > opening(name) as f: > if f.read(2) == 0xFEB0: found = True > if found: break My standard workaround is using exceptions, but I'm not sure how that interacts with a block: try: for name in filenames: with opened(name) as f: if f.read(2) == 0xFEB0: raise Found except Found: pass -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It's 106 miles to Chicago. We have a full tank of gas, a half-pack of cigarettes, it's dark, and we're wearing sunglasses." "Hit it." ___ 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 -- loose ends
[ Reinhold Birkenfeld ]: > Well, with it you could create suites with _any_ introducing > identifier. Consider: > > with: > (...) > > synchronized: > (...) > > try: > (...) > > transaction: > (...) > > > Do you understand my concern? I definetely see your point. However,... > It would be very, very hard to discern > these "user-defined statements" from real language constructs. - today it is hard to distinguish a user-defined function from a builtin function. What is the problem with the former (anonymous blocks) that is accepted for the later (functions). I guess the solution is the same for both: documentation. - 'try' would probably be an invalid identifier/expression in a block, as well as any other reserved words. So no confusion arises from '''try:''' nor '''while''' nor '''for''' nor '''except''' etc [ Ka-Ping Yee ]: > My point is There are good reasons why the language has keywords, why it > distinguishes statements from expressions, uses indentation, and > so on. All of these properties cause Python programs to be made > of familiar and easily recognizable patterns instead of degenerating > into a homogeneous pile of syntax. I am completely in favour of preserving Python's readability and simplicity. But metaclasses and decorators introduced opportunities for some magical spells. Either you know their definition and how they modify its subjects or your code understanding might be harmed to a certain degree. They were born without being baptized with a keyword, why should blocks ? I think that the absence of 'name clashing', alone, is the strong argument in favour of the __no keyword__ proposal. Recognizing a __no keyword__ block would be very easy. If you did not recognize it as something you already knew, then it was a block <0.2 wink>. best regards, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.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] PEP 340: Breaking out.
Aahz wrote: > On Wed, May 04, 2005, Paul Moore wrote: >> >> Yes, that'd do. I can't say I think it would be common, but it's a >> valid case. And the workaround is the usual messy flag variable: >> >> for name in filenames: >> found = False >> opening(name) as f: >> if f.read(2) == 0xFEB0: found = True >> if found: break > > My standard workaround is using exceptions, but I'm not sure how that > interacts with a block: > > try: > for name in filenames: > with opened(name) as f: > if f.read(2) == 0xFEB0: > raise Found > except Found: > pass >From a naive point of view, it should definitely work as expected. >From the PEP point of view, no clue. *hope* Reinhold -- Mail address is perfectly valid! ___ 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] Py_UNICODE madness
Nicholas Bastin wrote: > That makes PyUnicode_FromUnicode() a lot less useful. Well, really, > not useful at all. Why do you say that? Py_UNICODE is as good a type to store characters as any other, and if you happen to have a Py_UNICODE[], you can use that function to build a unicode object. > You might suggest that PyUnicode_FromWideChar is more useful, but > that's only true on platforms that support wchar_t. Useful to do what? PyInt_FromLong isn't useful if you have a void*, either... > Is there no universally supported way of moving buffers of unicode data > (as common data types, like unsigned short, etc.) into Python from C? There is no common Unicode type in C, period (be it Python or not). Your best bet is to prepare a Py_UNICODE[], either by copying from your favourite Unicode type, or by casting it, e.g. #if Py_UNICODE_IS_AS_WIDE_AS_MY_UNICODE_TYPE Py_UNICODE* data = (Py_UNICODE*) my_data; do_free=0; #else Py_UNICODE* data = malloc(sizeof(Py_UNICODE)*my_data_len); for(int i=0;i<=my_data_len) data[i] = my_data[i]; do_free=1; #endif PyObject *uni = PyUnicode_FromUnicode(data); if(do_free)free(data); 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
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 type on > any given platform." But people want to know "Is Python's Unicode 16-bit or 32-bit?" So the documentation should explicitly say "it depends". 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
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 type on >>any given platform." > > > But people want to know "Is Python's Unicode 16-bit or 32-bit?" > So the documentation should explicitly say "it depends". On a related note, it would be help if the documentation provided a little more background on unicode encoding. Specifically, that UCS-2 is not the same as UTF-16, even though they're both two bytes wide and most of the characters are the same. UTF-16 can encode 4 byte characters, while UCS-2 can't. A Py_UNICODE is either UCS-2 or UCS-4. It took me quite some time to figure that out so I could produce a patch [1]_ for PyXPCOM that fixes its unicode support. .. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=281156 Shane ___ 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
And per the PEP, I think the explaining that:: try: A except: B else: C finally: D is *exactly* equivalent to:: try: try: A except: B else: C finally: D Resolved all the questions about control flow for me. Well, assuming that implementation makes the explanation truth. ;) ___ 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] Need to hook Py_FatalError
Hi, Added the patch to the patch manager on SF. Best regards. ___ 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 -- concept clarification
Nick Coghlan wrote: > Ah, someone else did post this idea first :) I knew I was standing on the shoulders of others :) > To deal with the generator issue, one option would be to follow up on > Phillip's idea of a decorator to convert a generator (or perhaps any > standard iterator) into a block iterator. > > I think this would also do wonders for emphasising the difference > between for loops and block statements. I think if we are going to emphasise the difference, a decorator does not go far enough. To use a decorator, this *must* be valid syntax:: def gen(): try: yield finally: print 'Done!' However, that generator cannot be properly used in a for-loop. So it's only realistically valid with the decorator, and used in a block statement (resource suite ;) My feeling is that the above should be a SyntaxError, as it currently is, and that a new keyword is needed which explicitly allows the above, and creates an object conforming to the resource protocal (as I called it). 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
Re: [Python-Dev] PEP 340 -- loose ends
Shane Hathaway wrote: > For each block statement, it is necessary to create a *new* iterator, > since iterators that have stopped are required to stay stopped. So at a > minimum, used-defined statements will need to call something, and thus > will have parentheses. The parentheses might be enough to make block > statements not look like built-in keywords. Definitely true for generators. Not necessarily true for iterators in general:: class Example(object): value = 0 result = False def __iter__(self): return self def next(self): self.result = not self.result if self.result: self.value += 1 return self.value else: raise StopIteration() :: >>> e = Example() >>> list(e) [1] >>> list(e) [2] >>> list(e) [3] It might actually be workable in the transaction scenario, as well as others. I'm not sure if I love or hate the idea though. Another thing. In the specification of the Anonymous Block function, is there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"? It seems to be a dis-symmetry with the 'for' loop specification. Thanks, -Shane (Holloway) ;) ___ 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: Breaking out.
Aahz wrote: > My standard workaround is using exceptions, but I'm not sure how that > interacts with a block: > > try: > for name in filenames: > with opened(name) as f: > if f.read(2) == 0xFEB0: > raise Found > except Found: > pass For any sane block iterator, it will work as expected. However, an evil block iterator could suppress the `Found` exception. A sane block iterator should re-raise the original exception. 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
Re: [Python-Dev] PEP 340 -- loose ends
I'm forced by my day job to temporarily withdraw from the discussion about PEP 340 (I've used up my Python quota for the next several weeks). If agreement is reached in python-dev to suggest specific changes to the PEP, please let me know via mail sent directly to me and not cc'ed to python-dev. But please only if there is broad agreement on something. -- --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] Pre-PEP: Unifying try-except and try-finally
[Shane Holloway] > And per the PEP, I think the explaining that:: > > try: > A > except: > B > else: > C > finally: > D > > is *exactly* equivalent to:: > > try: > try: > A > except: > B > else: > C > finally: > D > > Resolved all the questions about control flow for me. Well, assuming > that implementation makes the explanation truth. ;) Yup! It's not unreasonable to abbreviate it, but the second form is obvious on the face of it, and can already be written. I'm neutral on adding the slightly muddier shortcut. ___ 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] Adding DBL_MANTISSA and such to Python
Recently I needed some information about the floating point numbers on
my machine. So I wrote a tiny C99 program with the line
printf("%a\n", DBL_EPSILON);
The answer was "0x1p-52".
A search of comp.lang.python shows that I was not alone. Here are some
ideas.
1. Add to Python the constants in "float.h" and "limits.h".
2. Add the C99 "%a" format to the "%" operator for strings and allow it
in floating point literals.
3. Add full "tostring" and "fromstring" capabilities for Python numeric
types. "tostring(x)" would return a string containing the binary
representation of x. For example, if x is a Python float, "tostring(x)"
would have eight characters. "fromstring(s, atype)" does the reserve, so
fromstring(tostring(x), type(x)) == x
4. Add some functions that process floating point types at a low level.
I suggest borrowing from C
(mantissa, exponent) = frexp(x)
where mantissa is a float and exponent is an int. The mantissa can be
0.0 or 0.5 <= mantissa < 1.0. Also x = mamtissa * 2**exponent. If
x == 0.0, the function returns (0.0, 0). (This is almost a quote from
Harbison and Steele.)
5. Add the C99 constants and functions involving special floating point
values: "FP_INFINITE", "FP_NAN", "FP_NORMAL", "FP_SUBNORMAL", "FP_ZERO",
"fpclassify", "isfinite", "isinf", "isnan", "isnormal", "signbit",
"copysign", "nan", "nextafter", and "nexttoward". There has been
controversy about these in the past, but I am in favor of them. The
documentation should discuss portability.
___
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 -- loose ends
Shane Hathaway wrote: > For each block statement, it is necessary to create a *new* iterator, > since iterators that have stopped are required to stay stopped. So at a > minimum, used-defined statements will need to call something, and thus > will have parentheses. Not necessarily! class Frobbing: def __neg__(self): begin_frobbing() try: yield finally: end_frobbing() frobbing = Frobbing() ... -frobbing: do_something() -- 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 -- loose ends
Shane Holloway (IEEE) wrote: > Another thing. In the specification of the Anonymous Block function, is > there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"? It > seems to be a dis-symmetry with the 'for' loop specification. Hmm... yeah. That's strange. In fact, if it gets changed to "itr = iter(EXPR1)", as it probably ought to, all of the existing examples will continue to work. It will also be safe to start block iterators with a single variable, nullifying my argument about parentheses. So Reinhold's examples stand, except for the "try" block, since it clashes with a keyword. They read well, but when something goes wrong in the code, how would a new programmer crack these nuts? with: (...) synchronized: (...) transaction: (...) > Thanks, > -Shane (Holloway) ;) Once in a while I read a post by Shane Hway and start wondering when I wrote it and how I could've forgotten about it. And then I realize I didn't. :-) Shane ___ 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: Only for try/finally?
BJörn Lindqvist wrote: > But why stop there? Lots of functions that takes a callable as > argument could be upgraded to use the new block syntax. Actually, this is something that occurred to me in potential support of a thunk implementation: It's possible that many functions already out there which take function arguments could *already* be used with a thunk-based block statement, without needing to be re-written at all. -- 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 -- loose ends
Greg Ewing wrote: > Shane Hathaway wrote: > >>For each block statement, it is necessary to create a *new* iterator, >>since iterators that have stopped are required to stay stopped. So at a >>minimum, used-defined statements will need to call something, and thus >>will have parentheses. > > > Not necessarily! > >class Frobbing: > > def __neg__(self): >begin_frobbing() >try: > yield >finally: > end_frobbing() > >frobbing = Frobbing() > >... > >-frobbing: > do_something() Larry Wall would hire you in a heartbeat. ;-) Maybe there's really no way to prevent people from writing cute but obscure block statements. A keyword like "block" or "suite" would give the reader something firm to hold on to. Shane ___ 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] PEP 340 -- Clayton's keyword?
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) The 'statement' statement declares to the parser that an identifier is to be treated as a keyword introducing a block statement when it appears as the first token in a statement. This would allow keywordless block-statements that look very similar to built-in statements, without any danger of forgetting to make a function call, since a call would be implicit in all such block-statements. A 'statement' declaration would be needed in all modules which use the generator, e.g. statement opening from filestuff import opening For convenience, this could be abbreviated to from filestuff import statement opening There could also be an abbreviation def statement opening(...): ... for when you're defining and using it in the same module. Sufficiently smart editors would understand the 'statement' declarations and highlight accordingly, making these user-defined statements look even more like the native ones. -- 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 -- Clayton's keyword?
+1 This is awesome. BTW, did we totally abandon the question of using block: as RHS? jb On May 5, 2005, at 12:12 AM, Greg Ewing wrote: > 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) > > The 'statement' statement declares to the parser that an > identifier is to be treated as a keyword introducing a > block statement when it appears as the first token in a > statement. > > This would allow keywordless block-statements that look > very similar to built-in statements, without any danger of > forgetting to make a function call, since a call would > be implicit in all such block-statements. > > A 'statement' declaration would be needed in all modules > which use the generator, e.g. > >statement opening >from filestuff import opening > > For convenience, this could be abbreviated to > >from filestuff import statement opening > > There could also be an abbreviation > >def statement opening(...): > ... > > for when you're defining and using it in the same module. > > Sufficiently smart editors would understand the 'statement' > declarations and highlight accordingly, making these > user-defined statements look even more like the native > ones. > > -- > 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/jbone > %40place.org > ___ 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] [OT] Re: PEP 340 -- Clayton's keyword?
Just a little offtopic note to Jeff Bone: Jeff, every time I send a message to Python-Dev, your "Mail.app 2.0" sends me a nasty auto-reply that I can't quote in public. Please stop. Since I can't seem to reach you by email, I'm trying to reach you through this mailing list. The note refers to something about "Shantar"; maybe that will help you figure out what's wrong. Shane ___ 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] Adding DBL_MANTISSA and such to Python
Edward C. Jones wrote: > The documentation should discuss portability. This is the critical issue here. Discussing portability is not enough; these features really ought to be either available on a majority of the installations, or not available at all. In particular, they would need to be available on Windows. I haven't check whether VC 7.1 provides them, and if it doesn't, somebody would have to provide a "direct" implementation. I'd say "contributions are welcome". 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
