Mailman 3 August 2004 - Python-Dev

Similar syntax
by Gustavo Niemeyer 06 Aug '04

06 Aug '04

> Ok, I'll try to summarize the current status of the feature > so that I (and others) can understand if there's something to > be done: > > - Decorators are going in on 2.4. [...] > - The @ character is used in at least two tools (Leo, IPython), > and this is being considered as something bad, but not a > show stopper; > > - The perlish argument is non-sense; > > I belive that either some different syntax which most > people agree upon is raised, or we're done. After writing this list, I thought about something which is close to the current implementation, but avoids @. If it was already suggested, please forgive me. At least I wasn't able to find it in the PEP/Wiki: <static> def method(foo): pass and also <accepts(int,int), returns(float)> def bar(low, high): ... Advantages over current syntax: - Avoids introducing a new meaningful character in the syntax; - Leaves Leo and IPython people happy; - ">" is already being used on "print >>", so special casing it wouldn't be something new; - Not acceptable in the current syntax; - Looks like a tag; -- Gustavo Niemeyer http://niemeyer.net

4 4

Decorator syntax proposal
by Wiktor Sadowski 06 Aug '04

06 Aug '04

FWIW: [def][decorateMethod1(param)] [def][decorateMethod2(param)] def method(self,param): pass or all in one line [def][decorateFunc1(param)][decorateFunc2(param)] def func(param): pass [class][decorateClass(param)] class toBeDecorated: pass import hooks [import][modify(mod)] import foo Regards Wiktor Sadowski

1 0

RE: [Python-Dev] Call for defense of @decorators
by Robert Brewer 05 Aug '04

05 Aug '04

Martin: > So we do need Unicode after all :-) > > ►classmethod > def foo(): > pass And after that, we can replace 'def' with \u0402 >:) ►classmethod ƒ foo(): pass Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

Re: Call for defense of @decorators
by Shalabh Chaturvedi 05 Aug '04

05 Aug '04

I converted some code which makes good use decorators (an example follows): @paramnames(username='Username', password='Password') @webmethod(username=str, password=str) def login(self, username, password, return_to=None): request = current.request ... Here is some usability feedback: + Easy to type. I found myself typing the function name before going up one line and typing the decorators - @ decorator <ENTER> @ decorator <ENTER>. + One line is one decorator - this preserves clarity while writing and reading. + I look at the code and all decorators line up in a column just above the function - very easily browsable and hard to miss. No searching or scanning required. + Changing order or decorators (if it matters) is easy. The only downside I found was: - @ is a 'noisy' character and makes it look a little cluttered. Usually def has an empty line before it but with decorators there is some funky code sticking to it. Not a big deal, though. Also, this symptom might get alleviated once editors know how to color decorators nicely. 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 ... |webmethod() def logout(self, return_to=None): current.request.session.user = None return current.request.redirect(return_to or self._q_location) Appears accentuated, yet clean, specially for simple/single decorators. Gives an appearance that the decorators are 'connected' to the function. Conclusion: as a user I'm +1 on the @-decorator syntax, or any similar syntax using an alternative character. Cheers, Shalabh

1 0

RE: [Python-Dev] A usability argument for list-after-def
by Robert Brewer 05 Aug '04

05 Aug '04

Skip wrote: > >> So there it is, my personal argument for > list-after-def as better > >> than "@" ... > > aahz> +1 > > What he said. > > +1. > > I had simply given up arguing the point because it seemed > pointless and I > was tired of arguing. I suppose there are more than a few > people in this > particular boat. ObAOLMeToo. +1 Good-thing-we're-NOT-voting-ly yours, Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

RE: [Python-Dev] A usability argument for list-after-def
by Delaney, Timothy C (Timothy) 05 Aug '04

05 Aug '04

Aahz wrote: > I've been staying out of this because I thought my preference had no > chance to make it in (i.e. I don't care between "no decorators" and "@ > decorators"), but if it's getting some revival, I want to make clear > that I think putting decorators *after* ``def``, name, and parameter > list but clearly *with* the function definition makes the most sense > for readability -- in the simple cases. Who cares about the complex > cases, because it's always going to be ugly? +1 This has been my position all along. I understand the need for decorator syntax (and even defended pie-syntax on c.l.py for that reason) but I think that of all the alternatives, list after parameters, before colon is the best alternative presented. def func (params) [decorators]: pass To me this conveys the information I need clearly and in the order that I need it - name is most important, parameters second, and the "type" of function last. The vast majority of functions are between 1 and 3 parameters. Similarly, I doubt there will be many functions with more than a couple of decorators. Having everything on a single line in the majority of cases is IMO a big win - both for readability and understandability. Tim Delaney

1 0

No handlers could be found for logger "cookielib"
by Vinay Sajip 05 Aug '04

05 Aug '04

I just made a change to test_logging to clean up after itself, so that it removes all handlers that it creates. test_urllib2 seems to have handler creation commented out in NetworkTests.setUp(). A combination of the two may explain why the message shows up now. Vinay Sajip ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 1

About pep 318--Intro
by Edward K. Ream 05 Aug '04

05 Aug '04

I received the following from GvR in a private communication: > If good arguments against @ are presented it may be removed in 2.4b1 (that was always the plan but apparently not publicized). I am going to take this as an invitation to discuss @ syntax again. Given the controversy, a reexamination of the major issues seems not only reasonable, but desirable. Please feel free to send me links to relevant discussion, but given the apparent lack of consensus at present I would not like to be told to read the entire py-dev archives. > Please bring up the Leo issues in Python-dev. I'll be posting on separate threads soon. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

2 1

Plea for simpler decorator syntax, in addition to pie-shaped syntax
by Jim Fulton 05 Aug '04

05 Aug '04

IMO, the most common uses of decorators will be to define properties, and class and static methods. IMO, these uses would be better served by a simpler syntax: def classmethod foo(cls, ...): ... This simplified syntax only allows names to specify decorators. It could allow multiple names, although I'm not sure it should, I find this *far* more readable and obvious than any of the other syntaxs I've seen propsed. Those applications that *need* decorator arguments could use the more complex pie-shaped notation. 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

10 10

RE: [Python-Dev] Call for defense of @decorators
by Batista, Facundo 05 Aug '04

05 Aug '04

[Gustavo Niemeyer] #- Is there something to be done that could change the current #- decision? Voting? Collecting pros/cons and classifying them? Guido said it. All the people that doesn't like the actual state of things could choose together an alernative syntax and propose it to him. Then, I guess, he'll choose. Be aware that he wants good reasons, ;) Anyway, I think that administering a voting/brainstorm to choose another syntax is a good idea. Maybe in this list, maybe in another list, maybe on IRC, as you like. . Facundo

2 1