Re: [Python-Dev] removing nested tuple function parameters
On 9/18/05, Greg Ewing [EMAIL PROTECTED] wrote: François Pinard wrote: The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. If the argument represents a coherent enough concept to be passed in as a tuple in the first place, it should be possible to find a meaningful name for it. Otherwise the elements should probably be passed in as separate arguments. Yet, if I was given the choice between nested tuple function arguments, and faster argument processing, the latter would win instantly. I believe that exactly the same bytecode results either way, so there's no speed advantage or penalty. Yep, the bytecode will be the same sans the compiler-created name for the tuple . -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Greg Ewing wrote: François Pinard wrote: The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. If the argument represents a coherent enough concept to be passed in as a tuple in the first place, it should be possible to find a meaningful name for it. Otherwise the elements should probably be passed in as separate arguments. But sometimes you don't have this option. If I have a class that I'd like to support an indexing operation like: obj[x, y] then the natural __getitem__ signature will look like: def __getitem__(self, (x, y)): ... Note that I definitely can't write this as: def __getitem__(self, x, y): ... because __getitem__ is always called with a single argument, not two. Of course, I can give the parameter a name and do the tuple unpacking manually (e.g. x, y = x_y), but I'm not sure I understand yet what we gain by making __getitem__ harder to use with tuples. I guess if tuple unpacking in function parameters goes away, I think we should change the __getitem__ machinery so that: obj[x1, x2, ..., xN] is translated to: obj.__getitem__(x1, x2, ..., xN) where __getitem__ would now have to take a *args when called with tuples. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
I consider the current situation to be a consistency feature. To a first approximation, Python function calls 'pass' objects by name-binding: param_name_list = arg_object_list Disabling structure unpacking in this assignment would make the language slightly more complex. Someone else posted the same observation in c.l.p. Another thought. By directly unpacking and not naming a sequence, one 'announces' that only the components are of interest and that nothing will be done with the sequence object itself. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
On 9/19/05, Terry Reedy [EMAIL PROTECTED] wrote: I consider the current situation to be a consistency feature. To a first approximation, Python function calls 'pass' objects by name-binding: param_name_list = arg_object_list Disabling structure unpacking in this assignment would make the language slightly more complex. Someone else posted the same observation in c.l.p. Maybe, but there are enough differences between parameter/argument lists and sequences that this consistency sounds rather foolish to me. In fact, the feature came from a similar feature in ABC, but in ABC, parameter lists *were* considered assignment targets -- the outer level of parentheses was just a special case of tuple unpacking. Not so in Python, which has keyword parameters, *varargs, **keywords, and where f(x,) is the same as f(x) -- even though (x,) is a tuple and (x) is not. Also, I bet many people will be surprised to know that this code doesn't work: add = lambda (x, y): x+y print add(1, 2) Another thought. By directly unpacking and not naming a sequence, one 'announces' that only the components are of interest and that nothing will be done with the sequence object itself. Fair enough, though I'm not sure what use we can make of that information. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Guido van Rossum wrote: Also, I bet many people will be surprised to know that this code doesn't work: add = lambda (x, y): x+y print add(1, 2) What, an example using lambda syntax that's unintuitive? Never! ;-) STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
I agree that we shouldn't mess with them in 2.x. Yet I think they are a candidate for being dropped from Py3K. While every feature is used by *someone* (as the feedback to Brett's query clearly shows) this one has several things against it. For every user who is fond of them there are probably ten who have never even heard of it. It's purely syntactic sugar (the only place where it's not trivial to replace is in a lambda). I've encountered quite a few people who had a hard time reading code that uses it. I personally prefer reading code that doesn't use this feature; for one thing, when this is used, you can't refer to a parameter by name. I don't know whether this qualifies as an argument for or against the feature, but ML has a nice way of referring to such a parameter by name: fun f(x as (y, z)) = (* ... *) This defines f as a function with an argument that is a 2-element tuple. The name x is bound to the argument, and the names y and z are bound to the two components of the argument. This example is syntactic sugar for fun f x = let val (y, z) = x in (* ... *) end but it I find the sugared version easier and more natural to write and understand. If you don't know ML, the unsugared version might be easier to follow if I indent it Pythonically: fun f x = let val (y, z) = x in (* ... *) end The idea is that the stuff between in and end is executed in the scope of the bindings between let and in, after which those bindings are discarded. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. Another reason, but not practical at all, is that the concept conveys some elegance and originality (each programming language should ideally have a few of these) and is enforced in other places in Python, like in the `for' statement -- where I find implied unpacking very, very useful. One other reason: It is possible to imagine using the feature to catch some type errors at the point of call, rather than having to get into the function itself before detecting them. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Andrew Koenig [EMAIL PROTECTED] writes: The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. Another reason, but not practical at all, is that the concept conveys some elegance and originality (each programming language should ideally have a few of these) and is enforced in other places in Python, like in the `for' statement -- where I find implied unpacking very, very useful. One other reason: It is possible to imagine using the feature to catch some type errors at the point of call, rather than having to get into the function itself before detecting them. Conceptually, maybe, but implementation wise, that's not how things work. Cheers, mwh -- I love the way Microsoft follows standards. In much the same manner that fish follow migrating caribou. -- Paul Tomblin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Steven Bethard wrote: I guess if tuple unpacking in function parameters goes away, I think we should change the __getitem__ machinery so that: obj[x1, x2, ..., xN] is translated to: obj.__getitem__(x1, x2, ..., xN) where __getitem__ would now have to take a *args when called with tuples. That might be a reasonable idea to consider for Py3k in any case. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Terry Reedy wrote: I consider the current situation to be a consistency feature. To a first approximation, Python function calls 'pass' objects by name-binding: param_name_list = arg_object_list Disabling structure unpacking in this assignment would make the language slightly more complex. But it's a rather selective kind of consistency. To be truly consistent in this sense, arbitrary lvalues would have to be allowed in the parameter list. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Andrew Koenig wrote: One other reason: It is possible to imagine using the feature to catch some type errors at the point of call, rather than having to get into the function itself before detecting them. Not a big deal - you just need to look one line further up in the traceback to find where the call was. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Brett Cannon wrote: Would anyone really throw a huge fit if they went away? I am willing to write a PEP for their removal in 2.6 with a deprecation in 2.5 if people are up for it. -1. I don't think this could realistically be done before 3.0, because it would break a lot of existing code for no good reason. I probably wouldn't mind all that much if they went away in 3.0, although they can be handy. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
* Brett Cannon: Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. Will def fxn((a,b,),): print a,b continue to work? (I'm not sure if the problems are syntax or representation of the parse tree; I don't know what's going on on that AST branch.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Brett Cannon wrote: Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. I personally don't see them being overly useful thanks to assignment unpacking. Plus I don't think they are used very much (gut feeling, though, and not based on any grepping). The fixes needed to make them work properly didn't seem all that ugly to me. Also, if they weren't used in the stdlib, they wouldn't have caused us any grief on the AST branch ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
[Brett] Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? I am. ditching them thanks to the pain they caused in the AST branch. Changing the grammar for the convenience of a particular AST implementation carries zero weight with me -- that is the tail wagging the dog. Besides, I had thought that one of the goals of AST was to make it easier to experiment with language. Are you finding that it has a hard time even with the existing grammar? AFAICT, nested tuple arguments presented no problem for Jython or PyPy. Plus I don't think they are used very much (gut feeling, though, and not based on any grepping). python-dev grammar change proposals should probably be held to a higher standard than gut feeling, just toss it whims. [Nick] The fixes needed to make them work properly didn't seem all that ugly to me. That pretty much settles it the do it for the convenience of AST argument. [Andrew Bennetts] Please keep them! Twisted code uses them in places for Deferred callbacks that need to deal with multiple return values. And that settles the question of whether people are using them in real code. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
[Brett] Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? [Raymond] I am. I agree that we shouldn't mess with them in 2.x. Yet I think they are a candidate for being dropped from Py3K. While every feature is used by *someone* (as the feedback to Brett's query clearly shows) this one has several things against it. For every user who is fond of them there are probably ten who have never even heard of it. It's purely syntactic sugar (the only place where it's not trivial to replace is in a lambda). I've encountered quite a few people who had a hard time reading code that uses it. I personally prefer reading code that doesn't use this feature; for one thing, when this is used, you can't refer to a parameter by name. I'm not going to do the survey myself, but you could go through a representative code sample and see how it looks after doing the natural transformation. (In fact, this would be one 2.x - 3.0 transformation that could easily be automated if you can handle making up less-than-optimal names for the arguments.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
François Pinard wrote: The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. If the argument represents a coherent enough concept to be passed in as a tuple in the first place, it should be possible to find a meaningful name for it. Otherwise the elements should probably be passed in as separate arguments. Yet, if I was given the choice between nested tuple function arguments, and faster argument processing, the latter would win instantly. I believe that exactly the same bytecode results either way, so there's no speed advantage or penalty. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
On Sat, Sep 17, 2005 at 06:20:08PM -0700, Brett Cannon wrote: Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. I personally don't see them being overly useful thanks to assignment unpacking. Plus I don't think they are used very much (gut feeling, though, and not based on any grepping). Would anyone really throw a huge fit if they went away? I am willing to write a PEP for their removal in 2.6 with a deprecation in 2.5 if people are up for it. Otherwise I say they should definitely go in Python 3. Please keep them! Twisted code uses them in places for Deferred callbacks that need to deal with multiple return values. For instance, the twisted.cred.portal.Portal's login method returns Deferred that will be called with a tuple of (interface that the avatar implements, the avatar, a 0-arg logout callable), which naturally leads to functions like: def _cbAuthenticated(self, (iface, avatar, logout)): ... Based on a quick grep, there's well over 80 uses of tuple-unpacking in function declarations in Twisted's code base. There's almost certainly many more outside of Twisted; I know I have some code at work that uses this. So the short answer is: yes, we are attached to it, we will miss it. No guarantees about throwing fits, though wink. -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
