Re: [Python-Dev] Positional-only parameters in Python

2018-01-21 Thread Mario Corchero 
Here is the proposal we have worked on (Pablo and I).

I've added Larry as co-author given that a good chunk of the content and
the idea comes from his PEP. Larry, if you don't want to appear as such
please let us know.

Thanks!

Rendered content:
https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst


PEP: 
Title: Python Positional-Only Parameters
Version: $Revision$
Last-Modified: $Date$
Author: Larry Hastings , Pablo Galindo
, Mario Corchero  
Discussions-To: Python-Dev 
Status:
Type:
Content-Type: text/x-rst
Created: 20-Jan-2018



Overview


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 arguments are mapped to these parameters based solely on
their position.

=
Rationale
=

Python has always supported positional-only parameters.
Early versions of Python lacked the concept of specifying
parameters by name, so naturally all parameters were
positional-only.  This changed around Python 1.0, when
all parameters suddenly became positional-or-keyword.
This allowed users to provide arguments to a function both
positionally or referencing the keyword used at the definition
of it. But, this is not always desired nor even available as
even in current versions of Python, many CPython
"builtin" functions still only accept positional-only arguments.

Even if positional arguments only in a function can be achieved
via using``*args`` parameters and extracting them one by one,
the solution is far from ideal and not as expressive as the one
proposed in this PEP, which targets to provide syntax to specify
accepting a specific number of positional-only parameters.
Additionally, this will bridge the gap we currently find between
builtin functions that today allows to specify positional-only
parameters and pure Python implementations that lack the
syntax for it.

-
Positional-Only Parameter Semantics In Current Python
-

There are many, many examples of builtins that only
accept positional-only parameters.  The resulting
semantics are easily experienced by the Python
programmer--just try calling one, specifying its
arguments by name::


>>> help(pow)
...
pow(x, y, z=None, /)
...
>>> pow(x=5, y=3)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: pow() takes no keyword arguments

Pow clearly expresses that its arguments are only positional
via the `/` marker, but this is at the moment only documentational,
Python developers cannot wright such syntax.

In addition, there are some functions with particularly
interesting semantics:

