Re: [Python-Dev] [Python-checkins] r51458 - peps/trunk/pep-0000.txt peps/trunk/pep-0362.txt
brett.cannon wrote: > Added: peps/trunk/pep-0362.txt > +Relation With Other PEPs > + > + > +"Keyword-Only Arguments [#pep-3102]_ > + > + > +If keyword-only parameters come into existence, the Parameter object > +will require modification. A ``keyword_only`` attribute will be added > +that holds a boolean representing whether the parameter is > +keyword-only or not. Why an extra attribute instead of using "x.position is None"? Unlike default_value, None is not otherwise a legitimate value for the position attribute. > +Where should keyword-only parameters be stored in the Signature object? > +--- > + > +If PEP 3102 [#pep-3102]_ ends up being accepted, there is the > +possibility that storing keyword-only parameters in a set instead of > +in the ``parameters`` attribute of the Signature object makes more > +sense. Since keyword-only parameters do not have any semantic meaning > +in terms of their position within the signature, there is no direct > +semantic gain in storing it in the parameter list. > + > +Storing keyword-only paramaters in a set makes it much more explicit > +that keyword-only parameters have no inherent order. It does have the > +drawback, though, that if one wants to process all parameters at once > +they would need to perform extra work to make sure to go through both > +the parameter list and set. Throwing the keyword arguments in a set still loses information that was present in the source code. Preserving the ordering in the signature object means that the author of the function can control the order in which the keyword arguments are displayed by introspection-based help utilities (e.g. putting "more important" arguments first. 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] What should the focus for 2.6 be?
On Mon, Aug 21, 2006 at 12:24:54PM -0700, Brett Cannon wrote: > As for the docs, they just need a thorough updating. Michael Hudson was working on a new guide to extending/embedding Python. Incorporating that should be a goal for 2.6 (the document may still need to be finished -- I'm not sure what state it's in). The HOWTOs should be incorporated into the documentation build process; this will mean you need both LaTeX and Docutils to build all the documentation. I already have a Makefile patch for this; perhaps I should just check it into the trunk now. --amk ___ 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] What should the focus for 2.6 be?
"A.M. Kuchling" <[EMAIL PROTECTED]> writes: > On Mon, Aug 21, 2006 at 12:24:54PM -0700, Brett Cannon wrote: >> As for the docs, they just need a thorough updating. > > Michael Hudson was working on a new guide to extending/embedding > Python. Incorporating that should be a goal for 2.6 (the document may > still need to be finished -- I'm not sure what state it's in). Oh my word, even I had nearly forgotten about that. I think the latest version is here: http://starship.python.net/crew/mwh/toext/ and source is here: http://codespeak.net/svn/user/mwh/toext/ It's certainly not even half-finished, and I'm not sure how much time or enthusiasm I'm likely to be able to find for it in the medium term. Cheers, mwh -- ZAPHOD: OK, so ten out of ten for style, but minus several million for good thinking, eh? -- The Hitch-Hikers Guide to the Galaxy, Episode 2 ___ 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] What should the focus for 2.6 be?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 22, 2006, at 11:26 AM, Michael Hudson wrote: > Oh my word, even I had nearly forgotten about that. > > I think the latest version is here: > >http://starship.python.net/crew/mwh/toext/ > > and source is here: > >http://codespeak.net/svn/user/mwh/toext/ > > It's certainly not even half-finished, and I'm not sure how much time > or enthusiasm I'm likely to be able to find for it in the medium term. I'd be willing to help out with this, as well as flesh out some of the more, er, under-documented parts of the C API. I do a /ton/ of embedding/extending work for my Real Job so I think I could justify some work time devoted to improving things here. I'll try to take a look at MWH's stuff, but should we go ahead and check it into Python's svn at some point? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBROsjuHEjvBPtnXfVAQLEcQQAiyH3LaJysEJrpbHPQhXUMBlQ/+ULDatc D1pBUmN02jY33fg14Z8Tw7AjJ5cOWsDFeF+gh6TBXvawpvF2q/XafdmtjkjwvQpa 8KfAl5JeNHSyTTd5tcKuZ1y2mQ1XpVVIqICT8PP24l+6RyCbnRhTe6MaLUHnUegm bSl728r3s64= =7WIt -END 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] [Python-checkins] r51458 - peps/trunk/pep-0000.txt peps/trunk/pep-0362.txt
On 8/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: brett.cannon wrote:> Added: peps/trunk/pep-0362.txt> +Relation With Other PEPs> +> +> +"Keyword-Only Arguments [#pep-3102]_> + > +> +If keyword-only parameters come into existence, the Parameter object> +will require modification. A ``keyword_only`` attribute will be added> +that holds a boolean representing whether the parameter is > +keyword-only or not.Why an extra attribute instead of using "x.position is None"?Didn't think of that. =) Unlikedefault_value, None is not otherwise a legitimate value for the positionattribute. Makes sense. I will talk it over with Jiwon. Might want to rename 'position' to 'positional' then in order to make it even more obvious what the information stores. > +Where should keyword-only parameters be stored in the Signature object?> +--- > +> +If PEP 3102 [#pep-3102]_ ends up being accepted, there is the> +possibility that storing keyword-only parameters in a set instead of> +in the ``parameters`` attribute of the Signature object makes more > +sense. Since keyword-only parameters do not have any semantic meaning> +in terms of their position within the signature, there is no direct> +semantic gain in storing it in the parameter list. > +> +Storing keyword-only paramaters in a set makes it much more explicit> +that keyword-only parameters have no inherent order. It does have the> +drawback, though, that if one wants to process all parameters at once > +they would need to perform extra work to make sure to go through both> +the parameter list and set.Throwing the keyword arguments in a set still loses information that waspresent in the source code. Preserving the ordering in the signature object means that the author of the function can control the order in which thekeyword arguments are displayed by introspection-based help utilities (e.g.putting "more important" arguments first. That's a good enough argument for me.-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] [Python-checkins] r51458 - peps/trunk/pep-0000.txt peps/trunk/pep-0362.txt
On 8/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: brett.cannon wrote:> Added: peps/trunk/pep-0362.txt> +Relation With Other PEPs> +> +> +"Keyword-Only Arguments [#pep-3102]_> + > +> +If keyword-only parameters come into existence, the Parameter object> +will require modification. A ``keyword_only`` attribute will be added> +that holds a boolean representing whether the parameter is > +keyword-only or not.Why an extra attribute instead of using "x.position is None"? Unlikedefault_value, None is not otherwise a legitimate value for the positionattribute. OK, talked over with Jiwon and the room here at the sprint and the preference was to keep it as-is. Reasons were it allowed the position in the signature to be kept with the object (and thus not be reliant on the Signature object to know its position in the actual output), and the possibility of disparate types being in the attribute. Plus Guido preferred the original way. =) -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] String formatting / unicode 2.5 bug?
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.
John
___
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] GeneratorExit is unintuitive and uneccessary
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/archive%40mail-archive.com
