What's going on with PEP 448 - Additional Unpacking Generalizations ?

[Neil Girdhar]

It says "standards track", but it doesn't seem to work in Python 3.4.  I am really looking forward to this!  Any chance we can get a from __future__ for inclusion in 3.4?  Or maybe it can make it into 3.5?

Best,

Neil

[Chris Angelico]

It also says "Status: Draft", which means it hasn't (yet) been
accepted as part of the language. That means it's definitely not going
to get into 3.4; it might be able to get into 3.5 if it gets approved
very shortly, but the time frame is narrowing. Last chance to get it
into 3.5 would be Beta 1, scheduled for May 24th (see PEP 478), and
ideally it should get into an alpha before that.

Would be nice to actually have it land somewhere. Seems it's been
proposed for every Python version since 3.0.

ChrisA
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Guido van Rossum]

I see no big problem with it from a language design perspective, but also no reason to commit huge resources to it -- it's all very much in the "nice to have" category. Unless you find a champion who wants to review the (old) patch and so on, what's the point of accepting the PEP?

[Neil Girdhar]

Is there any way that I can help?

[Neil Girdhar]

Fixed it on my system!  (OS X Yosemite)

http://hamelot.co.uk/programming/osx-gcc-dispatch_block_t-has-not-been-declared-invalid-typedef/

Okay, I'll get working on this patch soon.

Thanks,

Neil

On Mon, Jan 19, 2015 at 5:39 PM, Chris Angelico <ros...@gmail.com> wrote:

On Tue, Jan 20, 2015 at 9:22 AM, Chris Angelico <ros...@gmail.com> wrote:
> Skipped tests are normal; if you're building on a system that doesn't
> have GDB, it'll skip test_gdb, because there's nothing to test. The
> failing tests, though, are likely to be a problem. What environment
> are you building on? Are you experienced with building Python from
> source?

FWIW, here's my 'make test' summary. Debian Wheezy, Python 3.5 (tip),
amd64 architecture.

379 tests OK.
1 test altered the execution environment:
    test_warnings
11 tests skipped:
    test_devpoll test_gdb test_kqueue test_msilib test_ossaudiodev
    test_startfile test_tk test_ttk_guionly test_winreg test_winsound
    test_zipfile64

ChrisA

[Neil Girdhar]

I've been working on the patch for PEP 448.  Are the restrictions on the order of arguments in a function call partially or fully lifted?

Currently, we can do:

def f(a, b, c, d):

    pass

f(1, d=4, *[1,2], 2, **{})

After PEP 448 can we do:

f(1, d=4, *[2], c=3, **{})

?

[Neil Girdhar]

oops, I mean, currently we can do

f(1, d=4, *[1,2], **{})

I'm asking about the others…  

--

---
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/J99EFY1D1nI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python-ideas...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

--

---
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/J99EFY1D1nI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python-ideas...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neil Girdhar]

Also, if after PEP 448, you can do

f(*a, *b, *c)

and you can always do

f(a,

  b,

  c,

 )

then why shouldn't you be able to do

f(*a,

  *b,

  *c,

 )

?

[Joshua Landau]

On 20 January 2015 at 11:02, Neil Girdhar <miste...@gmail.com> wrote:
> I've been working on the patch for PEP 448. Are the restrictions on the
> order of arguments in a function call partially or fully lifted?

I believe we settled on

function(
argument or *args, argument or *args, ...,
kwargument or *args, kwargument or *args, ...,
kwargument or **kwargs, kwargument or **kwargs, ...
)

as the most likely candidate.

Guido said
> Regarding the decision about the allowable syntax for argument lists,
> I prefer to keep the existing restriction

See https://mail.python.org/pipermail/python-ideas/2013-July/021872.html
for the discussion.

> Currently, we can do:
> def f(a, b, c, d):
> pass
>
> f(1, d=4, *[1,2], 2, **{})
>
> After PEP 448 can we do:
>
> f(1, d=4, *[2], c=3, **{})
>
> ?