* ``range()``, which accepts an optional parameter
  to the *left* of its required parameter. [#RANGE]_

* ``dict()``, whose mapping/iterator parameter is optional and
  semantically must be positional-only.  Any externally
  visible name for this parameter would occlude
  that name going into the ``**kwarg`` keyword variadic
  parameter dict! [#DICT]_

Obviously one can simulate any of these in pure Python code
by accepting ``(*args, **kwargs)`` and parsing the arguments
by hand.  But this results in a disconnect between the
Python function signature and what it actually accepts,
not to mention the work of implementing said argument parsing.

==
Motivation
==

The new syntax will allow developers to further control how their
api can be consumed. It will allow to restrict the usage of keyword
Specify arguments by adding the new type of positional-only ones.

A similar PEP with a broader scope (PEP 457) was proposed
to define the syntax. This PEP builds on top of part of it
to define and provide an implementation for the ``/`` syntax on
function signatures.

=
The Current State Of Documentation For Positional-Only Parameters
=

The documentation for positional-only parameters is incomplete
and inconsistent:

* Some functions denote optional groups of positional-only arguments
  by enclosing them in nested square brackets. [#BORDER]_

* Some functions denote optional groups of positional-only arguments
  by presenting multiple prototypes with varying numbers of
  arguments. [#SENDFILE]_

* Some functions use *both* of the above approaches. [#RANGE]_ [#ADDCH]_

One more important idea to consider: currently in the documentation
there's no way to tell whether a function takes positional-only
parameters.  ``open()`` accepts keyword arguments, ``ord()`` does
not, but there is no way of telling just by reading the
documentation that this is true.


Syntax And Semantics


>From the "ten-thousand foot view", and ignoring ``*args`` and ``**kwargs``
for now,

Re: [Python-Dev] Positional-only parameters in Python

2018-01-21 Thread Oleg Broytman 
Hi! A few minor corrections below.

On Sun, Jan 21, 2018 at 01:59:49PM +, Mario Corchero  
wrote:
> Author: Larry Hastings , Pablo Galindo
> , Mario Corchero  
 ^
Add a space or a few here - this is the way for line wrapping in long
headers.

> introduces an asymetry on how parameter behavior is declared. Also, as the `\`

   \ -> /

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Positional-only parameters in Python

2018-01-21 Thread Mario Corchero 
Thanks, Oleg! Fixed that and a bunch more typos in the GitHub document.

https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst

On 21 January 2018 at 14:16, Oleg Broytman  wrote:

> Hi! A few minor corrections below.
>
> On Sun, Jan 21, 2018 at 01:59:49PM +, Mario Corchero <
> [email protected]> wrote:
> > Author: Larry Hastings , Pablo Galindo
> > , Mario Corchero  
>  ^
> Add a space or a few here - this is the way for line wrapping in long
> headers.
>
> > introduces an asymetry on how parameter behavior is declared. Also, as
> the `\`
>
>\ -> /
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/[email protected]
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariocj89%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] sys.settrace does not produce events for C functions

2018-01-21 Thread Pablo Galindo Salgado 
The docs for sys.settrace mention that:

>> event is a string: 'call', 'line', 'return', 'exception', >> 'c_call',
'c_return', or 'c_exception'

But in the code for ceval.c the only point where call_trace is invoked with
PyTrace_C_CALL or PyTrace_C_RETURN is under the C_TRACE macro. In this
macro this line prevents any function set up using sys.settrace to call
call_trace with the mentioned arguments:

if (tstate->use_tracing && tstate->c_profilefunc)

Notice that from the code of PyEval_SetTrace and PyEval_SetProfile, only
the later sets tstate->c_profilefunc and therefore only functions installed
using sys.setprofile will recieve a c_call for the event.

Xiang Zhan has suggested me to ask here what is the best course of action:

1) Document this behavior.

2) Fix the code.

This question is related to this issue:
https://bugs.python.org/issue17799

Thanks everyone for your time!

Pablo
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.settrace does not produce events for C functions

2018-01-21 Thread Guido van Rossum 
As I posted to the issue:

The reason not to pass C calls to the tracing function is that tracing
exists to support pdb and other debuggers, and pdb only cares about tracing
through Python code. So the docs should be updated.

On Sun, Jan 21, 2018 at 11:40 AM, Pablo Galindo Salgado  wrote:

> The docs for sys.settrace mention that:
>
> >> event is a string: 'call', 'line', 'return', 'exception', >> 'c_call',
> 'c_return', or 'c_exception'
>
> But in the code for ceval.c the only point where call_trace is invoked
> with PyTrace_C_CALL or PyTrace_C_RETURN is under the C_TRACE macro. In this
> macro this line prevents any function set up using sys.settrace to call
> call_trace with the mentioned arguments:
>
> if (tstate->use_tracing && tstate->c_profilefunc)
>
> Notice that from the code of PyEval_SetTrace and PyEval_SetProfile, only
> the later sets tstate->c_profilefunc and therefore only functions installed
> using sys.setprofile will recieve a c_call for the event.
>
> Xiang Zhan has suggested me to ask here what is the best course of action:
>
> 1) Document this behavior.
>
> 2) Fix the code.
>
> This question is related to this issue:
> https://bugs.python.org/issue17799
>
> Thanks everyone for your time!
>
> Pablo
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Positional-only parameters in Python

2018-01-21 Thread Larry Hastings 



On 01/21/2018 05:59 AM, Mario Corchero wrote:

Credit for making left option groups higher precedence goes to
Nick Coghlan. (Conversation in person at PyCon US 2013.)


Actually Argument Clinic has always given left option groups higher 
precedence.  This theoretically allows Argument Clinic to elegantly 
support the range builtin as "range([start,] stop, [step])", although 
nobody has bothered to actually convert range() to Clinic. (Which is 
reasonable--I don't think there's any reason to bother.)


Anyway, this acknowledgement is the only mention of "option groups" in 
the document.  Perhaps this was in reference to the now-abandoned idea 
of adding "option groups" to the language?  If so, this acknowledgement 
should probably be removed too.



//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Positional-only parameters in Python

2018-01-21 Thread Mario Corchero 
Ups, indeed, totally missed it. Removed it from
https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst

On 21 January 2018 at 21:44, Larry Hastings  wrote:

>
>
> On 01/21/2018 05:59 AM, Mario Corchero wrote:
>
> Credit for making left option groups higher precedence goes to
> Nick Coghlan. (Conversation in person at PyCon US 2013.)
>
>
> Actually Argument Clinic has always given left option groups higher
> precedence.  This theoretically allows Argument Clinic to elegantly support
> the range builtin as "range([start,] stop, [step])", although nobody has
> bothered to actually convert range() to Clinic.  (Which is reasonable--I
> don't think there's any reason to bother.)
>
> Anyway, this acknowledgement is the only mention of "option groups" in the
> document.  Perhaps this was in reference to the now-abandoned idea of
> adding "option groups" to the language?  If so, this acknowledgement should
> probably be removed too.
>
>
> */arry*
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 567 v3

2018-01-21 Thread Koos Zevenhoven 
On Thu, Jan 18, 2018 at 3:53 AM, Yury Selivanov 
wrote:

​[]


>
> Given the time frame of the Python 3.7 release schedule it was decided
> to defer this proposal to Python 3.8.
>

​It occurs to me that I had misread this to refer to the whole PEP.
Although I thought it's kind of sad that after all this, contextvars still
would not make it into 3.7, I also thought that it might be the right
decision. As you may already know, I think there are several problems with
this PEP. Would it be worth it to write down some thoughts on this PEP in
the morning?

-- Koos​



-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

2018-01-21 Thread Eric V. Smith 

On 1/7/2018 12:25 PM, Guido van Rossum wrote:
On Sun, Jan 7, 2018 at 9:09 AM, Eric V. Smith > wrote:


On 1/3/2018 1:17 PM, Eric V. Smith wrote:

I’ll open an issue after I have time to read this thread and
comment on it.


https://bugs.python.org/issue32513 
I need to think though how __eq__ and __ne__ work, as well as the
ordering operators.

My specific concern with __ne__ is that there's one flag to control
their generation, but python will use "not __eq__" if you don't
provide __ne__. I need to think through what happens if the user
only provides __eq__: does dataclasses do nothing, does it add
__ne__, and how does this interact with a base class that does
provide __ne__.


Maybe dataclasses should only ever provide __eq__ and always assume 
Python's default for __ne__ kicks in? If that's not acceptable (maybe 
there are cases where a user did write an explicit __ne__ that needs to 
be overridden) I would recommend the following rule:


- If there's an __eq__, don't do anything (regardless of whether there's 
an __ne__)
- If there no __eq__ but there is an __ne__, generate __eq__ but don't 
generate __ne__

- If neither exists, generate both


I've added my proposal on issue 32513:
https://bugs.python.org/issue32513#msg310392

It's long, so I won't repeat it here. The only really confusing part is 
__hash__ and its interaction with __eq__.


Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com