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
"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
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
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-
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-De
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 ef
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 goa
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
[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?
* 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
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
Python-Dev@p
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
16 matches
Mail list logo
