Re: [Python-Dev] Python 3.6.3 venv FAILURE

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/rsla

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

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

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

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 __

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

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

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

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

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

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 s

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

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

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

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. "an

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

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@py

[Python-Dev] Python 3.6.3 venv FAILURE

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

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

> 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 runtim

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

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 var

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

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 var

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

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

[Python-Dev] Summary of Python tracker Issues

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 wi

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

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 func

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

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 annota

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

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 h

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

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 cur

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

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 wrapp

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

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 remem

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

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... t