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 [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] test__locale on Mac OS X
test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4 branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we should list that as an expected failure on that platform? Skip ___ 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] 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 [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] test__locale on Mac OS X
[forgot to CC python-dev] On 9/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4 > branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we > should list that as an expected failure on that platform? > It passes on 10.4 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] 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 [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] 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 [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] 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 [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] removing nested tuple function parameters
[Raymond Hettinger] > [Brett] > > > Is anyone truly attached to nested tuple function parameters; ``def > > fxn((a,b)): print a,b``? > I am. I like the possibility and use it once in a while, but not often, at least not enough to beg for its preservation, or cry after its loss. Having to go without it, a mere tuple unpacking line near the beginning of the function would do. 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. Yet, if I was given the choice between nested tuple function arguments, and faster argument processing, the latter would win instantly. > > 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. A very funny image! :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] removing nested tuple function parameters
On 9/18/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [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. > I obviously didn't make the statement clear enough. The suport is already in the AST branch, it was just a statement Jeremy made once while starting to work on the implementaiton for the AST branch that I happen to still remember. They are already supported. The real trigger for this is introspection issues in terms of function paramters. Without changing the way the bytecode does things the only way to know the exact parameters is to inspect the bytecode. There are possible solutions than removal, but I personally find the use of nested tuple arguments hard to read and not widely known as Guido pointed out in another email. > > > > 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. > Which is why I asked first before doing a full-blown push for this. -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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: > Given the points you make, and the facts that both Python 3 and real > problems with continuing to scale down semiconductor chip feature sizes > are on the horizon, it seems that now would be an excellent time to start > work on this, with the goal of introducing it at the same time as Python > 3. > > a. Python 3.0 will break lots of code anyway, so the extension module >issue becomes far less significant. > > b. In x years time (x < 10?) it seems likely multiprocessor (MP) users >will be in the majority. (As a result, the uniprocessor (UP) slowdown >becomes less important in practice, and also Python has the opportunity >of avoiding the risk of being sidelined by a real or perceived lack of >MP performance.) That assumes a very specific model for how all that MP power is going to be used. I personally don't think the threaded programming model as found in Java works all that well; without locks you end up with concurrent modification errors, with locks you get deadlocks and livelocks. A typical programmer has a hard enough time keeping track of a bunch of variables being modified by a single thread; add multiple threads acting simultaneously on the same variables to the mix, and it's a nightmare. If my hunch is right, I expect that instead of writing massively parallel applications, we will continue to write single-threaded applications that are tied together at the process level rather than at the thread level. > c. Since time is needed to iron out bugs (and perhaps also to reimplememt >some pieces of code "from scratch"), very early in the life of Python 3 >seems like the least-worst time to begin work on such a change. > > I realize that not all algorithms (nor all computational problems) scale > well to MP hardware. Is it feasible to usefully compile both MP and a UP > binaries from one Python source code base? That's an understatement. I expect that *most* problems (even most problems that we will be programming 10-20 years from now) get little benefit out of MP. > (I'm also quite aware that the GIL does not prevent all means of achieving > efficient use of multiprocessors. I'm just concious that different > parellisation problems are presumably best expressed using different > tools, and that Python 3 and increased prevalance of MP systems might tip > the balance in favour of removing the GIL.) > > Of course, it still takes a (anti-)hero to step forward and do the work... Be my guest. Prove me wrong. Talk is cheap; instead of arguing my points (all of which can be argued ad infinitum), come back when you've got a working GIL-free Python. Doesn't have to be CPython-based -- C# would be fine too. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] list splicing
Hi, has anybody considered adding something like this: a = [1, 2] [ 'x', *a, 'y'] as syntactic sugar for a = [1, 2] [ 'x' ] + a + [ 'y' ]. Notes: - This is a common operation - To me, the splicing form looks much better than the concatenation form - It can be implemented more efficiently than a bunch of list concatenations - This would be similar to the "apply" feature [ foo(*a) ]. The '*' operator is reminiscent of dereferencing operators in C-derived languages. Alternatively it could be '@', like perl's implicit array splicing, and Lisp's ',@' in backquoted lists. - (I know "splicing" traditionally refers to something else in Python, but other languages refer to this as splicing, and the English definition of "splice" applies better to this.) -- Karl 2005-09-18 18:26 ___ 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] list splicing
Karl Chen wrote: > Hi, has anybody considered adding something like this: > a = [1, 2] > [ 'x', *a, 'y'] > > as syntactic sugar for > a = [1, 2] > [ 'x' ] + a + [ 'y' ]. > > Notes: > - This is a common operation is it? ___ 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] list splicing
Karl Chen wrote: > Hi, has anybody considered adding something like this: > a = [1, 2] > [ 'x', *a, 'y'] > > as syntactic sugar for > a = [1, 2] > [ 'x' ] + a + [ 'y' ]. You can write that as a = [1, 2] a[1:1] = a Greg ___ 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] 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 [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] list splicing
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > > Karl Chen wrote: > > > Hi, has anybody considered adding something like this: > > a = [1, 2] > > [ 'x', *a, 'y'] > > > > as syntactic sugar for > > a = [1, 2] > > [ 'x' ] + a + [ 'y' ]. > > > > Notes: > > - This is a common operation > > is it? Not in the code that I read/use. While "not all 3 line functions should be a builtin", "not all <5 character typing savings should be made syntax". - Josiah ___ 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] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
