Mailman 3 August 2004 - Python-Dev

Re: elements of decorator syntax suggestions
by John Marshall 06 Aug '04

06 Aug '04

On Fri, 2004-08-06 at 17:19, Steven Bethard wrote: > I think one of the biggest reasons we're having such problems coming > to any agreement on decorator syntax is that each proposal makes a > number of syntax decisions, not just one. For decorators, I see the > following decisions that must be made: > > 1) Indicator > > 2) Location > > 3) List notation > > 4) Indentation I think you have done a good job identifying and isolating what the issues are regarding decorator options. I think another thing that should perhaps be made clearer (maybe for me only?) is to identify, in order of importance/signfigance, the relationship between decorators and the function: 1) is the function/method signature more important than the decorators (to the programmer)? 2) do the decorators belong or are affected by the function? 3) what other constructs in Python say/imply "look ahead for what I am about to affect/define"? I understand that designing programming languages is sometimes an art rather than a science (natural languages a chock full of exceptions to the rule). But if the priority of functions and decorators are established, then I think this would help. In response to my own questions above: 1) From my perspective, it seems that almost everybody would say that the function (class also) signature is more important than decorators. For example, how many people would say "I wonder where the classmethod function is?" Instead, people would say, "Where is my function xyz()". This seems to argue for the decorators following (somewhere) after the signature. Of course highlighting editors can help by marking off function names and parameters, but this argument only serves to confirm that the signature is the KEY thing programmers are interested in. Apart from aesthetics, which are subjective and could be debated endlessly, I cannot see how one could argue otherwise. 2) Perhaps I am not understanding fully. Can someone explain how decorators before the function logically belong outside of the function definition block if they are intended to affect the function? Are the decorators meant to affect something other than the function? It seems to me that in every other situation in Python (please correct me if I am wrong) blocks are the way we are able to identify what belongs to what (e.g., local variable to a function). The current decorator approach says to me, "I belong to the class" (if a class is involved), or "I belong to the module" (if no class is involved). 3) In a sense, this point is somewhat related to #2. Does Python support an implicit "I am doing something now, on something I haven't defined, but which is coming up next" anywhere else than the decorator before function construction? Even in classes, Python forces the use of self.xxx (explicit). Hope this contributes to the discussion. John

1 0

RE: [Python-Dev] Call for defense of @decorators
by Michael Chermside 06 Aug '04

06 Aug '04

Gustavo Niemeyer writes: > Is there something to be done that could change the current > decision? Voting? Collecting pros/cons and classifying them? Yes, there is. And it's not voting <wink>. Write a simple "white paper" summarizing the major arguments and showing how they apply to the 3 or 4 top syntax proposals. Solicit input from c.l.py or python-dev after you have a first draft. After the 3rd draft is done, post it here and send it to Guido. Then sit back and quietly put up with the resulting decision whether you agree or not. At this point, I long ago said most everything I had to say and so I'm working on the "quietly put up with the results" part myself. -- Michael Chermside

2 1

Re: @decorators, the PEP and the "options" out there?
by Jim J Jewett 06 Aug '04

06 Aug '04

Nicolas Fleury asked: > Is there ambiguities with the following? > def decorator1(decoratorN(foo(arg1, argN))): > pass Remember that there is already an obscure possibility for nested argument lists. def func (arg1, (arg2, arg3)): pass __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

I'd like to add an __iter__ method to unittest.TestSuite
by Jim Fulton 06 Aug '04

06 Aug '04

TestSuite objects provide no public mechanism for iteration. We have a need to be able to iterate over them. Up to now, we've been using the _tests attribute, which is bad. If no one objects, I'll add an __iter__ method. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

PEP 318, and the PEP process
by Anthony Baxter 06 Aug '04

06 Aug '04

