On 10 Oct 2013 12:40, "Greg Ewing" wrote:
>
> On 10/10/13 11:57, Nick Coghlan wrote:
>>
>> PEP title: Representation of positional-only parameters
>
>
> Something like "Notation for documenting positional-only parameters"
> would make it even clearer that this is not a proposal for adding
> to the
On 10/10/13 11:57, Nick Coghlan wrote:
PEP title: Representation of positional-only parameters
Something like "Notation for documenting positional-only parameters"
would make it even clearer that this is not a proposal for adding
to the syntax of the language.
--
Greg
On 10/10/13 09:51, Larry Hastings wrote:
Perhaps we could add (egad, no, I can't believe I'm saying this) a new
built-in function that tells you whether or not a local variable has been
assigned to yet?
def range([start,] stop, [step], /):
if not bound(start):
start = 0
On Wed, Oct 09, 2013 at 04:15:36PM +0200, Larry Hastings wrote:
> >- parameters in optional groups should just have an implied "=None"
> >that can be overriden if desired.
> >
>
> No no no! You can't have a default value, and you definitely couldn't
> use None.
>
> range() decides what its ar
On 10 Oct 2013 00:17, "Larry Hastings" wrote:
>
>
> On 10/09/2013 11:46 AM, Nick Coghlan wrote:
>>
>> Generally, it needs to be a bit clearer that the intent of the PEP isn't
to say "let's do this", it's to be explicit that acceptance of the Argument
Clinic PEP severely constrains the design space
On Wed, Oct 9, 2013 at 12:20 PM, Eric Snow wrote:
> For me the allure of positional-only arguments lies in the following:
>
> 1. not having to roll my own *args handling;
> 2. not having to clutter up my code with the *args handling;
> 3. not having to handle positional-or-keyword params with *arg
On Wed, Oct 09, 2013 at 09:46:00PM +0100, Mark Shannon wrote:
> There is no need to create an "undefined" value.
> Rather than define a parameter by assigning a fake value, just don't
> define it. We already do this for non-parameter locals and it could be
> extended to parameters.
>
> 'range'
On Wed, Oct 09, 2013 at 02:25:18PM -0400, Terry Reedy wrote:
> Unlike Georg, I think '/' is plausibly ok. You should, however,
> explicitly say in the PEP that it was selected not randomly but by rough
> analogy. Division (/) is the inverse of multiplication (*), and
> positional-only is sort o
On 10/09/2013 10:46 PM, Mark Shannon wrote:
There is no need to create an "undefined" value.
Rather than define a parameter by assigning a fake value, just don't
define it. We already do this for non-parameter locals and it could be
extended to parameters.
'range' would be defined thus:
def
On 09/10/13 00:33, Larry Hastings wrote:
I've contributed a new PEP to humanity. I include the RST for your
reading pleasure below, but you can also read it online here:
http://www.python.org/dev/peps/pep-0457/
Overall I'm in favour.
As a motivation for positional only parameters, consi
On 10/09/2013 08:25 PM, Terry Reedy wrote:
I am sure that he has rejected any backward-incompatible change, as
would I. Allowing keyword passing *is* compatible, so I would not
guess about that.
I don't know where to look for this discussion, and I read it quite some
time ago. So I this is
On 10/09/2013 07:50 PM, Eli Bendersky wrote:
I'm not sure what you call "parsing". This?
>>> def myfoo(*args): a, b = args; print("%s, then %s" % (a, b))
From the Argument Clinic PEP (436):
The primary implementation of Python, "CPython", is written in a
mixture of Python and C. One imp
On 9 October 2013 18:00, Ethan Furman wrote:
> On 10/09/2013 09:05 AM, Paul Moore wrote:
>>
>>
>> I remain -1 on forcing "Python syntax" to support all of these odd
>> corner cases (and positional-only is already a corner case,
>> range/addch are seriously so).
>
>
> Considering the prevalence of
On Wed, Oct 9, 2013 at 11:38 AM, R. David Murray wrote:
> It seems to me, then, that the solution for the
> handle-the-ugly-existing-practice-groups issue is to make case (3)
> (pydoc prototype) match the convention that we have arrived at for the
> documentation: multiple signature lines to repr
On 10/9/2013 1:05 PM, Larry Hastings wrote:
First, if you're proposing to change the signature of range()... well,
good luck. Any proposals I made like that got shot down almost
immediately. I /think/ Guido said somewhere "range isn't changing.
deal with it.", though I admit I don't have a ref
On Wed, Oct 9, 2013 at 8:53 AM, Larry Hastings wrote:
> But that's not how addch works. addch counts how many arguments it
> received; if it is called with one or two, it does one thing, and if it's
> called with three or four it does something else. You can't duplicate these
> semantics with
>
Am 09.10.2013 19:00, schrieb Ethan Furman:
> On 10/09/2013 09:05 AM, Paul Moore wrote:
>>
>> I remain -1 on forcing "Python syntax" to support all of these odd corner
>> cases (and positional-only is already a corner case, range/addch are
>> seriously so).
>
> Considering the prevalence of positi
On Tue, Oct 8, 2013 at 4:33 PM, Larry Hastings wrote:
>
> I've contributed a new PEP to humanity. I include the RST for your
> reading pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
>
>
>
Hi Larry,
My comments below. TL;DR I'm -1, but trying t
On 10/09/2013 09:05 AM, Paul Moore wrote:
I remain -1 on forcing "Python syntax" to support all of these odd
corner cases (and positional-only is already a corner case,
range/addch are seriously so).
Considering the prevalence of positional-only functions and methods, I don't think they can be
On Wed, 09 Oct 2013 17:05:12 +0100, Paul Moore wrote:
> On 9 October 2013 16:07, Larry Hastings wrote:
> > On 10/09/2013 04:38 PM, Paul Moore wrote:
> >
> > For that matter, why does the syntax used by Argument Clinic have to
> > be the same as whatever future syntax is used in Python? If indeed,
On 10/9/2013 7:45 AM, Anders J. Munch wrote:
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-onl
Sorry if I meddle, but wouldn't be better to include a module in the
standard library that provides functions and classes to help parsing
*args and **kwargs?
This way you can avoid defining a new syntax, new builtin objects and so on.
___
Python-Dev mail
On 10/09/2013 06:48 PM, Terry Reedy wrote:
On 10/9/2013 9:51 AM, Larry Hastings wrote:
range() in
PyPy accepts keyword parameters, and in fact this works:
range(9, step=2)
That's way illegal in CPython.
But Georg's point is that it does not have to be illegal in CPython.
Range, in part
On 10/9/2013 9:51 AM, Larry Hastings wrote:
Again, I don't expect this syntax to be implemented any time soon. But
this does raise a mild sore point: Maciej and Armin Rigo tell me that
PyPy's implementation of range() looks like this:
def range(x, y=None, step=None):
The "None" above is no
On 9 October 2013 16:07, Larry Hastings wrote:
> On 10/09/2013 04:38 PM, Paul Moore wrote:
>
> For that matter, why does the syntax used by Argument Clinic have to
> be the same as whatever future syntax is used in Python? If indeed,
> any ever is? What benefit do we get given the cost (rushing in
On 10/09/2013 08:09 AM, Larry Hastings wrote:
On 10/09/2013 04:45 PM, Anders J. Munch wrote:
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-only.
For example, the docstring of sorted:
sorted(iterable, key=None, r
2013/10/9 Larry Hastings :
> On 10/09/2013 04:24 PM, Benjamin Peterson wrote:
>
> My proposed syntax is a little complex--but complex is better than
> complicated and inconsistent and undocumented and inconvenient, which is
> what we have now.
>
> Certainly the argument conventions of these functio
On 10/09/2013 04:45 PM, Anders J. Munch wrote:
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-o
On 9 October 2013 15:53, Larry Hastings wrote:
> My goal in writing the PEP was to codify existing practice, which meant
> reflecting these (annoying!) corner cases accurately.
That's fair. But I would argue that we very much don't want to
encourage anyone ever duplicating that practice with new
Am 09.10.2013 16:53, schrieb Larry Hastings:
> On 10/09/2013 04:26 PM, Georg Brandl wrote:
>>> I realize you are -1 on the proposal in general, but I'd be very interested
>>> if
>>> you could propose an alternate approach where I didn't need "a new spelling
>>> for
>>> None" as you put it.
>> I t
On 10/09/2013 04:38 PM, Paul Moore wrote:
For that matter, why does the syntax used by Argument Clinic have to
be the same as whatever future syntax is used in Python? If indeed,
any ever is? What benefit do we get given the cost (rushing in a
syntax that nobody is actually convinced we even need
On 10/09/2013 04:24 PM, Benjamin Peterson wrote:
My proposed syntax is a little complex--but complex is better than
complicated and inconsistent and undocumented and inconvenient, which is
what we have now.
Certainly the argument conventions of these functions are not
undocumented, so wonder wha
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-only.
For example, the docstring of sorted:
sorte
On 10/09/2013 04:26 PM, Georg Brandl wrote:
I realize you are -1 on the proposal in general, but I'd be very interested if
you could propose an alternate approach where I didn't need "a new spelling for
None" as you put it.
I think I would make Steven's proposed syntax mandatory: let the impleme
Le Wed, 9 Oct 2013 15:40:08 +0100,
Paul Moore a écrit :
> On 9 October 2013 15:30, Larry Hastings wrote:
> > Only if I can stop writing other PEPs and replying to their
> > discussion threads!
>
> So once again, why is this new PEP needed? :-)
Procrastination perhaps ;-)
> Paul
__
On 9 October 2013 15:30, Larry Hastings wrote:
> Only if I can stop writing other PEPs and replying to their discussion
> threads!
So once again, why is this new PEP needed? :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
On 9 October 2013 13:38, Benjamin Peterson wrote:
>> Generally, it needs to be a bit clearer that the intent of the PEP isn't to
>> say "let's do this", it's to be explicit that acceptance of the Argument
>> Clinic PEP severely constrains the design space for possible solutions if we
>> ever *did*
On Oct 9, 2013 4:04 AM, "Paul Moore" wrote:
> But if the intention is that any attempt to add the functionality to
> Python will be constrained to use the syntax here, surely that means
> we need to have all of the usability arguments and bikeshedding *now*.
> otherwise the opportunity is lost?
I
On 10/09/2013 03:36 PM, Antoine Pitrou wrote:
I think it would be better to exercise [Argument Clinc] first as an internal
tool,
eliminate any possible quirks and issues, and *then* perhaps expose it
as a public API.
By the way, do you think it'll be ready for 3.4?
Only if I can stop writing
Am 09.10.2013 15:56, schrieb Larry Hastings:
> On 10/09/2013 07:15 AM, Georg Brandl wrote:
>> We have quite a large
>> amount of C functions with positional-only parameters. Adding a "/"
>> to each of those is a) a tedious task and b) probably not helpful for
>> a lot of people:
>
> I volunteer t
2013/10/9 Larry Hastings :
>
> On 10/09/2013 03:31 AM, Benjamin Peterson wrote:
>
> 2013/10/8 Larry Hastings :
>
> This PEP proposes a backwards-compatible syntax that should
> permit implementing any builtin in pure Python code.
>
> This is rather too strong. You can certainly implement them; you
On 10/09/2013 11:46 AM, Nick Coghlan wrote:
Generally, it needs to be a bit clearer that the intent of the PEP
isn't to say "let's do this", it's to be explicit that acceptance of
the Argument Clinic PEP severely constrains the design space for
possible solutions if we ever *did* implement Pyt
On Wed, Oct 9, 2013 at 8:15 AM, Georg Brandl wrote:
>
> [...]
>
> Rather, I would try to make as many C functions as possible "regular",
See http://bugs.python.org/issue8706 and http://bugs.python.org/issue8350
Best Regards,
Ezio Melotti
___
Python-De
On 10/09/2013 07:15 AM, Georg Brandl wrote:
We have quite a large
amount of C functions with positional-only parameters. Adding a "/"
to each of those is a) a tedious task and b) probably not helpful for
a lot of people:
I volunteer to ensure that the "/"s are added if this PEP is accepted.
On 10/09/2013 07:48 AM, Eric Snow wrote:
The PEP doesn't mention anything about inspect.Signature, which
already supports positional-only parameters. It should.
Well, inspect.Signature support for positional-only parameters is
currently insufficient to express all of Python's builtins. As I
On 10/09/2013 03:31 AM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings :
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly implement them; you just
have to implement the argument pars
Am 09.10.2013 15:32, schrieb Larry Hastings:
> On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
>> Why does a syntax need to be reserved? Documentation conventions and
>> the syntax of internal tools like argument clinic may be changed any
>> time we like.
>
> If Argument Clinic is accepted, and s
Le Wed, 09 Oct 2013 15:32:10 +0200,
Larry Hastings a écrit :
> On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
> > Why does a syntax need to be reserved? Documentation conventions and
> > the syntax of internal tools like argument clinic may be changed any
> > time we like.
>
> If Argument Clini
On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
Why does a syntax need to be reserved? Documentation conventions and
the syntax of internal tools like argument clinic may be changed any
time we like.
If Argument Clinic is accepted, and ships with Python, my expectation is
that it would cease
2013/10/9 Nick Coghlan :
> The PEP needs to state more clearly up front (preferably in the title) that
> it's about *reserving* a Python level syntax that matches the syntax we
> worked out for Argument Clinic at PyCon US. Explicitly stating that the
> requirements that drive the Argument Clinic de
On 9 October 2013 10:46, Nick Coghlan wrote:
> The PEP needs to state more clearly up front (preferably in the title) that
> it's about *reserving* a Python level syntax that matches the syntax we
> worked out for Argument Clinic at PyCon US. Explicitly stating that the
> requirements that drive t
The PEP needs to state more clearly up front (preferably in the title) that
it's about *reserving* a Python level syntax that matches the syntax we
worked out for Argument Clinic at PyCon US. Explicitly stating that the
requirements that drive the Argument Clinic design are to support the
signature
On 10/09/2013 03:57 AM, Joao S. O. Bueno wrote:
def a([b],/,**kw):
print (b)
does calling "a(b=5)" should raise a TypeError, or put "5" in
"""kw["b"]""" and leave
"b" as "undefined" ?
The latter. This is how they are "similarly to *args and **kwargs":
>>> def foo(*a, **kw):
...
On Wed, 09 Oct 2013 01:33:26 +0200
Larry Hastings wrote:
>
> I've contributed a new PEP to humanity. I include the RST for your
> reading pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
Only skimmed through the PEP, but -1 on the whole id
On Tue, Oct 8, 2013 at 9:02 PM, Terry Reedy wrote:
> I am for having a way to succintly properly describe the signature of C in
> the manual and docstrings and help output. As it is now, the only safe thing
> to do, without trial and exception, is to assume positional only unless one
> knows other
On Tue, Oct 8, 2013 at 5:33 PM, Larry Hastings wrote:
>
> I've contributed a new PEP to humanity. I include the RST for your reading
> pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
>
>
> Discuss,
The PEP doesn't mention anything about inspect.
On 10/08/2013 09:55 PM, Benjamin Peterson wrote:
2013/10/8 Ethan Furman :
On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
2013/10/8 Terry Reedy :
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings :
This PEP proposes a backwards-compatible syntax that should
permi
Am 09.10.2013 01:33, schrieb Larry Hastings:
>
> I've contributed a new PEP to humanity. I include the RST for your reading
> pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
...
>* Documentation can clearly, unambiguously, and
> c
2013/10/8 Ethan Furman :
> On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
>>
>> 2013/10/8 Terry Reedy :
>>>
>>> On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings :
>
>
> This PEP proposes a backwards-compatible syntax that should
> permit imple
On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
2013/10/8 Terry Reedy :
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings :
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. Yo
2013/10/8 Terry Reedy :
> On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
>>
>> 2013/10/8 Larry Hastings :
>>>
>>> This PEP proposes a backwards-compatible syntax that should
>>> permit implementing any builtin in pure Python code.
>>
>>
>> This is rather too strong. You can certainly implement them
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings :
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly implement them; you just
have to implement the argument parsin
I am -1 for the optional parameters and grouping stuff -
no need to make complicated stuff easier to do just because "range" semantics
is strange to start with.
(And one can implement a range-like funciton explictly parsing
the parameters if needed be.)
As for the "/" delimiting positional only p
2013/10/8 Larry Hastings :
> This PEP proposes a backwards-compatible syntax that should
> permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly implement them; you just
have to implement the argument parsing yourself. Python's
call/signature syntax is a
On 10/08/2013 05:15 PM, Steven D'Aprano wrote:
On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote:
The obvious solution: add a new singleton constant to Python
that is passed in when a parameter is not mapped to an argument.
I propose that the value be called called ``undefined``,
a
A very quick reply, more tomorrow.
On 10/09/2013 02:15 AM, Steven D'Aprano wrote:
I note that in your example above, you put the comma outside the square
bracket:
def addch([y, x,] ch, [attr], /):
which seems perfectly readable to me.
It becomes less readable / more tiresome with nested gro
On 10/08/2013 04:33 PM, Larry Hastings wrote:
I've contributed a new PEP to humanity. I include the RST for your reading
pleasure below, but you can also read it
online here:
http://www.python.org/dev/peps/pep-0457/
I like it! :)
Feedback below...
==
N
On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote:
> This PEP proposes a syntax for positional-only parameters in Python.
> Positional-only parameters are parameters without an externally-usable
> name; when a function accepting positional-only parameters is called,
> positional argum
I've contributed a new PEP to humanity. I include the RST for your
reading pleasure below, but you can also read it online here:
http://www.python.org/dev/peps/pep-0457/
Discuss,
//arry/
-
PEP: 457
Title: Syntax For Positional-Only Parameters
Version: $Revision$
Last-Modified: $D
69 matches
Mail list logo
