Re: [Python-Dev] Python 3.6.3 venv FAILURE

2017-11-10 Thread Brett Cannon 
Please file bugs at bugs.python.org.

On Fri, Nov 10, 2017, 16:40 Larry Chen,  wrote:

> Upgraded from 3.6.1 to 3.6.3; but got an error when trying to create my
> virtual environment.
>
>
>
> [larrchen@rslab239 Larry]$  /opt/python3.6.3/bin/python3.6 -m venv
> /u/larrchen/work2/SAN/Users/Larry/rslab239_myENV_363
>
> Error: Command
> '['/u/larrchen/work2/SAN/Users/Larry/rslab239_myENV_363/bin/python3.6',
> '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit
> status 1.
>
> [larrchen@rslab239 Larry]$
>
>
>
> Regards,
>
> Larry Chen
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
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-committers] Enabling depreciation warnings feature code cutoff

2017-11-10 Thread Brett Cannon 
On Thu, Nov 9, 2017, 17:33 Nathaniel Smith,  wrote:

> On Nov 8, 2017 16:12, "Nick Coghlan"  wrote:
>
> On 9 November 2017 at 07:46, Antoine Pitrou  wrote:
> >
> > Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
> >>
> >> However, between them, the following two guidelines should provide
> >> pretty good deprecation warning coverage for the world's Python code:
> >>
> >> 1. If it's in __main__, it will emit deprecation warnings at runtime
> >> 2. If it's not in __main__, it should have a test suite
> >
> > Nick, have you actually read the discussion and the complaints people
> > had with the current situation?  Most of them *don't* specifically talk
> > about __main__ scripts.
>
> I have, and I've also re-read the discussions regarding why the
> default got changed in the first place.
>
> Behaviour up until 2.6 & 3.1:
>
> once::DeprecationWarning
>
> Behaviour since 2.7 & 3.2:
>
> ignore::DeprecationWarning
>
> With test runners overriding the default filters to set it back to
> "once::DeprecationWarning".
>
>
> Is this intended to be a description of the current state of affairs?
> Because I've never encountered a test runner that does this... Which
> runners are you thinking of?
>
>
> The rationale for that change was so that end users of applications
> that merely happened to be written in Python wouldn't see deprecation
> warnings when Linux distros (or the end user) updated to a new Python
> version. It had the downside that you had to remember to opt-in to
> deprecation warnings in order to see them, which is a problem if you
> mostly use Python for ad hoc personal scripting.
>
> Proposed behaviour for Python 3.7+:
>
> once::DeprecationWarning:__main__
> ignore::DeprecationWarning
>
> With test runners still overriding the default filters to set them
> back to "once::DeprecationWarning".
>
> This is a partial reversion back to the pre-2.7 behaviour, focused
> specifically on interactive use and ad hoc personal scripting. For ad
> hoc *distributed* scripting, the changed default encourages upgrading
> from single-file scripts to the zipapp model, and then minimising the
> amount of code that runs directly in __main__.py.
>
> I expect this will be a sufficient change to solve the specific
> problem I'm personally concerned by, so I'm no longer inclined to
> argue for anything more complicated. Other folks may have other
> concerns that this tweak to the default filters doesn't address - they
> can continue to build their case for more complex options using this
> as the new baseline behaviour.
>
>
> I think most people's concern is that we've gotten into a state where
> DeprecationWarning's are largely useless in practice, because no one sees
> them. Effectively the norm now is that developers (both the Python core
> team and downstream libraries) think they're following some sensible
> deprecation cycle, but often they're actually making changes without any
> warning, just they wait a year to do it. It's not clear why we're bothering
> through multiple releases -- which adds major overhead -- if in practice we
> aren't going to actually warn most people. Enabling them for another 1% of
> code doesn't really address this.
>
> As I mentioned above, it's also having the paradoxical effect of making it
> so that end-users are *more* likely to see deprecation warnings, since
> major libraries are giving up on using DeprecationWarning. Most recently it
> looks like pyca/cryptography is going to switch, partly as a result of this
> thread:
>   https://github.com/pyca/cryptography/pull/4014
>
> Some more ideas to throw out there:
>
> - if an envvar CI=true is set, then by default make deprecation warnings
> into errors. (This is an informal standard that lots of CI systems use.
> Error instead of "once" because most people don't look at CI output at all
> unless there's an error.)
>

One problem with that is I don't want e.g. mypy to start spewing out
warnings while checking my code. That's why I like Victor's idea of a -X
option that also flips on other test/debug features. Yes, this would also
trigger for test runners, but that's at least a smaller amount of affected
code.

-Brett


> - provide some mechanism that makes it easy to have a deprecation warning
> that starts out as invisible, but then becomes visible as you get closer to
> the switchover point. (E.g. CPython might make the deprecation warnings
> that it issues be invisible in 3.x.0 and 3.x.1 but become visible in
> 3.x.2+.) Maybe:
>
> # in warnings.py
> def deprecation_warning(library_version, visible_in_version,
> change_in_version, msg, stacklevel):
> ...
>
> Then a call like:
>
>   deprecation_warning(my_library.__version__, "1.3", "1.4", "This function
> is deprecated", 2)
>
> issues an InvisibleDeprecationWarning if my_library.__version__ < 1.3, and
> a VisibleDeprecationWarning otherwise.
>
> (The stacklevel argument is mandatory because the usual default of 1 is
> always wrong for deprecation warnings.)
>
> -n
> ___

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

2017-11-10 Thread Nick Coghlan 
On 11 November 2017 at 01:48, Guido van Rossum  wrote:
> I don't mind the long name. Of all the options so far I really only like
> 'string_annotations' so let's go with that.

+1 from me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

2017-11-10 Thread Nick Coghlan 
On 11 November 2017 at 02:02, Random832  wrote:
> On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote:
>> My suggestion for that definition is to have the *default* meaning of
>> "third party code" be "everything that isn't __main__".
>
> What is __main__? Or, rather, how do you determine when it is to blame?
> For syntax it's easy, but any deprecated function necessarily belongs to
> its own module and not to main. Main may have called it, which can be
> detected from the stack trace, or it may have used it in some other way
> (pass to some builtin or e.g. itertools function that takes a callable
> argument, for example).

The warnings machinery already defines how this works (look for
"stacklevel"). For callbacks defined as Python code, the deprecated
call will be attributed to whichever module defined the callback, not
the machinery that called the callback.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-10 Thread Ben Usman 
Got it, thank you. I'll go and check it out!

On Nov 11, 2017 01:22, "Jelle Zijlstra"  wrote:

>
>
> 2017-11-10 19:53 GMT-08:00 Ben Usman :
>
>> The following works now:
>>
>> seq = [1, 2]
>> d = {'c': 3, 'a': 1, 'b': 2}
>>
>> (el1, el2) = *seq
>> el1, el2 = *seq
>> head, *tail = *seq
>>
>> seq_new = (*seq, *tail)
>> dict_new = {**d, **{'c': 4}}
>>
>> def f(arg1, arg2, a, b, c):
>> pass
>>
>> f(*seq, **d)
>>
>> It seems like dict unpacking syntax would not be fully coherent with
>> list unpacking syntax without something like:
>>
>> {b, a, **other} = **d
>>
>> Because iterables have both syntax for function call unpacking and
>> "rhs in assignment unpacking" and dict has only function call
>> unpacking syntax.
>>
>> I was not able to find any PEPs that suggest this (search keywords:
>> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
>> however, let me know if I am wrong.
>>
>> It was discussed at great length on Python-ideas about a year ago. There
> is a thread called "Unpacking a dict" from May 2016.
>
>
>> The main use-case, in my understating, is getting shortcuts to
>> elements of a dictionary if they are going to be used more then
>> ones later in the scope. A made-up example is using a config to
>> initiate a bunch of things with many config arguments with long
>> names that have overlap in keywords used in initialization.
>>
>> One should either write long calls like
>>
>> start_a(config['parameter1'], config['parameter2'],
>> config['parameter3'], config['parameter4'])
>>
>> start_b(config['parameter3'], config['parameter2'],
>> config['parameter3'], config['parameter4'])
>>
>> many times or use a list-comprehension solution mentioned above.
>>
>> It becomes even worse (in terms of readability) with nested structures.
>>
>> start_b(config['group2']['parameter3'], config['parameter2'],
>> config['parameter3'], config['group2']['parameter3'])
>>
>>
>> ## Rationale
>>
>> Right now this problem is often solved using [list] comprehensions,
>> but this is somewhat verbose:
>>
>> a, b = (d[k] for k in ['a', 'b'])
>>
>> or direct per-instance assignment (looks simple for with
>> single-character keys, but often becomes very verbose with
>> real-world long key names)
>>
>> a = d['a']
>> b = d['b']
>>
>> Alternatively one could have a very basic method\function
>> get_n() or __getitem__() accepting more then a single argument
>>
>> a, b = d.get_n('a', 'b')
>> a, b = get_n(d, 'a', 'b')
>> a, b = d['a', 'b']
>>
>> All these approaches require verbose double-mentioning of same
>> key. It becomes even worse if you have nested structures
>> of dictionaries.
>>
>> ## Concerns and questions:
>>
>> 0. This is the most troubling part,  imho, other questions
>> are more like common thoughts. It seems (to put it mildly)
>> weird that execution flow depends on names of local variables.
>>
>> For example, one can not easily refactor these variable names. However,
>> same is true for dictionary keys anyway: you can not suddenly decide
>> and refactor your code to expect dictionaries with keys 'c' and
>> 'd' whereas your entire system still expects you to use dictionaries
>> with keys 'a' and 'b'. A counter-objection is that this specific
>> scenario is usually handled with record\struct-like classes  with
>> fixed members rather then dicts, so this is not an issue.
>>
>> Quite a few languages (closure and javascript to name a few) seem
>> to have this feature now and it seems like they did not suffer too
>> much from refactoring hell. This does not mean that their approach
>> is good, just that it is "manageable".
>>
>> 1. This line seems coherent with sequence syntax, but redundant:
>> {b, a, **other} = **d
>>
>> and the following use of "throwaway" variable just looks poor visually
>> {b, a, **_} = **d
>>
>> could it be less verbose like this
>> {b, a} = **d
>>
>> but it is not very coherent with lists behavior.
>>
>> E.g. what if that line did not raise something like "ValueError:
>> Too many keys to unpack, got an unexpected keyword argument 'c'".
>>
>> 2. Unpacking in other contexts
>>
>> {self.a, b, **other} = **d
>>
>> should it be interpreted as
>> self.a, b = d['a'], d['b']
>>
>> or
>>
>> self.a, b = d['self.a'], d['b']
>>
>> probably the first, but what I am saying is that these name-extracting
>> rules should be strictly specified and it might not be trivial.
>>
>> ---
>> Ben
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.
>> zijlstra%40gmail.com
>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-10 Thread Jelle Zijlstra 
2017-11-10 19:53 GMT-08:00 Ben Usman :

> The following works now:
>
> seq = [1, 2]
> d = {'c': 3, 'a': 1, 'b': 2}
>
> (el1, el2) = *seq
> el1, el2 = *seq
> head, *tail = *seq
>
> seq_new = (*seq, *tail)
> dict_new = {**d, **{'c': 4}}
>
> def f(arg1, arg2, a, b, c):
> pass
>
> f(*seq, **d)
>
> It seems like dict unpacking syntax would not be fully coherent with
> list unpacking syntax without something like:
>
> {b, a, **other} = **d
>
> Because iterables have both syntax for function call unpacking and
> "rhs in assignment unpacking" and dict has only function call
> unpacking syntax.
>
> I was not able to find any PEPs that suggest this (search keywords:
> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
> however, let me know if I am wrong.
>
> It was discussed at great length on Python-ideas about a year ago. There
is a thread called "Unpacking a dict" from May 2016.


> The main use-case, in my understating, is getting shortcuts to
> elements of a dictionary if they are going to be used more then
> ones later in the scope. A made-up example is using a config to
> initiate a bunch of things with many config arguments with long
> names that have overlap in keywords used in initialization.
>
> One should either write long calls like
>
> start_a(config['parameter1'], config['parameter2'],
> config['parameter3'], config['parameter4'])
>
> start_b(config['parameter3'], config['parameter2'],
> config['parameter3'], config['parameter4'])
>
> many times or use a list-comprehension solution mentioned above.
>
> It becomes even worse (in terms of readability) with nested structures.
>
> start_b(config['group2']['parameter3'], config['parameter2'],
> config['parameter3'], config['group2']['parameter3'])
>
>
> ## Rationale
>
> Right now this problem is often solved using [list] comprehensions,
> but this is somewhat verbose:
>
> a, b = (d[k] for k in ['a', 'b'])
>
> or direct per-instance assignment (looks simple for with
> single-character keys, but often becomes very verbose with
> real-world long key names)
>
> a = d['a']
> b = d['b']
>
> Alternatively one could have a very basic method\function
> get_n() or __getitem__() accepting more then a single argument
>
> a, b = d.get_n('a', 'b')
> a, b = get_n(d, 'a', 'b')
> a, b = d['a', 'b']
>
> All these approaches require verbose double-mentioning of same
> key. It becomes even worse if you have nested structures
> of dictionaries.
>
> ## Concerns and questions:
>
> 0. This is the most troubling part,  imho, other questions
> are more like common thoughts. It seems (to put it mildly)
> weird that execution flow depends on names of local variables.
>
> For example, one can not easily refactor these variable names. However,
> same is true for dictionary keys anyway: you can not suddenly decide
> and refactor your code to expect dictionaries with keys 'c' and
> 'd' whereas your entire system still expects you to use dictionaries
> with keys 'a' and 'b'. A counter-objection is that this specific
> scenario is usually handled with record\struct-like classes  with
> fixed members rather then dicts, so this is not an issue.
>
> Quite a few languages (closure and javascript to name a few) seem
> to have this feature now and it seems like they did not suffer too
> much from refactoring hell. This does not mean that their approach
> is good, just that it is "manageable".
>
> 1. This line seems coherent with sequence syntax, but redundant:
> {b, a, **other} = **d
>
> and the following use of "throwaway" variable just looks poor visually
> {b, a, **_} = **d
>
> could it be less verbose like this
> {b, a} = **d
>
> but it is not very coherent with lists behavior.
>
> E.g. what if that line did not raise something like "ValueError:
> Too many keys to unpack, got an unexpected keyword argument 'c'".
>
> 2. Unpacking in other contexts
>
> {self.a, b, **other} = **d
>
> should it be interpreted as
> self.a, b = d['a'], d['b']
>
> or
>
> self.a, b = d['self.a'], d['b']
>
> probably the first, but what I am saying is that these name-extracting
> rules should be strictly specified and it might not be trivial.
>
> ---
> Ben
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

2017-11-10 Thread Ben Usman 
The following works now:

seq = [1, 2]
d = {'c': 3, 'a': 1, 'b': 2}

(el1, el2) = *seq
el1, el2 = *seq
head, *tail = *seq

seq_new = (*seq, *tail)
dict_new = {**d, **{'c': 4}}

def f(arg1, arg2, a, b, c):
pass

f(*seq, **d)

It seems like dict unpacking syntax would not be fully coherent with
list unpacking syntax without something like:

{b, a, **other} = **d

Because iterables have both syntax for function call unpacking and
"rhs in assignment unpacking" and dict has only function call
unpacking syntax.

I was not able to find any PEPs that suggest this (search keywords:
"PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
however, let me know if I am wrong.

The main use-case, in my understating, is getting shortcuts to
elements of a dictionary if they are going to be used more then
ones later in the scope. A made-up example is using a config to
initiate a bunch of things with many config arguments with long
names that have overlap in keywords used in initialization.

One should either write long calls like

start_a(config['parameter1'], config['parameter2'],
config['parameter3'], config['parameter4'])

start_b(config['parameter3'], config['parameter2'],
config['parameter3'], config['parameter4'])

many times or use a list-comprehension solution mentioned above.

It becomes even worse (in terms of readability) with nested structures.

start_b(config['group2']['parameter3'], config['parameter2'],
config['parameter3'], config['group2']['parameter3'])


## Rationale

Right now this problem is often solved using [list] comprehensions,
but this is somewhat verbose:

a, b = (d[k] for k in ['a', 'b'])

or direct per-instance assignment (looks simple for with
single-character keys, but often becomes very verbose with
real-world long key names)

a = d['a']
b = d['b']

Alternatively one could have a very basic method\function
get_n() or __getitem__() accepting more then a single argument

a, b = d.get_n('a', 'b')
a, b = get_n(d, 'a', 'b')
a, b = d['a', 'b']

All these approaches require verbose double-mentioning of same
key. It becomes even worse if you have nested structures
of dictionaries.

## Concerns and questions:

0. This is the most troubling part,  imho, other questions
are more like common thoughts. It seems (to put it mildly)
weird that execution flow depends on names of local variables.

For example, one can not easily refactor these variable names. However,
same is true for dictionary keys anyway: you can not suddenly decide
and refactor your code to expect dictionaries with keys 'c' and
'd' whereas your entire system still expects you to use dictionaries
with keys 'a' and 'b'. A counter-objection is that this specific
scenario is usually handled with record\struct-like classes  with
fixed members rather then dicts, so this is not an issue.

Quite a few languages (closure and javascript to name a few) seem
to have this feature now and it seems like they did not suffer too
much from refactoring hell. This does not mean that their approach
is good, just that it is "manageable".

1. This line seems coherent with sequence syntax, but redundant:
{b, a, **other} = **d

and the following use of "throwaway" variable just looks poor visually
{b, a, **_} = **d

could it be less verbose like this
{b, a} = **d

but it is not very coherent with lists behavior.

E.g. what if that line did not raise something like "ValueError:
Too many keys to unpack, got an unexpected keyword argument 'c'".

2. Unpacking in other contexts

{self.a, b, **other} = **d

should it be interpreted as
self.a, b = d['a'], d['b']

or

self.a, b = d['self.a'], d['b']

probably the first, but what I am saying is that these name-extracting
rules should be strictly specified and it might not be trivial.

---
Ben
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Peter Ludemann via Python-Dev 
On 10 November 2017 at 19:17, Greg Ewing 
wrote:

> Ethan Furman wrote:
>
>> Contriwise, "annotation_strings" sounds like a different type of
>> annotation -- they are now being stored as strings, instead of something
>> else.
>>
>
> How about "annotations_as_strings"?


That feels unambiguous. "annotations_to_str" is shorter, given that "str"
is a type in Python, and "to" says that it's converting *to* string (it's
given *as* an expression).
​

>
>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann
> %40google.com
>
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Greg Ewing 

Ethan Furman wrote:
Contriwise, "annotation_strings" sounds like a different type of 
annotation -- they are now being stored as strings, instead of something 
else.


How about "annotations_as_strings"?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.6.3 venv FAILURE

2017-11-10 Thread Larry Chen 
Upgraded from 3.6.1 to 3.6.3; but got an error when trying to create my virtual 
environment.

[larrchen@rslab239 Larry]$  /opt/python3.6.3/bin/python3.6 -m venv 
/u/larrchen/work2/SAN/Users/Larry/rslab239_myENV_363
Error: Command 
'['/u/larrchen/work2/SAN/Users/Larry/rslab239_myENV_363/bin/python3.6', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
[larrchen@rslab239 Larry]$

Regards,
Larry Chen

___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Lukasz Langa 

> On 10 Nov, 2017, at 4:48 PM, Guido van Rossum  wrote:
> 
> On Fri, Nov 10, 2017 at 1:20 AM, Lukasz Langa  > wrote:
> Alright, we're on bikeshed territory now. Finally! :-)
> 
> I was always thinking about this as "static annotations". The fact they're 
> strings at runtime is irrelevant for most people who will use this future. 
> They don't want string annotations, they want them to not be evaluated on 
> import time... they want them to be static. Also, "static typing" et al. I 
> think it has a nice vibe to it.
> 
> I admit "annotations" is too broad but "static_annotations" (or 
> "string_annotations" ¯\_(ツ)_/¯ ) will be the longest __future__ name so far. 
> That was my main motivation behind using the shorter name. And a bit of 
> megalomania I guess.
> 
> I don't mind the long name. Of all the options so far I really only like 
> 'string_annotations' so let's go with that.

Done.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Guido van Rossum 
On Fri, Nov 10, 2017 at 9:50 AM, Ethan Furman  wrote:

> On 11/10/2017 07:48 AM, Guido van Rossum wrote:
>
> I don't mind the long name. Of all the options so far I really only like
>> 'string_annotations' so let's go with that.
>>
>
> As someone else mentioned, we have function annotations and variable
> annotations already, which makes string_annotations sound like it's
> annotations for strings.
>

We can't strive to encode the full documentation in the future's name.


> Contriwise, "annotation_strings" sounds like a different type of
> annotation -- they are now being stored as strings, instead of something
> else.
>

Trust me, that can also be misinterpreted. Let's stop the bikeshedding.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Koos Zevenhoven 
On Fri, Nov 10, 2017 at 7:50 PM, Ethan Furman  wrote:

> On 11/10/2017 07:48 AM, Guido van Rossum wrote:
>
> I don't mind the long name. Of all the options so far I really only like
>> 'string_annotations' so let's go with that.
>>
>
> As someone else mentioned, we have function annotations and variable
> annotations already, which makes string_annotations sound like it's
> annotations for strings.
>
>
> Contriwise, "annotation_strings" sounds like a different type of
> annotation -- they are now being stored as strings, instead of something
> else.
>
>
​Or a step further (longer), with annotations_as_strings.

––Koos​


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Ethan Furman 

On 11/10/2017 07:48 AM, Guido van Rossum wrote:


I don't mind the long name. Of all the options so far I really only like 
'string_annotations' so let's go with that.


As someone else mentioned, we have function annotations and variable annotations already, which makes string_annotations 
sound like it's annotations for strings.



Contriwise, "annotation_strings" sounds like a different type of annotation -- they are now being stored as strings, 
instead of something else.


--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2017-11-10 Thread Python tracker 

ACTIVITY SUMMARY (2017-11-03 - 2017-11-10)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6247 ( -8)
  closed 37507 (+76)
  total  43754 (+68)

Open issues with patches: 2404 


Issues opened (44)
==

#10049: Add a "no-op" (null) context manager to contextlib
https://bugs.python.org/issue10049  reopened by ncoghlan

#31486: calling a _json.Encoder object raises a SystemError in case ob
https://bugs.python.org/issue31486  reopened by serhiy.storchaka

#31937: Add the term "dunder" to the glossary
https://bugs.python.org/issue31937  opened by brett.cannon

#31938: Convert selectmodule.c to Argument Clinic
https://bugs.python.org/issue31938  opened by taleinat

#31939: Support return annotation in signature for Argument Clinic
https://bugs.python.org/issue31939  opened by haypo

#31940: copystat on symlinks fails for alpine -- faulty lchmod impleme
https://bugs.python.org/issue31940  opened by Anthony Sottile

#31942: Document that support of start and stop parameters in the Sequ
https://bugs.python.org/issue31942  opened by serhiy.storchaka

#31943: Add asyncio.Handle.cancelled() method
https://bugs.python.org/issue31943  opened by decaz

#31946: mailbox.MH.add loses status info from other formats
https://bugs.python.org/issue31946  opened by shai

#31947: names=None case is not handled by EnumMeta._create_ method
https://bugs.python.org/issue31947  opened by anentropic

#31948: [EASY] Broken MSDN links in msilib docs
https://bugs.python.org/issue31948  opened by berker.peksag

#31949: Bugs in PyTraceBack_Print()
https://bugs.python.org/issue31949  opened by serhiy.storchaka

#31951: import curses is broken on windows
https://bugs.python.org/issue31951  opened by joe m2

#31954: Don't prevent dict optimization by coupling with OrderedDict
https://bugs.python.org/issue31954  opened by serhiy.storchaka

#31956: Add start and stop parameters to the array.index()
https://bugs.python.org/issue31956  opened by niki.spahiev

#31958: UUID versions are not validated to lie in the documented range
https://bugs.python.org/issue31958  opened by David MacIver

#31961: subprocess._execute_child doesn't accept a single PathLike arg
https://bugs.python.org/issue31961  opened by Roy Williams

#31962: test_importlib double free or corruption
https://bugs.python.org/issue31962  opened by DNSGeek

#31964: [3.4][3.5] pyexpat: compilaton of libexpat fails with: ISO C90
https://bugs.python.org/issue31964  opened by haypo

#31966: [EASY C][Windows] print('hello\n', end='', flush=True) raises 
https://bugs.python.org/issue31966  opened by Guillaume Aldebert

#31967: [Windows] test_distutils: fatal error LNK1158: cannot run 'rc.
https://bugs.python.org/issue31967  opened by haypo

#31968: exec(): method's default arguments from dict-inherited globals
https://bugs.python.org/issue31968  opened by Ilya Polyakovskiy

#31971: idle_test: failures on x86 Windows7 3.x
https://bugs.python.org/issue31971  opened by haypo

#31972: Inherited docstrings for pathlib classes are confusing
https://bugs.python.org/issue31972  opened by eric.araujo

#31973: Incomplete DeprecationWarning for async/await keywords
https://bugs.python.org/issue31973  opened by barry

#31975: Add a default filter for DeprecationWarning in __main__
https://bugs.python.org/issue31975  opened by ncoghlan

#31976: Segfault when closing BufferedWriter from a different thread
https://bugs.python.org/issue31976  opened by benfogle

#31978: make it simpler to round fractions
https://bugs.python.org/issue31978  opened by wolma

#31979: Simplify converting non-ASCII strings to int, float and comple
https://bugs.python.org/issue31979  opened by serhiy.storchaka

#31982: 8.3. collections — Container datatypes
https://bugs.python.org/issue31982  opened by Sasha Kacanski

#31983: Officially add Py_SETREF and Py_XSETREF
https://bugs.python.org/issue31983  opened by serhiy.storchaka

#31984: startswith and endswith leak implementation details
https://bugs.python.org/issue31984  opened by Ronan.Lamy

#31985: Deprecate openfp() in aifc, sunau and wave
https://bugs.python.org/issue31985  opened by brian.curtin

#31986: [2.7] test_urllib2net.test_sites_no_connection_close() randoml
https://bugs.python.org/issue31986  opened by haypo

#31988: Saving bytearray to binary plist file doesn't work
https://bugs.python.org/issue31988  opened by serhiy.storchaka

#31990: Pickling deadlocks in thread with python -m
https://bugs.python.org/issue31990  opened by Werner Smidt

#31991: Race condition in wait with timeout for multiprocessing.Event
https://bugs.python.org/issue31991  opened by tomMoral

#31993: pickle.dump allocates unnecessary temporary bytes / str
https://bugs.python.org/issue31993  opened by Olivier.Grisel

#31994: json encoder exception could be better
https://bugs.python.org/issue31994  opened by Jason Hihn

#31995: Set operation

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

2017-11-10 Thread Random832 
On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote:
> My suggestion for that definition is to have the *default* meaning of
> "third party code" be "everything that isn't __main__".

What is __main__? Or, rather, how do you determine when it is to blame?
For syntax it's easy, but any deprecated function necessarily belongs to
its own module and not to main. Main may have called it, which can be
detected from the stack trace, or it may have used it in some other way
(pass to some builtin or e.g. itertools function that takes a callable
argument, for example). Maybe the DeprecationWarning should be raised at
the name lookup* rather than the call? What if "calling this function
with some particular combination of arguments" is deprecated?


*i.e. something like:

class deprecated:
   def __init__(self, obj): self.obj = obj
class DeprecatableModule(ModuleType):
   def __getattr__(self, name):
  obj = self.__dict__[name]
  if isinstance(type(obj), deprecated):
  if (detect somehow caller is __main__): raise
  DeprecationWarning
  return obj.obj
  else: return obj
def __dir__(self):
return [k for k in self.__dict__ if not
isinstance(self.__dict__[k], deprecated)]
  
sys.modules[__name__].type=DeprecatableModule

@deprecated
def some_deprecated_function(...): ...

SOME_DEPRECATED_CONSTANT = deprecated(42)
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Guido van Rossum 
On Fri, Nov 10, 2017 at 1:20 AM, Lukasz Langa  wrote:

> Alright, we're on bikeshed territory now. Finally! :-)
>
> I was always thinking about this as "static annotations". The fact they're
> strings at runtime is irrelevant for most people who will use this future.
> They don't want string annotations, they want them to not be evaluated on
> import time... they want them to be static. Also, "static typing" et al. I
> think it has a nice vibe to it.
>
> I admit "annotations" is too broad but "static_annotations" (or
> "string_annotations" ¯\_(ツ)_/¯ ) will be the longest __future__ name so
> far. That was my main motivation behind using the shorter name. And a bit
> of megalomania I guess.
>

I don't mind the long name. Of all the options so far I really only like
'string_annotations' so let's go with that.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Koos Zevenhoven 
On Thu, Nov 9, 2017 at 9:51 PM, Guido van Rossum  wrote:

> If we have to change the name I'd vote for string_annotations -- "lazy"
> has too many other connotations (e.g. it might cause people to think it's
> the thunks). I find str_annotations too abbreviated, and
> stringify_annotations is too hard to spell.
>
>
​I can't say I disagree. ​And maybe importing string_annotations from the
__future__ doesn't sound quite as sad as importing something from the
__past__.

Anyway, it's not obvious to me that it is the module author that should
decide how the annotations are handled. See also this quote below:

(Quoted from the end of
https://mail.python.org/pipermail/python-ideas/2017-October/047311.html )

On Thu, Oct 12, 2017 at 3:59 PM, Koos Zevenhoven  wrote:

>
> ​​[*] Maybe somehow make the existing functionality a phantom easter
> egg––a blast from the past which you can import and use, but which is
> otherwise invisible :-). Then later give warnings and finally remove it
> completely.
>
> But we need better smooth upgrade paths anyway, maybe something like:
>
> from __compat__ import unintuitive_decimal_contexts
>
> with unintuitive_decimal_contexts:
> do_stuff()
>
> ​Now code bases can more quickly switch to new python versions and make
> the occasional compatibility adjustments more lazily, while already
> benefiting from other new language features.
>
>
> ––Koos​
>
>
>
-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Nick Coghlan 
On 10 November 2017 at 19:20, Lukasz Langa  wrote:
> Alright, we're on bikeshed territory now. Finally! :-)
>
> I was always thinking about this as "static annotations". The fact they're
> strings at runtime is irrelevant for most people who will use this future.

It's highly relevant to anyone currently using annotations for a
purpose *other than* type hints, though - they're going to have to
work out how to cope with annotations being strings rather than
eagerly evaluated expressions.

It's also a hopefully useful mnemonic as to what the new runtime
semantics are: the feature flag makes it as if all your annotations
were quoted strings, just without the actual quote markers.

> They don't want string annotations, they want them to not be evaluated on
> import time... they want them to be static. Also, "static typing" et al. I
> think it has a nice vibe to it.

Getting folks to *not* call type hinting static typing is an ongoing
challenge though, so it doesn't seem like a good idea to encourage
that link to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

2017-11-10 Thread Stefan Krah 
On Fri, Nov 10, 2017 at 12:09:12PM +1000, Nick Coghlan wrote:
> I'm with Antoine on this - we should be pushing folks writing
> extension modules towards code generators like Cython, cffi, SWIG, and
> SIP, support libraries like Boost::Python, or safer languages like
> Rust (which can then be wrapped with cffi), rather than encouraging
> more bespoke C/C++ extensions modules with handcrafted refcount
> management. There's a reason the only parts of
> https://packaging.python.org/guides/packaging-binary-extensions/ that
> have actually been filled in are the ones explaining how to use a tool
> to write the extension module for you :)

They will be slower and in my experience not easier to maintain -- quite
the opposite.



Stefan Krah




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

2017-11-10 Thread Nathaniel Smith 
On Tue, Nov 7, 2017 at 8:45 AM, Nathaniel Smith  wrote:
> Also, IIRC it's actually impossible to set the stacklevel= correctly when
> you're deprecating a whole module and issue the warning at import time,
> because you need to know how many stack frames the import system uses.

Doh, I didn't remember correctly. Actually Brett fixed this in 3.5:
https://bugs.python.org/issue24305

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
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 563: Postponed Evaluation of Annotations

2017-11-10 Thread Lukasz Langa 
Alright, we're on bikeshed territory now. Finally! :-)

I was always thinking about this as "static annotations". The fact they're 
strings at runtime is irrelevant for most people who will use this future. They 
don't want string annotations, they want them to not be evaluated on import 
time... they want them to be static. Also, "static typing" et al. I think it 
has a nice vibe to it.

I admit "annotations" is too broad but "static_annotations" (or 
"string_annotations" ¯\_(ツ)_/¯ ) will be the longest __future__ name so far. 
That was my main motivation behind using the shorter name. And a bit of 
megalomania I guess.

- Ł

> On 9 Nov, 2017, at 7:30 PM, Guido van Rossum  wrote:
> 
> So... Łukasz?
> 
> On Thu, Nov 9, 2017 at 6:11 PM, Nick Coghlan  > wrote:
> On 10 November 2017 at 05:51, Guido van Rossum  > wrote:
> > If we have to change the name I'd vote for string_annotations -- "lazy" has
> > too many other connotations (e.g. it might cause people to think it's the
> > thunks). I find str_annotations too abbreviated, and stringify_annotations
> > is too hard to spell.
> 
> Aye, I'd be fine with "from __future__ import string_annotations" -
> that's even more explicitly self-documenting than either of my
> suggestions.
> 
> --
> --Guido van Rossum (python.org/~guido )



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com