Re: [Python-Dev] PEP 484 proposal: don't default to Optional if argument default is None

2017-05-10 Thread Ivan Levkivskyi 
There is a discrepancy now between PEP 484 and PEP 526:

def f(x: int = None): ... # OK
x: int = None # Error

I think the two rules should be "in sync", in view of this I agree with the
proposal.

Concerning verbosity and a long name Optional there are many reasonable
workarounds.
One is already mentioned from typing import Optional as O. Another
(unrelated to `` = None`` pattern)
is https://github.com/python/typing/issues/420 that allows to avoid
Optional altogether in patterns like this:

def func(x: Optional[X]) -> Optional[Y]:
if x is None:
return None
# do some stuff with 'x'

With @maybe decorator proposed in
https://github.com/python/typing/issues/420
this will be simplified to:

@maybe
def func(x: X) -> Y:
if x is None:
return None
# do some stuff with 'x'

Even if @maybe will not make it to typing, one still can define such (or
similar) decorators
(especially with @decorated_type and extended Callable syntax).

In view of this, I think verbosity is not a problem at all.

--
Ivan
___
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 484 update proposal: annotating decorated declarations

2017-05-10 Thread Jukka Lehtosalo 
Even if Callable types will soon support keyword arguments, the syntax for
Callables will look quite different from function definitions and this
inconsistency may hurt readability, at least for more complex signatures.
We could work around this by using the def syntax for the declared type of
a decorator. For example:

@declared_type
def session(url: str) -> ContextManager[DatabaseSession]: ...  # Explicit
'...'

@contextmanager
def session(url: str) -> Iterator[DatabaseSession]:
s = DatabaseSession(url)
...

This would be quite similar to how overloads work, so there is a precedent
for something like this. We could require or recommend that the declared
type comes immediately before the implementation so that the entire
definition of a single function would not be too spread out.

This won't help if the decorated type is not a callable. We could support
this use case by using the normal variable annotation syntax:

thing: Decorated  # Declared type of 'thing'

@decorator
def thing() -> int:
...

Jukka

On Wed, May 10, 2017 at 12:27 AM, Naomi Seyfer  wrote:

