Mailman 3 February 2004 - Python-Dev

new syntax for wrapping (PEP 318)
by Jewett, Jim J 26 Feb '04

26 Feb '04

Jim Jewett: >> Also, many of them don't work with the proposed >> syntax. Specifically, you're trying to provide >> a second binding for the function (such as running >> for __main__, or registering with the exit handler). >> For me, this is the most common use case, but ... >> PEP 318 doesn't handle it. (Which is one reason >> that I don't think this will be the *last* extension, >> which is one reason I don't want *bare* syntax.) Bob Ippolito: > Sorry, but you understate the capabilities of this new > syntax and overestimate the need for future related syntax. Not really; I guess I should have left in the full original example. def foo[__main__]: will not work. Yes, you can first define a decorator function specific to this particular function you're about to define, just as you can currently rebind the functions's name to a transform of the function. Both are ugly. Jim Jewett: >> I realize that the new syntax (patch version) would >> actually say something more like [for Quixote] >> def head [html](title)[classmethod]: Bob Ippolito: > in theory the proposed new syntax is enough to accommodate > Quixote's domain specific language **without the need for a > custom grammar**. Agreed. If it weren't for backwards compatibility, they could just migrate to the new version entirely. My point isn't that both are needed; my point is that using up unnamed syntax can come back to bite you later. (In fairness, this is also a slight knock against "as", which could just as easily mean "alias" - which I find a more common use case. But "as" is OK if the proponents really want something short.) Jim Jewett: >> Features which are used frequently need to be short. >> Features which are used rarely (like this one?) can be >> more verbose. >> I agree that if only advanced users will need it, then it >> can be a bit more complex to use. It should absolutely >> not be harder to recognize as irrelevant. Bob Ippolito: > The problem is that advanced users will need it /quite/ > frequently :) Fair enough; then it is reasonable to use an obscure abbreviation, so long as it isn't obscure enough to be mistaken for possibly normal usage. Use "X" as the magic keyword if you want. (Though even "as" is better.) > I don't think it's a burden on the rest of the language, > I just think it's a burden on newbies who try and read > advanced code. They'll probably be confused by what it > does, anyway. I haven't seen much in the way of difficulty-graded indices of sample code. A common introduction to a new language is to have a specific problem, and to hear that package X solves it. If package HyperMetaConfusing is the package that solves the problem, then it is the first package new users will look at. Jim Jewett: >> If *functions* had seemed awkward, I would have >> chosen another language instead. Bob Ippolito: > Classes are currently so much more preferable to > functions because it's easier to make them carry > around lots of beautiful wonderful metadata. For me, the advantage is that they save state. I understand that others use them very differently; my main point is that adding syntax to something I consider crucial (functions) is more of a problem (for me) than adding it to something that I don't consider crucial. If this transform applied only to class methods, it would not have put newbie-me off, because those aren't as basic. (I don't suggest this artificial distinction; I only point out that it affects the "cost" of the change.) I am willing to bet that most programmers (and non- programmers starting with python as a first language) will believe that they need to learn functions. So function syntax should be as transparent as possible. -jJ

2 1

Re: new syntax for wrapping (PEP 318)
by Shalabh Chaturvedi 26 Feb '04

26 Feb '04

Hello python-dev people: Just joined, intro below :) Barry Warsaw wrote: > I've rewritten some of my code to use both the [] and the 'as' syntax. > Neither is ideal, primarily because the interesting information tends to > get pushed way off to the right, where I think the eye is lazier because > of the more ragged nature of "code right". > > Putting the decorator between the def and the method name actually > doesn't look so bad to me, e.g.: > > def [classmethod] func(a, b, c): > > but I think with a longer decorator list, it might be problematic. I > think that one element decorator lists will be the most common use and > in that case, I like this syntax because it almost reads like English. I completely agree. This is the second-most elegant syntax, the most-elegant being: def classmethod func(a, b, c): Has this been completely rejected? The pep's argument is it becomes cluttered and obscure when the decorator is a function call: def synchronized(lock) classmethod func(a): Can we also require that decorators be identifiers only (no expressions allowed), forcing clean looking definitions? The above would be rewritten as: sync = synchronized(lock) def sync classmethod func(a): In fact sync would probably be reused throughout the class body. This keeps simple things simple, and complex things possible. In addition it encourages using few decorators, keeping the def line short. And did I mention no new keywords? The alternatives - using [], (), <> and/or expressions - only make it more cluttered, leaving the simple (and IMO most common) cases hard to read and write. They do provide power that is useful for specific domains, but unnecessary for general purpose programming. Which would be ok (since when is power a bad thing?) if it wasn't at the cost of readability. Cheers, Shalabh Chaturvedi PS: I am a software consultant and have been using Python for four years (which includes two years of full time development :-). Needless to say, it is my first choice for solving problems. Recently I have become more interested in development and promotion of Python.

7 8

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Moore, Paul 26 Feb '04