These should be OK, if I've understood the sentiment.

[Joshua Landau]

On 20 January 2015 at 14:18, Joshua Landau <jos...@landau.ws> wrote:
> On 20 January 2015 at 11:02, Neil Girdhar <miste...@gmail.com> wrote:
>>
>> f(1, d=4, *[1,2], 2, **{})
>

> These should be OK, if I've understood the sentiment.

I meant, of course, to reply to your fixed version:

>> f(1, d=4, *[1,2], **{})

wrt.

>> Also, if after PEP 448, you can do
>>
>> f(*a, *b, *c)
>>
>> and you can always do
>>
>> f(a,
>> b,
>> c,
>> )
>>
>> then why shouldn't you be able to do
>>
>> f(*a,
>> *b,
>> *c,
>> )

I see no reason this shouldn't work.

[Neil Girdhar]

Ok, the final comma means a small change to the grammar.

In summary of the other rules:

positional argument never follow keyword arguments

iterable argument unpacking never follow keyword argument unpacking

Neither rule is truly necessary, but ok for now.

Best,

Neil

[Guido van Rossum]

The PEP hasn't been accepted yet AFAIK...  I'm generally okay with allowing multiple *x things (except in an *unpack* position of course) but I still don't think we should be mixing positional and keyword args. So, no f(a, b=2, c), nor f(a, b=2, *c).

--Guido van Rossum (python.org/~guido)

[Joshua Landau]

On 20 January 2015 at 16:38, Guido van Rossum <gu...@python.org> wrote:
> The PEP hasn't been accepted yet AFAIK... I'm generally okay with allowing
> multiple *x things (except in an *unpack* position of course) but I still
> don't think we should be mixing positional and keyword args. So, no f(a,
> b=2, c), nor f(a, b=2, *c).
>

f(a, b=2, *c) is currently legal as both a call and as a definition:

a, *c = 1, 2, 3

def f(*args, **kwargs):
print(args, kwargs)

f(a, b=2, *c)
#>>> (1, 2, 3) {'b': 2}

def f(a, b=2, *c):
print(a, b, c)

f(1, 2, 3)
#>>> 1 2 (3,)

So I imagine that's staying (or, at least, this PEP isn't removing
it). I don't think anyone is (yet) arguing for f(a, b=2, c).

[Neil Girdhar]

Okay, so: positional arguments neither follow keyword arguments nor keyword argument unpackings; iterable argument unpackings never follow keyword argument unpackings.

 

 

[Guido van Rossum]

OK. I don't like arg unpackings after keyword args, for the same reason plain positional args aren't allowed after keyword args, but I guess I didn't pay attention when it was introduced, so we're stuck with it now, it's not the end of the world, and at least the definition is clear (collect all positional args first, then handle keyword args).

--Guido van Rossum (python.org/~guido)

[Joshua Landau]

On 20 January 2015 at 16:51, Neil Girdhar <miste...@gmail.com> wrote:
>
> Okay, so: positional arguments neither follow keyword arguments nor keyword
> argument unpackings; iterable argument unpackings never follow keyword
> argument unpackings.

Yep. :)

Incidentally, this confusion was why I originally suggested the more
relaxed rules. It's probably not a problem for the end-user though,
because nobody does it. It would probably be fine from an
implementation perspective, too, now that I know how ast_for_call
works.

[Neil Girdhar]

Exactly…

[Neil Girdhar]

I believe I have finally finished the work on the patch for PEP 448 (http://bugs.python.org/issue2292).  How do we get the PEP approved?  What else would we need to check it into Python?

Best,

Neil

[Guido van Rossum]

Thanks very much for your work! I am CC'ing python-dev to see if there are any last calls for PEP 448. Assuming no material objection appear to the new syntax and semantics, I can approve the PEP later this week. To get it committed, you need one of the active committers to give you a code review (waiting for me would mean waiting forever). Maybe Antoine, Benjamin or Victor?