Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary
Igor Bukanov wrote: > This example also suggests how to fix generators. One just need to > change the close method so it would cause return executed right after > the yield instead of throw. > > I.e. replace the current text from > http://www.python.org/dev/peps/pep-0342/ > by simpler one: Simpler is in the eye of the beholder - the current close() merely uses throw() to raise a particular kind of exception 'asynchronously' (which is already a familiar concept due to KeyboardInterrupt). What you're suggesting is a completely new flow control concept that doesn't exist anywhere else in the language. I suggested during the PEP 352 discussions that GeneratorExit should inherit directly from BaseException, so that the fix to your example would be to replace the bare "except:" with "except Exception:" (because it can swallow KeyboardInterrupt the version you posted is buggy regardless of how g.close() works). Guido didn't like that idea [1], so the correct way to write your exception handler is to either explicitly catch & reraise GeneratorExit before doing a general "except Exception:" catch-all clause, or to do the yield outside the try-except clause (but inside the try-finally) (obviously, this makes more sense when what you're yielding is an expression rather than a single variable). I think Guido is correct that GeneratorExit should be a normal exception from a technical point of view (as GE should never reach the outer layers of a program), but I also believe it is going to be a PITA from a practical point of view because I think the natural way of writing a generator with exception handling is to include the yield inside the try/except block instead of storing the result in a variable and yielding afterwards. However, since the status quo is the result of BDFL preference, it's going to be up to Guido as to whether or not he considers this enough of a potential pain to change his mind. As there isn't actually any new evidence here (it's all still hypothetical), I don't really expect that to happen :) That said, with the PEP 342 implementation now being a bit more mature, I am curious as to exactly *how* GeneratorExit is supposed to leak out of code that was supposed to catch it (which was Guido's main concern at the time he decided that GE should remain a normal Exception). GeneratorExit really shouldn't be getting raised by anything other than g.close(), which takes great pains to ensure that the exception gets handled correctly (and if it *doesn't* get handled correctly, the resulting exception that reports that fact is a RuntimeError, not GeneratorExit). > This not only fixes the above discrepancy between normal flow control > and generators, removes GeneratorExit and simplifies the generator > protocol, but also bring a new feature allowing to have easy to grasp > feature table of the iterator methods: > > next: continue after yield This isn't right, though. next()/send() just resume execution after a yield. They are only equivalent to continue if the yield is at the end of a loop body. > throw: raise after yield > close: return after yield In the current implementation, close is just a special case of throw (g.throw(GeneratorExit)), the same as next() is just a special case of send (g.send(None)). 2 concepts to understand (send(), throw()) is simpler to my mind than 3 (send(), throw(), close()). Cheers, Nick. [1] http://mail.python.org/pipermail/python-dev/2006-March/062825.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
Re: [Python-Dev] String formatting / unicode 2.5 bug?
John J Lee wrote:
> On Mon, 21 Aug 2006, Nick Coghlan wrote:
>
>> John J Lee wrote:
And once the result has been promoted to unicode, __unicode__ is used
directly:
>>> print repr("%s%s" % (a(), a()))
__str__
accessing <__main__.a object at 0x00AF66F0>.__unicode__
__str__
accessing <__main__.a object at 0x00AF6390>.__unicode__
__str__
u'hihi'
>>> I don't understand this part. Why is __unicode__ called? Your example
>>> doesn't appear to show this happening "once [i.e., because?] the result has
>>> been promoted to unicode" -- if that were true, it would "stand to reason"
>>> that the interpreter would then conclude it should call
>>> __unicode__ for all remaining %s, and not bother with __str__.
>> It does try to call unicode directly, but because the example object doesn't
>> supply __unicode__ it ends up falling back to __str__ instead. The behaviour
>> is clearer when the example object provides both methods:
> [...]
>
> If the interpreter is falling back from __unicode__ to __str__ (rather
> than the other way around, kind-of), that makes much more sense. I
> understood that __unicode__ was not provided, of course -- what wasn't
> clear to me was why the interpreter was calling/accessing those
> methods/attributes in the sequence it does. Still not sure I understand
> what the third __str__ above comes from, but until I've thought it through
> again, that's my problem.
The sequence is effectively:
x, y = a(), a()
str(x) # calls x.__str__
unicode(x) # tries x.__unicode__, fails, falls back to x.__str__
unicode(y) # tries y.__unicode__, fails, falls back to y.__str__
The trick in 2.5 is that the '%s' format code, instead of actually calling
str(x), calls x.__str__() directly, and promotes the result to Unicode if
x.__str__() returns a Unicode result.
I'll try to do something to clear up that section of the documentation before
2.5 final.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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
Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary
This discussion probably happens as a result of attempts to copy Python's design in JavaScript. I propose that JavaScript do whatever it wants and its developers leave Python alone -- maybe some time in the future we'll be able to compare the two approaches. I think it's impossible to do so at the moment. --Guido On 8/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Igor Bukanov wrote: > > This example also suggests how to fix generators. One just need to > > change the close method so it would cause return executed right after > > the yield instead of throw. > > > > I.e. replace the current text from > > http://www.python.org/dev/peps/pep-0342/ > > > > by simpler one: > > > Simpler is in the eye of the beholder - the current close() merely uses > throw() to raise a particular kind of exception 'asynchronously' (which is > already a familiar concept due to KeyboardInterrupt). What you're suggesting > is a completely new flow control concept that doesn't exist anywhere else in > the language. > > I suggested during the PEP 352 discussions that GeneratorExit should inherit > directly from BaseException, so that the fix to your example would be to > replace the bare "except:" with "except Exception:" (because it can swallow > KeyboardInterrupt the version you posted is buggy regardless of how g.close() > works). > > Guido didn't like that idea [1], so the correct way to write your exception > handler is to either explicitly catch & reraise GeneratorExit before doing a > general "except Exception:" catch-all clause, or to do the yield outside the > try-except clause (but inside the try-finally) (obviously, this makes more > sense when what you're yielding is an expression rather than a single > variable). > > I think Guido is correct that GeneratorExit should be a normal exception from > a technical point of view (as GE should never reach the outer layers of a > program), but I also believe it is going to be a PITA from a practical point > of view because I think the natural way of writing a generator with exception > handling is to include the yield inside the try/except block instead of > storing the result in a variable and yielding afterwards. > > However, since the status quo is the result of BDFL preference, it's going to > be up to Guido as to whether or not he considers this enough of a potential > pain to change his mind. As there isn't actually any new evidence here (it's > all still hypothetical), I don't really expect that to happen :) > > That said, with the PEP 342 implementation now being a bit more mature, I am > curious as to exactly *how* GeneratorExit is supposed to leak out of code that > was supposed to catch it (which was Guido's main concern at the time he > decided that GE should remain a normal Exception). GeneratorExit really > shouldn't be getting raised by anything other than g.close(), which takes > great pains to ensure that the exception gets handled correctly (and if it > *doesn't* get handled correctly, the resulting exception that reports that > fact is a RuntimeError, not GeneratorExit). > > > This not only fixes the above discrepancy between normal flow control > > and generators, removes GeneratorExit and simplifies the generator > > protocol, but also bring a new feature allowing to have easy to grasp > > feature table of the iterator methods: > > > > next: continue after yield > > This isn't right, though. next()/send() just resume execution after a yield. > They are only equivalent to continue if the yield is at the end of a loop > body. > > > throw: raise after yield > > close: return after yield > > In the current implementation, close is just a special case of throw > (g.throw(GeneratorExit)), the same as next() is just a special case of send > (g.send(None)). > > 2 concepts to understand (send(), throw()) is simpler to my mind than 3 > (send(), throw(), close()). > > Cheers, > Nick. > > [1] http://mail.python.org/pipermail/python-dev/2006-March/062825.html > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > 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
Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary
I rather like it, actually. I don't recall there being any real reasons to catch a GeneratorExit exception, but even if there were, you could do the equivalent like this: try: closed = True yield 1 closed = False finally: if closed: # special closing code Unfortunately, this is a pretty major change to be making to the specification (PEP 342) when we've just released 2.5c1; it seems like something that requires at least a beta release. But aside from that, it seems like a fairly neat solution to the problem. I'd like to hear from Jython and IronPython representatives regarding implementability for those platforms, though. Our original assumption was that if they could implement throw() then they could clearly implement close(), since close() was defined in terms of throw(). An asynchronous return might be another matter. But if that hurdle is crossable, then I agree that modelling close() as an early return is more intuitive, eliminates a built-in exception, etc. At 03:17 PM 8/22/2006 +0200, Igor Bukanov wrote: >Consider the following example: > >for i in range(3): > try: > print i > break > except: > print "Unexpected exception!" > finally: > print "Finally" > >When executed, it naturally prints > 0 > Finally >since break does not use exceptions to transfer the control and as >such can not be stopped using catch-all exception handler. > >Now consider a similar example using generators: > >def gen(): > for i in range(3): > try: > yield i > except: > print "Unexpected exception!" > finally: > print "Finally" > >for i in gen(): > print i > break > >This example prints: > 0 > Unexpected exception! > Finally > Exception exceptions.RuntimeError: 'generator ignored GeneratorExit' >in ignored > >Suddenly with generators a program can mess with control transfer >since it uses explicit GeneratorExit which can be caught and ignored. >This is unintuitive IMO. > >This example also suggests how to fix generators. One just need to >change the close method so it would cause return executed right after >the yield instead of throw. > >I.e. replace the current text from >http://www.python.org/dev/peps/pep-0342/ > >4. Add a close() method for generator-iterators, which raises >GeneratorExit at the point where the generator was paused. If the >generator then raises StopIteration (by exiting normally, or due to >already being closed) or GeneratorExit (by not catching the >exception), close() returns to its caller. If the generator yields a >value, a RuntimeError is raised. If the generator raises any other >exception, it is propagated to the caller. close() does nothing if the >generator has already exited due to an exception or normal exit. > >by simpler one: > >4. Add a close() method for generator-iterators, which executes normal >return at the point where the generator was paused. If the generator >then raises StopIteration (by exiting normally, or due to already >being closed), close() returns to its caller. If the generator yields >a value, a RuntimeError is raised. If the generator raises any other >exception, it is propagated to the caller. close() does nothing if the >generator has already exited due to an exception or normal exit. > >This not only fixes the above discrepancy between normal flow control >and generators, removes GeneratorExit and simplifies the generator >protocol, but also bring a new feature allowing to have easy to grasp >feature table of the iterator methods: > >next: continue after yield >throw: raise after yield >close: return after yield > >Regards, Igor >___ >Python-Dev mailing list >[email protected] >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.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
[Python-Dev] Python + Java Integration
This may seem like it's coming out of left field for a minute, but bear with me. There is no doubt that Ruby's success is a concern for anyone who sees it as diminishing Python's status. One of the reasons for Ruby's success is certainly the notion (originally advocated by Bruce Tate, if I'm not mistaken) that it is the "next Java" -- the language and environment that mainstream Java developers are, or will, look to as a natural next step. One thing that would help Python in this "debate" (or, perhaps simply put it in the running, at least as a "next Java" candidate) would be if Python had an easier migration path for Java developers that currently rely upon various third-party libraries. The wealth of third-party libraries available for Java has always been one of its great strengths. Ergo, if Python had an easy-to-use, recommended way to use those libraries within the Python environment, that would be a significant advantage to present to Java developers and those who would choose Ruby over Java. Platform compatibility is always a huge motivator for those looking to migrate or upgrade. In that vein, I would point to JPype (http://jpype.sourceforge.net). JPype is a module that gives "python programs full access to java class libraries". My suggestion would be to either: (a) include JPype in the standard library, or barring that, (b) make a very strong push to support JPype (a) might be difficult or cumbersome technically, as JPype does need to build against Java headers, which may or may not be possible given the way that Python is distributed, etc. However, (b) is very feasible. I can't really say what "supporting JPype" means exactly -- maybe GvR and/or other heavyweights in the Python community make public statements regarding its existence and functionality, maybe JPype gets a strong mention or placement on python.orgall those details are obviously not up to me, and I don't know the workings of the "official" Python organizations enough to make serious suggestions. Regardless of the form of support, I think raising people's awareness of JPype and what it adds to the Python environment would be a Good Thing (tm). For our part, we've used JPype to make PDFTextStream (our previously Java-only PDF text extraction library) available and supported for Python. You can read some about it here: http://snowtide.com/PDFTextStream.Python And I've blogged about how PDFTextStream.Python came about, and how we worked with Steve Ménard, the maintainer of JPype, to make it all happen (watch out for this URL wrapping): http://blog.snowtide.com/2006/08/21/working-together-pythonjava-open- sourcecommercial Cheers, Chas Emerick Founder, Snowtide Informatics Systems Enterprise-class PDF content extraction [EMAIL PROTECTED] http://snowtide.com | +1 413.519.6365 ___ 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] [4suite] cDomlette deallocation bug?
I'm CC python-dev as this may be a bug in the gc module. Although this may be
more of a c.l.p. post, I think that this usage shouldn't cause segfaults
regardless.
On Tuesday 22 August 2006 3:06 pm, Robert Fleming wrote:
> [step 1 unnecessary]
> 2. test program (test.c):
> / snip /
> #include
>
> #include
>
> int main(int argc, char* argv[])
> {
> int i;
> for (i = 0; i<10; i++)
> {
> printf("%d\n", i);
>
> Py_Initialize();
> (void)PyRun_SimpleString("import sys\n"
>"sys.path.append('.')\n"
>"import cDomlettec");
Change the string to just "import gc" and the segfault still happens.
> Py_Finalize();
> }
>
> return EXIT_SUCCESS;
> }
> /** snip /
>
> 3. compile with:
> gcc -I/usr/include/python2.4 test.c -lpython2.4
>
> 4. run program; output is:
> 0
> 1
> Segmentation fault
>
> Am I doing something wrong? I'm pretty new to embedding Python, but I'm
> hoping to be able to cleanly load and unload 4Suite this way
It just so happens that cDomlettec imports gc internally which, by the change
above shows, causes the segfault. Hopefully someone with more knowledge of
GC internals can comment on this.
--
Jeremy Kloth
http://4suite.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
Re: [Python-Dev] ctypes and win64
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> I suggest that it [the ctypes package] should be removed from the 2.5 win64 >> msi installers, so that >> at least, when it is ready, can be installed as separate package. > > Unfortunately, I won't be able to work on this until the release is > made. Feel free to work on it, but I suggest to just not worry about > it. Patch for Tools\msi\msi.py uploaded, and assigned to you. http://python.org/sf/1545507 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
[Python-Dev] Can LOAD_GLOBAL be optimized to a simple array lookup?
Hi all, I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup, and was wondering if that can be optimized to a simple array lookup. If i'm right there are 3 kinds of name lookups: locals, outer scopes(closures), and globals. (not counting attribute lookup). Locals are identified by, either the presence of assignments, or their presence in the arg list. So all name lookups can be classified into the 3 types at compile/load time. Since we know, at load time, which names are global.. Can't we simply build a global name table and replace LOAD_GLOBALs with a lookup at the corresponding index into the global name table? The module's dict object will need to be special so that whenever a name gets 'set', the global name table should get updated. Is this optimization possible or have i missed something? cheers [sreeram;] signature.asc Description: OpenPGP digital 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] Python + Java Integration
"Chas Emerick" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >One thing that would help Python in this "debate" In general, discussion of promoting/marketing python is more a topic for comp.lang.python than for this list. Also see below. >My suggestion would be to either: >(a) include JPype in the standard library, or barring that, Externally developed modules become part of the standard library by becoming sufficiently 'widely' tested and used in the Python community. One means for this is announcement and discussion in c.l.p. That and technical considerations aside, this strikes me as one of several specialized 'bridge' tools, none of which should be in that standard lib but all of which should be listed and accessible in the Python Package Index. >(b) make a very strong push to support JPype We are mostly all volunteers here. Go ahead and scratch this itch if you want. If it does not yet already, I would agree that python.org should have a page on bridging between Python and other languages (not just Java, though). C.l.py would be a place to discuss the idea and collect suggestions for inclusion on such a page >For our part, we've used JPype to make PDFTextStream (our previously >Java-only PDF text extraction library) available and supported for Python. Success strories that provide new information are welcome on c.l.py. Perhaps a couple of paragraphs summarizing the content that you link to. Terry Jan Reedy ___ 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] Can LOAD_GLOBAL be optimized to a simple array lookup?
On 8/23/06, K.S.Sreeram <[EMAIL PROTECTED]> wrote: Hi all,I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,and was wondering if that can be optimized to a simple array lookup.No, not as the language stands now. If i'm right there are 3 kinds of name lookups: locals, outerscopes(closures), and globals. (not counting attribute lookup). Locals are identified by, either the presence of assignments, or their presencein the arg list. So all name lookups can be classified into the 3 typesat compile/load time.Since we know, at load time, which names are global.. Can't we simply build a global name table and replace LOAD_GLOBALs with a lookup at thecorresponding index into the global name table?But we don't know statically what the globals will be. You can import a module and put something in its global namespace externally. That is done after load time or compile time. -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
[Python-Dev] [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c
Since Alex isn't on python-dev, forwarding this for his convenience (he said he wanted to reply.) Tim also replied to his checkin, but I didn't forward that message.-- Forwarded message --
From: Thomas Wouters <[EMAIL PROTECTED]>Date: Aug 24, 2006 12:16 AMSubject: Re: [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c
To: "alex. martelli" <[EMAIL PROTECTED]>On 8/23/06,
alex.martelli <[EMAIL PROTECTED]> wrote:
--- python/trunk/Objects/floatobject.c (original)+++ python/trunk/Objects/floatobject.c Wed Aug 23 22:42:02 2006@@ -821,12 +821,12 @@ix = pow(iv, iw);PyFPE_END_PROTECT(ix)Py_ADJUST_ERANGE1(ix);
- if (errno != 0) {+/* we need to ignore ERANGE here and just return inf */+ if (errno != 0 && errno != ERANGE) {/* We don't expect any errno value other than ERANGE, but
* the range of libm bugs appears unbounded. */- PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError :-PyExc_ValueError);
+ PyErr_SetFromErrno(PyExc_ValueError);return NULL;I don't think this can be right. The returnvalue of pow() in the case of ERANGE isn't defined anywhere that I can find, at least. How can we assume it is +Infinity? As I tried to say over the visiphone, you can't even use compile-time or startup-time checks for the behaviour because 'undefined' also means it need not be consistent, either. The best we could do, if we really wanted to return +inf instead of raising OverflowError (which I don't, but don't really care about either), is generate +Infinity in some guaranteed way. I'm sure Tim can come up with a convenient, portable way <
0.9 wink>.But I'd prefer to keep it the way it was: x*x and x**2 don't always do the same thing. Floats have a lot more confusing features like that, such as 10*x - 9*x need not be x. I don't see the added value of trying to make it consistent in just this case, even if it's portable.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] Can LOAD_GLOBAL be optimized to a simple array lookup?
On Aug 23, 2006, at 2:22 PM, K.S.Sreeram wrote: > Hi all, > > I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup, > and was wondering if that can be optimized to a simple array lookup. > > If i'm right there are 3 kinds of name lookups: locals, outer > scopes(closures), and globals. (not counting attribute lookup). Locals > are identified by, either the presence of assignments, or their > presence > in the arg list. So all name lookups can be classified into the 3 > types > at compile/load time. > > Since we know, at load time, which names are global.. Can't we simply > build a global name table and replace LOAD_GLOBALs with a lookup at > the > corresponding index into the global name table? At the time the function's body gets compiled, the global (or builtin) it's trying to access might or might not be there -- as long as it gets added afterwards, before the function's body gets _executed_, no problem (in today's scheme). It's not obvious to me how you could compile a ``corresponding index'' into the LOAD_GLOBAL opcode, since that index is in general unknown at compile time. > The module's dict object will need to be special so that whenever a > name > gets 'set', the global name table should get updated. It seems that you'd need to chase down and modify all of the LOAD_GLOBAL opcodes too, at every such modification. (the concept of modifying builtins becomes extremely scary...). Considering the amortized speed of a dict lookup for an interned string (hash value cached and thus immediately available, equality comparison with other interned string a single machine-level operation), it's not clear to me that the huge complexity (and potential performance impact) of all this could ever possibly be justified. A change in Python semantics allowing some level of "nailing down" of builtins (and perhaps globals too) *COULD* easily yield large performance benefits, but that's a subject for the Python-3000 mailing list; as long as builtins and globals stay as fluid as today, I'm skeptical on the optimization opportunities here. 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] Can LOAD_GLOBAL be optimized to a simple array lookup?
2006/8/24, Brett Cannon <[EMAIL PROTECTED]>: > > > > On 8/23/06, K.S.Sreeram <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup, > > and was wondering if that can be optimized to a simple array lookup. > > > No, not as the language stands now. > > > If i'm right there are 3 kinds of name lookups: locals, outer > > scopes(closures), and globals. (not counting attribute lookup). Locals > > are identified by, either the presence of assignments, or their presence > > in the arg list. So all name lookups can be classified into the 3 types > > at compile/load time. > > > > Since we know, at load time, which names are global.. Can't we simply > > build a global name table and replace LOAD_GLOBALs with a lookup at the > > corresponding index into the global name table? > > > But we don't know statically what the globals will be. You can import a > module and put something in its global namespace externally. That is done > after load time or compile time. > I think that it can be implemented for the language as it stands now. I don't know whether it will be a good thing or not. In principle, you can add a feature to dict implementation that will allow it to notify when the value of a specific key changes. If you have that, you can change LOAD_GLOBAL implementation to: 1. look for the global. 2. ask for notification when the global dict changes in a way that will change the meaning of the global. 3. change the LOAD_GLOBAL opcode to something like LOAD_CONST, and set the notification from the dict to update the LOAD_CONST opcode to the new object. In that way, LOAD_GLOBAL will cause a dict lookup only once. Changing the value of globals will require more work, though. Again, I'm not saying that it's desired, just that it's possible. Have a good day, 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
[Python-Dev] PEP 362 open issues
I have been spending my Google sprint time on writing and implementing PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally defines Signature objects for functions. With the implementation at a place I am happy with, I wanted to ask about the open issues with the PEP. The first question is whether to have Signature objects on all functions by default or to leave it in the 'inspect' module and have it be something totally optional. My vote is the latter for now and we can add them to all functions if they turn out to be useful and popular. The second open issue is how to handle binding arguments to tuple parameters for the Signature.bind() method. If you have the function ``def foo((a, b): pass``, how do you have the Signature.bind() method handle 'a', and 'b'? You can either take the proposed arguments and in the dict mapping arguments to parameters have an entry for 'a' and 'b' individually, or have an entry for '(a, (b,))'. My vote is the latter since you cannot address 'a' or 'b' individually as keyword arguments and this makes more sense with function annotations since they won't apply to 'a' and 'b' individually but instead to the entire tuple. Either way there is the issue of exhausting an iterator (like a generator) trying to find out if it is the proper length to unpack, for which I raise a TypeError instead of exhaust a possibly mutable iterator currently. -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] GeneratorExit is unintuitive and uneccessary
IIUC this is how return currently works -- in some sense it's an exception, but it can't be caught, and it won't escape from the current frame. Ditto for break/continue. The generator extensions are still very young, and I'm not against changing them somewhat in 2.6 or py3k. Perhaps GeneratorExit can be replaced by a treatment similar to the treatment of return. But I'm not sure it helps with the original problem; you could still put a yield in a finally clause that intercepts a return, just as today you can write def f(): for i in range(10): print i try: return finally: break print 999 where the finally clause nullifies the return. In a generator, a yield in the finally clause still needs to be dealt with somehow. On 8/23/06, Igor Bukanov <[EMAIL PROTECTED]> wrote: > On 8/23/06, Phillip J. Eby wrote: > > Our original > > assumption was that if they could implement throw() then they could clearly > > implement close(), since close() was defined in terms of throw(). An > > asynchronous return might be another matter. > > Such asynchronous return can always be implemented via a special > hidden exception that is invisible to catch statements. I.e an > implementation of generators can still use ___GeneratorExit > internally as long as it is not exposed to scripts. > > Regards, Igor > -- --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] [Python-checkins] r51525 - in python/trunk:Lib/test/test_float.py Objects/floatobject.c
Zitat von Tim Peters <[EMAIL PROTECTED]>: > Huh. It's been a (mildly controversial, but intentional all the same) > feature that Python tries to raise raise OverflowError on overflowing > libm operations. Doesn't work all that well, since there's no > consistency across platforms about when libm sets errno, or to what > (when it does). The other question is whether pow() is guaranteed to return inf when it sets errno to ERANGE; I believe there is no such guarantee. So I think the change should be reverted. 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] PEP 362 open issues
Brett Cannon wrote: > I have been spending my Google sprint time on writing and implementing > PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally > defines Signature objects for functions. With the implementation at a > place I am happy with, I wanted to ask about the open issues with the PEP. While reading the PEP, I stumbled over the description of the bind() method. As I understand the implementation patch, the parameter names will be keys and the arguments values in the resulting dictionary, but this sentence looks to me as if it describes it the opposite way (it also doesn't clarify that "parameter" means "parameter name"): * bind(*args, **kwargs) -> dict Create a mapping from argument to parameter for the signature (see `Open Issues`_ for question of how to handle tuples). Another question: could it be helpful to make Parameter.default_value a weak reference? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c
On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote:
>
> Since Alex isn't on python-dev, forwarding this for his convenience
> (he said he wanted to reply.)
Thanks! I _am_ on Python-Dev (otherwise couldn't read what you're
forwarding here), but not on Python-Checkins (where the discussion
was started).
> Tim also replied to his checkin, but I didn't forward that message.
Yep, saw that (thanks Brett) -- if I read him right, Tim was
basically suggesting better ways to check for infinity rather than
saying it's better to keep today's inconsistency (he can surely
correct me if I misread). Tim is of course right, but PEP 754 (the
fpconst module) would appear to be the right way to perform the
checking, anyway.
> I don't think this can be right. The returnvalue of pow() in the
> case of ERANGE isn't defined anywhere that I can find, at least.
> How can we assume it is +Infinity? As I tried to say over the
> visiphone, you can't even use compile-
That's how I read ISO/IEC 9899:1999 7.12.1.4 , which is describing
C's functions in general:
"""
If a floating result overflows and default rounding is in effect, or
if the mathematical result is an exact infinity (for example log
(0.0)), then the function returns the value of the macro HUGE_VAL,
HUGE_VALF, or HUGE_VALL according to the return type, with the same
sign as the correct value of the function;
"""
etc.
Yes, that's a C language standard that's just 7 years old, rather
than the 16-years-old standard Python can "definitely" count on; but
we could presumably test (and rely on) __STDC_IEC_559__ if we need
features in Appendix F, or just on __STDC_VERSION__ being defined and
>= 199901L for more generic parts of the standard (such as the part
I was quoting above from chapter 7). People who build Python with C
compilers not meeting these macro criteria but still "good enough" to
afford a minimally functional implementation of IEEE 754 floats might
run configure with some appropriate -with-whatever options to assert
the fact, if needed (i.e., if either because of C 1990 Standard
language, or realworld brokenness of important compilers, automatic
tests are in fact unreliable).
And PEP 754 (and thus fpconst, or some other way for Python code to
tell if it's running on a minimally functional implementation of IEEE
754 floats, and if so test for and generate NaNs and infinities)
should also be there so that the Python-coded unittests can properly
decide whether to test for compliance.
> time or startup-time checks for the behaviour because 'undefined'
> also means it need not be consistent, either. The
Yes, but the behavior is not undefined in standard C (1999 standard;
I don't have access to the 1990 standard)
> best we could do, if we really wanted to return +inf instead of
> raising OverflowError (which I don't, but don't really care about
> either), is generate +Infinity in some guaranteed way. I'm sure Tim
> can come up with a convenient, portable way < 0.9 wink>.
The macro Py_HUGE_VAL seems to be the documented way to do it. And
while I'd rather uniformly get infinity from operations producing
infinity, what I'm really keen to avoid is having one such operation
raise an exception while another one succeeds.
> But I'd prefer to keep it the way it was: x*x and x**2 don't always
> do the same thing. Floats have a lot more confusing features like
> that, such as 10*x - 9*x need not be x. I don't see the added value
> of trying to make it consistent in just this case, even if it's
> portable.
There's a huge conceptual gap between, on one side, two values
produced by "roughly equivalent" expressions being only *ALMOST*
equal rather than strictly equal, and one of the expressions raising
an exception while the other one happily proceeds. The former case
is reasonably easy to handle -- that's why we have an
assertAlmostEqual method in unittest.TestCase; the latter can be a
nightmare.
The same goes for the other bug I recently added to the tracker, the
""" x != y and [x] == [y] """ one. Of course, according to this
"more confusing features" philosophy, I guess it can be considered
quite OK to leave in Python absurdities like this one, as well. I
abhor that whle "slippery slope" philosophy ("there's a tiny
unavoidable problem in this corner so it's OK to leave a huge gaping
hole all over the place") but I see no way to resolve such
philosophical conflict without BDFL pronouncement. So, I have
reverted r51525; I now believe it can't be done right (with proper
unittests) without PEP 754 or something like that, anyway.
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] [Python-checkins] r51525 - in python/trunk:Lib/test/test_float.py Objects/floatobject.c
On Aug 23, 2006, at 3:13 PM, [EMAIL PROTECTED] wrote: > Zitat von Tim Peters <[EMAIL PROTECTED]>: > >> Huh. It's been a (mildly controversial, but intentional all the >> same) >> feature that Python tries to raise raise OverflowError on overflowing >> libm operations. Doesn't work all that well, since there's no >> consistency across platforms about when libm sets errno, or to what >> (when it does). > > The other question is whether pow() is guaranteed to return inf > when it sets errno to ERANGE; I believe there is no such guarantee. Summarizing my longer mail that crossed with yours: the guarantee is there in the 1999 C Standard; I don't have access any more to a copy of the 1990 C Standard to check how things were back then. > So I think the change should be reverted. I have reverted the change, but I think it (or rather "something like" it -- *SOME* fix for x**2 raising OverflowError while x*x proceeds happily for a certain range of floats) is important and should go back in again. Using Py_HUGE_VAL instead of trusting pow's result might be OK, for example, if the 1990 C Standard is that much weaker on this than 1999's and we need to stick to it anyway. But the problem is that testing this sensibly requires fpconst (from PEP 754) or the equivalent, otherwise it may be impossible to write unittest to show the presence or absence of this bug. 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 362 open issues
On 8/23/06, Georg Brandl <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> I have been spending my Google sprint time on writing and implementing> PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally > defines Signature objects for functions. With the implementation at a> place I am happy with, I wanted to ask about the open issues with the PEP.While reading the PEP, I stumbled over the description of the bind() method. As I understand the implementation patch, the parameter names will be keys andthe arguments values in the resulting dictionary, but this sentence looks tome as if it describes it the opposite way (it also doesn't clarify that "parameter" means "parameter name"):* bind(*args, **kwargs) -> dict Create a mapping from argument to parameter for the signature (see `Open Issues`_ for question of how to handle tuples). You're right, it's a typo. Another question: could it be helpful to make Parameter.default_value aweak reference?Perhaps, but I don't think it is necessarily required. I can change it if others want to go that way, but for now I am happy with the way it is.-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] GeneratorExit is unintuitive and uneccessary
At 04:10 PM 8/23/2006 -0700, Guido van Rossum wrote: >IIUC this is how return currently works -- in some sense it's an >exception, but it can't be caught, and it won't escape from the >current frame. Ditto for break/continue. > >The generator extensions are still very young, and I'm not against >changing them somewhat in 2.6 or py3k. Perhaps GeneratorExit can be >replaced by a treatment similar to the treatment of return. But I'm >not sure it helps with the original problem; It depends on what you're referring to as "the original problem". If you mean the problem Bob Ippolito opened a bug for, then yes, it does not solve that problem. But I think we agree that *that* problem doesn't actually need solving. However, it *does* solve the problem(s) that Igor Bukanov brought up, namely that GeneratorExit is unintuitive and unnecessary. :) It also fixes the problem of calling close() or GC'ing a generator written for an earlier version of Python, that yields inside a try-except. >In a generator, a yield >in the finally clause still needs to be dealt with somehow. And we should keep the existing PEP-defined behavior for dealing with it. That is, my understanding is that the only part of close()'s definition that would change is the 'throw(GeneratorExit)' bit. I just wish this had been proposed some time much sooner, like maybe not long after I did the original implementation of throw()/close()/etc. During the original discussion, I'd have been more skeptical of a return-based approach. But knowing what I know now about the implementation, making it based on return instead would be trivial. A proof-of-concept patch I just whipped up adds 7 lines to the hook code in ceval.c (to determine whether WHY_RETURN or WHY_EXCEPTION should be used), and 5 lines to gen_close() in genobject.c. ___ 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] GeneratorExit is unintuitive and uneccessary
At 01:44 AM 8/24/2006 +0200, Igor Bukanov wrote: >Regarding yield in the finally problem: > >The current implementation throws RuntimeException after the yield >transfer the control back to the close method. If that is changed to >reporting a bad behavior and rethrowing GeneratorExit or its hidden >analog as suggested at the point of yield inside the generator, that >would nicely unwind possible outer finally blocks and close the >generator in any case. This approach has already been proposed and rejected multiple times. A badly-behaving generator is broken and asking it to handle the error of its own brokenness will lead only to grief. Once the generator yields inappropriately, it has proven it cannot be trusted. It is only compounding the generator's insanity to ask it to handle this error! ___ 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