I'm extremely averse to making the Python development process any heavier than it has to be, but the complaint that PEP 318 should have been updated to the state of play before the checkin is a fair complaint. I'm not sure what the best approach here is - should we make a motherhood-and-apple-pie statement that, all things being equal, a PEP should be updated before the code it documents is checked in? Should we aim to have it done before the first release including the code? Before the first _final_ release that includes the code? My answers would be "before checkin, where possible; before first alpha/beta release, where really possible; before first final release, absolutely". Having said that, I don't think the lack of completed PEP is a reason to back out the @ syntax from CVS. If nothing else, it being present in a released alpha is giving us very real experience with the use of the feature. There's also the issue that there's a bunch of other existing PEPs describing features that aren't up to date at all. Which brings up another related point: Many PEPs contain "open issues" and the like, that are never ever backfilled. Largely this is a matter of round tuits - the PEP authors are generally drawn from a very small group of developers. How can we encourage other people to contribute to this? The obvious way (to me) is some form of Wiki annotation. I don't think we want to make the Wiki the primary copy of the document, but I think having the PEPs annotatable would be a win. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

10 16

PEP 318 - writing to func_name attribute
by Skip Montanaro 06 Aug '04

06 Aug '04

One thing I added awhile back to PEP 318 as an open issue is that for ease of writing wrappers the func_name attribute of a function object should be writable. For example, in situations where the decorator returns a new function object (often, I would think) it would really be nice if that new function object had the same name as the undecorated function. Consider: def a(func): def _inner(*args, **kwds): return func(*args, **kwds) return _inner @a def func(*args, **kwds): print args print kwds print "func's name:", func.func_name I realize you can use new.function() to create a new function object, but that seems like a fair amount of extra complexity just to change the function's name. I'd prefer it if the decorator could be written as: def a(func): def _inner(*args, **kwds): return func(*args, **kwds) _inner.func_name = func.func_name return _inner That fails because func_name is readonly. Any chance this restriction can be loosened up? Skip

3 4

Questions about '@' in pep 318
by Edward K. Ream 06 Aug '04

06 Aug '04

The "mandate" for this post is the following from GvR: > If good arguments against @ are presented it may be removed in 2.4b1 (that was always the plan but apparently not publicized). So I would like seriously to consider whether removing '@' might be a good idea. Note: my major concern with pep 318 has always been with syntax. I am not interested or qualified to discuss whether annotation in general is a good idea... My main questions: 1. Is '@' syntax required to get the job done cleanly? If the answer is clearly Yes, then consensus ought to be fairly easy, it seems to me. 2. If '@' is not required, why isn't it forbidden :-) There have been various statements to the effect that "almost every conceivable syntax alternative has been considered". I'd like to know if the following has been considered, and if so, what the objections to it were/are. Instead of: @accepts(int, (int,float)) Do: from __future__ import annotation as annotate # or a or whatever looks good. annotate.accepts(int, (int,float)) Clearly, with enough work the Python compiler could recognize this. Yes, it's a special case, but so what? This would avoid most problems with reserved words or keywords. And it would be in the spirit of letting modules encapsulate most major features. In other words, what ever happened to namespaces? 3. How "reliable" are the following design goals from pep 318? * be easy to type; programs that use it are expected to use it very frequently * not make it more difficult to scan through code quickly. It should still be easy to search for all definitions, a particular definition, or the arguments that a function accepts. - If visibility of code is a concern, use import annotation as XXXXX. - If brevity is wanted, use import annotation as a. I wonder why these design goals are even present. 4. Assuming that there are advantages to '@', why do they outweigh the disadvantages of changing the following paragraph of the Reference Manual? http://docs.python.org/ref/delimiters.html [quote] The following printing ASCII characters are not used in Python. Their occurrence outside string literals and comments is an unconditional error: @ $ ? [end quote] I regard any change to this paragraph as a major change to Python, in spite of its innocent appearance. Indeed, this paragraph is an excellent "line in the sand" for other tools. The pep contains the following design goal: * not needlessly complicate secondary support tools such as language-sensitive editors and other "toy parser tools out there. How is this not going to happen with the '@' syntax? All answers to these questions would be most appreciated. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

11 19

Re: Call for defense of @decorators
by Richie Hindle 06 Aug '04

06 Aug '04