26 Feb '04

From: Barry Warsaw > On Thu, 2004-02-26 at 02:43, Josiah Carlson wrote: > >> You (and others) have convinced me. There exists a reasonably large >> number of use-cases, even if I don't have one. The real question is >> whether everyone can decide on a good syntax. > > We won't, so if the PEP's accepted, the BDFL will do it for us. That's > why we keep him around <wink>. The PEP doesn't specify where discussion should take place, but the author hasn't participated here. At some point, he (or someone else) is going to have to put the PEP forward for acceptance. At the moment, the PEP appears fairly strongly in favour of "as" and against the use of brackets. But the author admits that he has not got the expertise to provide an implementation. So where do we go from here? Is anyone willing to modify MWH's patch to implement the "as" syntax, resulting in a PEP with associated implementation which can be submitted for approval? Should the PEP be changed to propose a syntax that matches the existing patch? I've copied the PEP author, in the hope that he can share his views. Paul.

3 2

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Phillip J. Eby 26 Feb '04

26 Feb '04

At 11:35 AM 2/26/04 -0500, Jewett, Jim J wrote: >Pete Shinners: > > Some of these may even be bad ideas apon further > > thought, but it's something to ponder. > >Also, many of them don't work with the proposed >syntax. Specifically, you're trying to provide >a second binding for the function (such as running >for __main__, or registering with the exit handler). def __main__(func): if __name__=='__main__': func() This now works correctly as long as you define your main function as the last thing in your module. As for the exit handler thing, that works okay too. All that happens is that the function you decorate it as will be None. So after: def exitHandler() [atexit.register]: ... 'exitHandler' will be 'None', but the function as it was defined will be registered for running at system exit. So, yes, actually, these two ideas do work with the proposed syntax. >Features which are used frequently need to be short. >Features which are used rarely (like this one?) can be >more verbose. Actually, I think that if the feature exists, it will be used frequently and for a wide variety of things. It is probably the closest thing to having macros that Python will ever get. We don't even know how many other cool things people will come up with to do with them. >I agree that if only advanced users will need it, then it >can be a bit more complex to use. Advanced users will *create* decorators, but everybody will want to *use* them. >If you use bare syntax, then the burden is >on everyone, and you have raised the barrier to entry for >the rest of the language. I don't think that's true, even for the [] syntax case. Most decorator lists will be relatively short, and the items *in* the decorator list will almost always be a good place to look them up. It's only the reuse of non-decorators (like 'atexit.register') or undocumented custom decorators that's likely to be confusing in reading code.

1 0

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Moore, Paul 26 Feb '04

26 Feb '04

From: Andrew Bennetts > Exactly -- this is why a keyword isn't need, the decorator is the "keyword". > Where Java people need to lookup "static" in their language manual, Python > people will lookup "staticmethod" in the library reference. The > documentation for staticmethod would presumably mention that it's a "function > decorator", and link to the appropriate docs, and maybe even give an example. This is a very good point. Assuming the "as" keyword, any user who saw def f(a, b, c) as classmethod: .... and looked up "as" rather than "classmethod" has clearly been having a bad day. Who, as a new user, saw "import something as another" and looked up "as" rather than "import"? Go on - admit it. You're among friends :-) Paul.

2 1

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Moore, Paul 26 Feb '04

26 Feb '04

From: Jewett, Jim J > Agreed. And why limit it to lists - why not any expression that > evaluates to a list? Or maybe any sequence? Which is one reason > that a bare "[...]" doesn't seem sufficient. Overgeneralisation without good use cases. Leave it as simple lists. Bob Ippolito just posted a pseq function which will do this for the (extremely rare) cases when it might be needed. > They don't need to, in general. The specific functions that they > do need (like __init__) are in the index. Though to be honest, > this was a concern at first, when I thought that creating a class would > require me to define a large number of methods. If I had been more > deeply object-oriented, that might have put me off. Instead, I just > started with functions instead of classes. Exactly. As a beginner, classes were more advanced than you needed. So the (relative) difficulty of finding the relevant details wasn't an issue - you just didn't use the feature for a while. By the time you needed classes, you were familiar enough with Python to know where to look. Heck, by the time most people will need the full power of the wrapping feature [1], they will probably know enough to understand the C code of the patch itself! It's pretty advanced usage, remember... [1] Except for extremely stylised cases like [classmethod], which will be for particular use cases - and you can look that one up under "classmethod"... Paul.

3 2

PEP 318: What Java does
by Paul Prescod 26 Feb '04

26 Feb '04

@debug(devbuild=production,counter=1) public void testMethod() { } public @remote void ping() { } The Java way does make clear what is a language builtin ("public", "void") and what is extension metadata "@remote", "@debug". That may not be a bad thing... Paul Prescod

1 0

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Edward Loper 26 Feb '04

26 Feb '04