> Stay tuned for the pep that allows callable to take keyword args.
>
> On May 9, 2017, at 3:59 PM, Brett Cannon  wrote:
>
> The idea seems reasonable to me when viewing type hints as a form of
> documentation as it helps remind people how they are expected to call the
> final function.
>
> One worry I do have, though, is Callable doesn't support keyword-only
> parameters, so declared_type won't work in all cases without Callable
> gaining such support (for those that don't know, Callable didn't start with
> that support as Callable has been meant for callback scenarios up to this
> point).
>
> On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:
>
>> There's a PR to the peps proposal here:
>> https://github.com/python/peps/pull/242
>>
>> The full text of the current proposal is below. The motivation for this
>> is that for complex decorators, even if the type checker can figure out
>> what's going on (by taking the signature of the decorator into account),
>> it's sometimes helpful to the human reader of the code to be reminded of
>> the type after applying the decorators (or a stack thereof). Much
>> discussion can be found in the PR. Note that we ended up having `Callable`
>> in the type because there's no rule that says a decorator returns a
>> function type (e.g. `property` doesn't).
>>
>> This is a small thing but I'd like to run it by a larger audience than
>> the core mypy devs who have commented so far. There was a brief discussion
>> on python-ideas (my original
>> ,
>> favorable reply
>>  by
>> Nick, my response
>> ).
>>
>> Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan
>> Levkivskyi and Jukka Lehtosalo.
>>
>> If there's no further debate here I'll merge it into the PEP and an
>> implementation will hopefully appear in the next version of the typing
>> module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
>>
>> Here's the proposed text (wordsmithing suggestions in the PR please):
>>
>> +Decorators
>> +--
>> +
>> +Decorators can modify the types of the functions or classes they
>> +decorate. Use the ``decorated_type`` decorator to declare the type of
>> +the resulting item after all other decorators have been applied::
>> +
>> + from typing import ContextManager, Iterator, decorated_type
>> + from contextlib import contextmanager
>> +
>> + class DatabaseSession: ...
>> +
>> + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
>> + @contextmanager
>> + def session(url: str) -> Iterator[DatabaseSession]:
>> + s = DatabaseSession(url)
>> + try:
>> + yield s
>> + finally:
>> + s.close()
>> +
>> +The argument of ``decorated_type`` is a type annotation on the name
>> +being declared (``session``, in the example above). If you have
>> +multiple decorators, ``decorated_type`` must be topmost. The
>> +``decorated_type`` decorator is invalid on a function declaration that
>> +is also decorated with ``overload``, but you can annotate the
>> +implementation of the overload series with ``decorated_type``.
>> +
>>
>> --
>> --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/
>> brett%40python.org
>>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jlehtosalo%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
https

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

2017-05-10 Thread Naomi Seyfer 
I think you're right that the redefinition style is easier to read for 
complicated stuff... It also seems more complicated in a way I can't put my 
finger on. 

The overload precedent helps. 

Currently leaning towards Jukka being right, vague worries about extra 
complication be damned. 

Readability is more important. 

> On May 10, 2017, at 5:23 AM, Jukka Lehtosalo  wrote:
> 
> Even if Callable types will soon support keyword arguments, the syntax for 
> Callables will look quite different from function definitions and this 
> inconsistency may hurt readability, at least for more complex signatures. We 
> could work around this by using the def syntax for the declared type of a 
> decorator. For example:
> 
> @declared_type
> def session(url: str) -> ContextManager[DatabaseSession]: ...  # Explicit 
> '...'
> 
> @contextmanager
> def session(url: str) -> Iterator[DatabaseSession]:
> s = DatabaseSession(url)
> ...
> 
> This would be quite similar to how overloads work, so there is a precedent 
> for something like this. We could require or recommend that the declared type 
> comes immediately before the implementation so that the entire definition of 
> a single function would not be too spread out.
> 
> This won't help if the decorated type is not a callable. We could support 
> this use case by using the normal variable annotation syntax:
> 
> thing: Decorated  # Declared type of 'thing'
> 
> @decorator
> def thing() -> int:
> ...
> 
> Jukka
> 
>> On Wed, May 10, 2017 at 12:27 AM, Naomi Seyfer  wrote:
>> Stay tuned for the pep that allows callable to take keyword args. 
>> 
>>> On May 9, 2017, at 3:59 PM, Brett Cannon  wrote:
>>> 
>>> The idea seems reasonable to me when viewing type hints as a form of 
>>> documentation as it helps remind people how they are expected to call the 
>>> final function.
>>> 
>>> One worry I do have, though, is Callable doesn't support keyword-only 
>>> parameters, so declared_type won't work in all cases without Callable 
>>> gaining such support (for those that don't know, Callable didn't start with 
>>> that support as Callable has been meant for callback scenarios up to this 
>>> point).
>>> 
 On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:
 There's a PR to the peps proposal here:
 https://github.com/python/peps/pull/242
 
 The full text of the current proposal is below. The motivation for this is 
 that for complex decorators, even if the type checker can figure out 
 what's going on (by taking the signature of the decorator into account), 
 it's sometimes helpful to the human reader of the code to be reminded  of 
 the type after applying the decorators (or a stack thereof). Much 
 discussion can be found in the PR. Note that we ended up having `Callable` 
 in the type because there's no rule that says a decorator returns a 
 function type (e.g. `property` doesn't).
 
 This is a small thing but I'd like to run it by a larger audience than the 
 core mypy devs who have commented so far. There was a brief discussion on 
 python-ideas (my original, favorable reply by Nick, my response).
 
 Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan 
 Levkivskyi and Jukka Lehtosalo.
 
 If there's no further debate here I'll merge it into the PEP and an 
 implementation will hopefully appear in the next version of the typing 
 module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
 
 Here's the proposed text (wordsmithing suggestions in the PR please):
 
 +Decorators
 +--
 +
 +Decorators can modify the types of the functions or classes they
 +decorate. Use the ``decorated_type`` decorator to declare the type of
 +the resulting item after all other decorators have been applied::
 +
 + from typing import ContextManager, Iterator, decorated_type
 + from contextlib import contextmanager
 +
 + class DatabaseSession: ...
 +
 + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
 + @contextmanager
 + def session(url: str) -> Iterator[DatabaseSession]:
 + s = DatabaseSession(url)
 + try:
 + yield s
 + finally:
 + s.close()
 +
 +The argument of ``decorated_type`` is a type annotation on the name
 +being declared (``session``, in the example above). If you have
 +multiple decorators, ``decorated_type`` must be topmost. The
 +``decorated_type`` decorator is invalid on a function declaration that
 +is also decorated with ``overload``, but you can annotate the
 +implementation of the overload series with ``decorated_type``.
 +
 
 -- 
 --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/p

Re: [Python-Dev] mention aenum in the Enum docs?

2017-05-10 Thread Jim F.Hilliard 
Being the one who left the comment, I'm all for adding it.

The reason I wondered why it was not there was because I was aware you are
the author of both so, I believe, the con of it being a 3rd party library
is minimized. I've also seen plenty of people asking around for more
advanced usages of Enums so it's better to direct them to a library that
not only covers many cases but is also reliable due to you authoring it.

I'm afraid that the alternative of adding it to the wiki (as you replied)
would make no tangible difference on its visibility.




On Wed, May 10, 2017 at 1:47 AM, Brett Cannon  wrote:

>
>
> On Tue, 9 May 2017 at 10:59 Mark Lawrence via Python-Dev <
> [email protected]> wrote:
>
>> On 09/05/2017 18:05, Ethan Furman wrote:
>> > A comment on a recent SO answer [1] wondered why my aenum library wasn't
>> > mentioned in the docs to help guide people that needed/wanted more
>> > advanced Enum options to it.  I responded that Python was not in the
>> > habit of mentioning third-party libraries in the docs.
>> >
>> > However, I thought I would double-check here to see if it might be a
>> > good idea.
>> >
>> > Pros:
>> > - drop-in replacement for the stdlib Enum
>> > - has many advanced features such as
>> >- auto __init__ building
>> >- multi-value members
>> >- duplicate value but non-aliasing members
>> >- etc.
>> > - I'm the primary/only maintainer for both
>> >
>> > Cons:
>> > - third-party library
>> >
>> > Thoughts?
>> >
>> > --
>> > ~Ethan~
>> >
>> >
>> > [1] http://stackoverflow.com/a/43855536/208880
>>
>> The precedent is all ready set as the third-party regex module gets a
>> mention here https://docs.python.org/3/library/re.html and the requests
>> package here https://docs.python.org/3/library/urllib.request.html.
>>
>
> Mark's right that we already do this for select modules. Since aenum is by
> the author of enum to add things that don't fit in the stdlib and has been
> out for years (i.e. by you, Ethan :) , I see nothing wrong with linking to
> it.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/d.
> f.hilliard%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] python docs

2017-05-10 Thread Ethan Furman 

Not sure where to ask about this, so I'm asking here.

In the on-line docs, at the very bottom of a page, in fine print, is a link: _Find a bug?_  Following that link leads to 
a short page with some advice on how to handle it.  Under the second heading [1] is this paragraph:



If you’re short on time, you can also email documentation bug reports

> to [email protected] (behavioral bugs can be sent to [email protected]).
> ‘docs@’ is a mailing list run by volunteers; your request will be noticed,
> though it may take a while to be processed.

Why is python-list the place to send behavioral bugs to?  It's been my experience that folks there will (rightly) ask 
the individual to file a bug on the tracker.


--
~Ethan~



[1] https://docs.python.org/3/bugs.html#documentation-bugs



___
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] python docs

