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 wh
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 mor
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 wh
"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 progra
Andrew Koenig wrote:
> 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.
There can certainly be value in type-checking parameters and
return values, but in this case, I think th
> 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 the
> 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 pro
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.
--- Buc
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
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
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
> shou
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 tup
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 meaningfu
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 convenien
[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 with
> [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
[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 t
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
* 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
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 f
Brett Cannon wrote:
> Is anyone truly attached to nested tuple function parameters; ``def
> fxn((a,b)): print a,b``?
I find 54 instances in my Python installation.
>grep -r "def.*([^=]*([^)]*,[^)]*).*):" *
aifc.py:def setparams(self, (nchannels, sampwidth, framerate,
nframes, comptype, compna
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 th
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
23 matches
Mail list logo