Jim Jewett said: > def f(arg) [x] : # wrap f in x > def f(arg) : [x] # start f's def with a list of x > > [...] > > These are all well-defined for parsing, but I don't think the > distinctions are obvious to a human who doesn't already know > the syntax. This point has come up a couple times, and I don't think it's really a valid complaint, because... * You won't get confused when reading it: No one will ever write the second one (f's def consists of a single list), because it's not a useful function. Has anyone ever actually seen a function like this? So when you're reading the code, you're very unlikely to get confused. This is especially true because there will be an indented body under the f(arg), so the [x] can't possibly be part of the body. * If you write the wrong thing, it's easy to detect: If you accidentally put the [x] after the colon, then you'll get a parse error, since you'll *also* have a body. The current parse error might be a little cryptic (just a syntax error at the first line of the body), but if necessary the parser could be special- cased to give a more specific error there. Some of the other arguments against the new syntax seem reasonable to me, and I'm not yet decided whether I'm in favor of the syntax or not. But I just wanted to point out that I don't find this particular complaint against it very compelling. -Edward

1 0

RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Jewett, Jim J 25 Feb '04

25 Feb '04

Michael> The "def name [modifiers]:" is unpythonic because: Michael> * It re-uses the "[]" for a completely new purpose, Michael> unrelated to lists or indexing. Skip> Not necessarily. It names a list of functions to be applied Skip> to this function to get the final definition ... Skip> def func1(a,b,c) [m for m in modifiers if is_enabled(m, "func1")]: Skip> If you are going to add [...] as a function modifier syntax, Skip> I would argue that it should allow the full power of list Skip> (or generator) comprehensions. Agreed. And why limit it to lists - why not any expression that evaluates to a list? Or maybe any sequence? Which is one reason that a bare "[...]" doesn't seem sufficient. Michael> * It relies heavily on punctuation (the placement Michael> of the ":"). Skip> The placement of the ":" hasn't changed. It's still at Skip> the end. A list constructor was just stuffed in between Skip> the argument list and the colon. def f(arg) [x] : # wrap f in x def f(arg) : [x] # start f's def with a list of x f(arg) [x] # call f, then select the x'th return value and maybe: def f(arg) x : # wrap f in each element of x def f(arg) g(): # wrap f in each element returned by g() def f(arg) g()[x]: # wrap f in the x'th element returned by g() These are all well-defined for parsing, but I don't think the distinctions are obvious to a human who doesn't already know the syntax. Michael> * There's no good way for a newbie to look it up. Skip> How do people learn about function names with leading underscores Skip> or leading and trailing double underscores? They don't need to, in general. The specific functions that they do need (like __init__) are in the index. Though to be honest, this was a concern at first, when I thought that creating a class would require me to define a large number of methods. If I had been more deeply object-oriented, that might have put me off. Instead, I just started with functions instead of classes. Skip> even though non-programmers will probably never have seen the Skip> "**" operator, they still manage to figure it out. It took me several tries to get it working, though, and even then I was missing some points, so I had more confusing problems later. That isn't a desirable trait in new features. Michael> All of these would be addressed by using a keyword. The only Michael> objection seems to be "we couldn't find a word we all Michael> liked". But that's hardly a good reason to go with pure Michael> punctuation. Skip> Function modifiers would be a fairly advanced feature anyway And so they are a good candidate for: Explicit is better than implicit. Sparse is better than dense. Readability counts. In the face of ambiguity, refuse the temptation to guess. Namespaces are one honking great idea -- let's do more of those! -jJ

2 1

Re: Python-Dev Digest, Vol 7, Issue 45
by Peter Harris 25 Feb '04

25 Feb '04

Edward Loper wrote: >Peter Harris wrote: > > >>>* curry() >>> >>>* closure() >>> >>>* partial() >>> >>>* partial_apply() >>> >>>* delayed() >>> >>>* other ? >>> >>> > >bind() and bindargs() seem pretty reasonable to me. But if you don't >like those, then how about fixargs() or fix_args()? That gets across >the message that we're generating a new function that fixes the values >of a subset of the arguments. > >Side note: I think that the following code will have unexpected behavior >with the current implementations: > > >>> def f(x,y,z): return (x,y,z) > >>> g = f.bind(y=3) > >>> print g(1,2) >TypeError: f() got multiple values for keyword argument 'y' > >(I would have expected this to return (1,3,2).) > >Of course, there's not really any way around it without using >inspection, and even then you can't really inspect argument lists for >builtins. But it might be worth noting in the docs the circumstances >under which it's appropriate to bind w/ keyword args. > >-Edward > > > Well, I'm coming to like partial(), because it's short enough, and relates to the term 'partial application'. I don't like verb-based names for this, because you are not doing an action so much as creating a thing. A noun would be splendid if an appropriate one could be found; failing that, an adjective will do, as it _implies_ a noun. So partial() evaluates as a 'partial' something, but bind() looks like it's binding something but not necessarily focusing attention on the fact that what we are making is an object. Peter Harris

1 0