2017-05-10 Thread Chris Angelico 
On Thu, May 11, 2017 at 12:53 AM, Ethan Furman  wrote:
> Why is python-list the place to send behavioral bugs to?  It's been my
> experience that folks there will (rightly) ask the individual to file a bug
> on the tracker.
>

How many bug tracker entries do you want to see about mutable default
arguments? :) The mailing list is a great gatekeeper against "not a
bug" bugs.

ChrisA
___
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] python docs

2017-05-10 Thread Guido van Rossum 
Presumably so newbies can get help on common issues that aren't bugs, or
guidance on how to file a good bug report. Or search the tracker for
duplicates, or to upgrade to a newer version.

On May 10, 2017 7:58 AM, "Ethan Furman"  wrote:

> Not sure where to ask about this, so I'm asking here.
>
> In the on-line docs, at the very bottom of a page, in fine print, is a
> link: _Find a bug?_  Following that link leads to a short page with some
> advice on how to handle it.  Under the second heading [1] is this paragraph:
>
> If you’re short on time, you can also email documentation bug reports
>>
> > to [email protected] (behavioral bugs can be sent to
> [email protected]).
> > ‘docs@’ is a mailing list run by volunteers; your request will be
> noticed,
> > though it may take a while to be processed.
>
> Why is python-list the place to send behavioral bugs to?  It's been my
> experience that folks there will (rightly) ask the individual to file a bug
> on the tracker.
>
> --
> ~Ethan~
>
>
>
> [1] https://docs.python.org/3/bugs.html#documentation-bugs
>
>
>
> ___
> 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
>
___
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] python docs

2017-05-10 Thread Terry Reedy 

On 5/10/2017 10:59 AM, Chris Angelico wrote:

On Thu, May 11, 2017 at 12:53 AM, Ethan Furman  wrote:

Why is python-list the place to send behavioral bugs to?


Where else?  The people who would follow that advice are generally not 
registered on bpo and have no interest in the hassle of becoming so. 
(The verification process sometimes fails.)  Those already registered 
already know about it.



 It's been my
experience that folks there will (rightly) ask the individual to file a bug
on the tracker.


After vetting.  Or sometimes someone else open an issue with more 
coherence or info than the O could.