[Shalabh] > An alternative character (as others have suggested) > might be good too. If so, I found '|' particularly nice :) > > |paramnames(username='Username', password='Password') > |webmethod(username=str, password=str) > def login(self, username, password, return_to=None): > request = current.request > ... I much prefer this to @decorator. In addition to the advantages that Shalabh gives: + It doesn't break Leo, IPython, or any other tool that uses @ as a special character. + The association with pipes makes some sense: "take this thing and pass it through that thing to get a modified thing". Perhaps someone with write access to the Wiki page at http://www.python.org/moin/PythonDecorators could add this idea there? It would be a shame if it got lost in the high-volume traffic here on python-dev. Unless there's some overwhelming technical reason why reusing the '|' character isn't possible, of course. -- Richie Hindle richie(a)entrian.com

3 2

Python in Unicode context
by François Pinard 06 Aug '04

06 Aug '04

Hello, people. I'm switching from ISO-8859-1 to UTF-8 in my locale, knowing it may take a while before everything gets fully adapted. Of course, I am prepared to do whatever it means. On my side at least, the perception of a meaning is an evolving process. :-) So, my goal here is to share some of difficulties I see with the current setup of Python in Unicode context, under the hypothesis that Python should ideally be designed to alleviate the pain of migration. I hope this is not out of context on the Python development list. Converting a Python source file from ISO-8859-1 to UTF-8, back and forth at the charset level, is a snap within Vim, and I would like if it was (almost) a snap in the Python code as well. There is some amount of trickery that I could put in to achieve this, but too much trickery does not fit well in usual Python elegance. As Martin once put it, the ultimate goal is to convert data to Unicode as early as possible in a Python program, and back to the locale as late as possible. While it's very OK with me, we should not loose sight that people might adopt different approaches. One thing is that a Python module should have some way to know the encoding used in its source file, maybe some kind of `module.__coding__' next to `module.__file__', saving the coding effectively used while compilation was going on. When a Python module is compiled, per PEP 0263 as I understand it, strings are logically converted to UTF-8 before scanning, and produced str-strings (but not unicode-strings), converted back to the original file coding. When later, at runtime, the string has to be converted back to Unicode, it would help if the programmer did not have to hardwire the encoding in the program, and edit more than the `coding:' cookie at the beginning if s/he ever switches file charset. That same `module.__coding__' could also be used for other things, like for example, to decide at run-time whether codecs streawriters should be used or not. Another solution would of course be to edit all strings, or at least those containing non-ASCII characters, to prepend a `u' and turn them into Unicode strings. This is what I intend to do in practice. However, all this editing is cumbersome, especially until it is definitive. I wonder if some other cookie, next to the `coding:' cookie, could not be used to declare that all strings _in this module only_ should be interpreted as Unicode by default, but without the need of resorting to `u' prefix all over. That would be weaker than the `-U' switch on a Python call, but likely much more convenient as well. As a corollary, maybe that some `s' prefix could force `str' type in a Unicodized module. Another way of saying it would be that an unadorned string would have `s' or `u' implied, depending if the Unicode cookie is missing or given at the start of a module. I have the intuition, still unverified, but to be confirmed over time and maybe discussions, that the above would alleviate transition to Unicode, back and forth. P.S. - Should I say and confess, one thing I do not like much about Unicode is how proponents often perceive it, like a religion, and all the fanatism going with it. Unicode should be seen and implemented as a choice, more than a life commitment :-). Right now, my feeling is that Python asks a bit too much of a programmer, in terms of commitment, if we only consider the editing work required on sources to use it, or not. -- François Pinard http://www.iro.umontreal.ca/~pinard

12 35

Questions about '@' in pep 318
by Edward K. Ream 06 Aug '04

06 Aug '04

> Please do not mislead people into thinking that a discussion of syntax alone is of any value, *unless* there is a willingness on the part of those against the "@" syntax to compromise on a single alternative. This statement seems a bit too strong, for the following reasons: 1. Adding @ impacts major external tools, negatively. 2. Adding @ is, in fact, a major change to the language. 3. The "willingness to compromise" is not really the driving force here: GvR is the only vote that matters. I have stated that Leo can probably live with the at sign. I have also stated elsewhere my reasons for not being particularly happy with it. For the record, I am +0 on the semantics. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

1 0