How many bug tracker entries do you want to see about mutable default
arguments? :) The mailing list is a great gatekeeper against "not a
bug" bugs.


I wish more newbies went to python-list first.

--
Terry Jan Reedy

___
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] python docs

2017-05-10 Thread Mark Lawrence via Python-Dev 

On 10/05/2017 15:53, Ethan Furman wrote:

Not sure where to ask about this, so I'm asking here.

In the on-line docs, at the very bottom of a page, in fine print, is a 
link: _Find a bug?_  Following that link leads to a short page with some 
advice on how to handle it.  Under the second heading [1] is this 
paragraph:



If you’re short on time, you can also email documentation bug reports
 > to [email protected] (behavioral bugs can be sent to 
[email protected]).
 > ‘docs@’ is a mailing list run by volunteers; your request will be 
noticed,

 > though it may take a while to be processed.

Why is python-list the place to send behavioral bugs to?  It's been my 
experience that folks there will (rightly) ask the individual to file a 
bug on the tracker.


--
~Ethan~

[1] https://docs.python.org/3/bugs.html#documentation-bugs



Saves even more reports on the grounds that "Python can't do floating 
point properly".  I don't know if it's calmed down now, but there used 
to be 3 or 4 a year.  They were, as always, very politely referred to 
the FAQ, or similar.  Multiply that up by a multitude of newbie problems 
and the triagers would be swamped.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] python docs

2017-05-10 Thread Ethan Furman 

On 05/10/2017 07:53 AM, Ethan Furman wrote:


Why is python-list the place to send behavioral bugs to?  It's been my 
experience that folks there will (rightly) ask
the individual to file a bug on the tracker.


Thank you for the abundance of answers.  I am now totally on-board with such "bug 
reports" going to Python List.

--
~Ethan~

___
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] mention aenum in the Enum docs?

2017-05-10 Thread Steven D'Aprano 
On Tue, May 09, 2017 at 10:05:43AM -0700, Ethan Furman wrote:

> A comment on a recent SO answer [1] wondered why my aenum library wasn't 
> mentioned in the docs to help guide people that needed/wanted more advanced 
> Enum options to it.

I know that the std lib is where good modules go to die :-)

Is the aenum module feature complete? Is it ready to ~~die~~ move to the 
std lib?

If aenum is not going through active development, perhaps the missing 
features should be ported to enum and then there's no need to recommend 
a second module.

> Pros:
> - drop-in replacement for the stdlib Enum
> - has many advanced features such as
>   - auto __init__ building
>   - multi-value members
>   - duplicate value but non-aliasing members
>   - etc.

Those three advanced features sound useful. Is there a reason enum 
doesn't support them?



-- 
Steve
___
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 484 update proposal: annotating decorated declarations

2017-05-10 Thread Steven D'Aprano 
On Tue, May 09, 2017 at 11:54:26PM +0400, Abdur-Rahmaan Janhangeer wrote:
> I'm really new to the mailing list. Can someone just summarise the
> preceding message in 5 to 10 lines like what it is, what type is it or when
> does it happen

It is an update to PEP 484, adding support for type-checking decorators.

https://www.python.org/dev/peps/pep-0484/

I don't understand what you mean by "what type is it".

When does it happen: if there are no strong or conclusive objections
(and I don't think there have been) it may have already happened by now.
If not, then soon. Depends on Guido's schedule.

As for when it will actually be visible in Python, the original post 
already answered that: Guido hopes to add it to Python 3.6.2 and 3.5.4. 
I don't think this will have much visible impact unless you're using 
MyPy for type checking.

By the way, the original post was less than fifty lines. That already 
is a summary.


-- 
Steve
___
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] mention aenum in the Enum docs?

2017-05-10 Thread Ethan Furman 

On 05/10/2017 05:50 PM, Steven D'Aprano wrote:

On Tue, May 09, 2017 at 10:05:43AM -0700, Ethan Furman wrote:



A comment on a recent SO answer [1] wondered why my aenum library wasn't
mentioned in the docs to help guide people that needed/wanted more advanced
Enum options to it.


I know that the std lib is where good modules go to die :-)

Is the aenum module feature complete? Is it ready to ~~die~~ move to the
std lib?


No, it is still under active development.


Pros:
- drop-in replacement for the stdlib Enum
- has many advanced features such as
   - auto __init__ building
   - multi-value members
   - duplicate value but non-aliasing members
   - etc.


Those three advanced features sound useful. Is there a reason enum
doesn't support them?


New features go to aenum first for experimentation and bug squashing.  After I'm happy with them, thay /may/ go to the 
standard library.


Even if all the features end up in the stdlib (unlikely), it would still be a useful recommendation as aenum works as 
far back as 2.7, possibly further).


--
~Ethan~
___
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