Re: [Python-Dev] [ssl] The weird case of IDNA

On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > >> This is another reason why we ought to let users do their own IDNA handling >> if they want... > > I expect that l

Re: [Python-Dev] [ssl] The weird case of IDNA

On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" < turnbull.stephen...@u.tsukuba.ac.jp> wrote: Nathaniel Smith writes: > Issue 1: Python's built-in IDNA implementation is wrong (implements > IDNA 2003, not IDNA 2008). Is "wrong" the right word here? I'l

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sat, Dec 30, 2017 at 2:28 AM, Antoine Pitrou wrote: > On Fri, 29 Dec 2017 21:54:46 +0100 > Christian Heimes wrote: >> >> On the other hand ssl module is currently completely broken. It converts >> hostnames from bytes to text with 'idna' codec in

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sat, Dec 30, 2017 at 7:26 AM, Stephen J. Turnbull wrote: > Christian Heimes writes: > > Questions: > > - Is everybody OK with breaking backwards compatibility? The risk is > > small. ASCII-only domains are not affected > > That's not quite true, as your

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

On Fri, Dec 29, 2017 at 12:30 PM, Ethan Furman wrote: > Good point. So auto-generate a new __repr__ if: > > - one is not provided, and > - existing __repr__ is either: > - object.__repr__, or > - a previous dataclass __repr__ > > And if the auto default doesn't work for

Re: [Python-Dev] PEP 567 v2

On Thu, Dec 28, 2017 at 1:51 AM, Victor Stinner wrote: > var = ContextVar('var', default=42) > > and: > > var = ContextVar('var') > var.set (42) > > behaves the same, no? No, they're different. The second sets the value in the current context. The first sets the value

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower <steve.do...@python.org> wrote: > On 19Dec2017 1004, Chris Barker wrote: >> >> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to >> return the same dict -- so documented behavior may already be broken

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower wrote: > On 18Dec2017 2309, Steven D'Aprano wrote: >> [A LOT OF THINGS I AGREE WITH] > I agree completely with Steven's reasoning here, and it bothers me that > what is an irrelevant change to many users (dict becoming ordered)

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote: >> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw <ba...@python.org> wrote: >> > On Dec 18, 2017, at 21:11, Chris Barker

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote: > On Dec 18, 2017, at 21:11, Chris Barker wrote: > >> Will changing pprint be considered a breaking change? > > Yes, definitely. Wait, what? Why would changing pprint (so that it accurately reflects

Re: [Python-Dev] Usefulness of binary compatibility accross Python versions?

On Dec 16, 2017 11:44 AM, "Guido van Rossum" wrote: On Sat, Dec 16, 2017 at 11:14 AM, Antoine Pitrou wrote: > On Sat, 16 Dec 2017 19:37:54 +0100 > Antoine Pitrou wrote: > > > > Currently, you can pass a `module_api_version` to

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Dec 15, 2017 10:50, "Tim Peters" wrote: [Eric Snow ] > Does that include preserving order after deletion? Given that we're blessing current behavior: - At any moment, iteration order is from oldest to newest. So, "yes" to your question. -

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Dec 14, 2017 21:30, "Raymond Hettinger" wrote: > On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote: > > If "dict keeps insertion order" is not language spec and we > continue to recommend people to use OrderedDict to keep > order, I want to

Re: [Python-Dev] PEP 567 -- Context Variables

On Tue, Dec 12, 2017 at 10:39 PM, Dima Tisnek wrote: > My 2c: > TL;DR PEP specifies implementation in some detail, but doesn't show > how proposed change can or should be used. > > > > get()/set(value)/delete() methods: Python provides syntax sugar for > these, let's use it. >

Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level

On Dec 7, 2017 12:49, "Eric V. Smith" wrote: The reason I didn't include it (as @dataclass(slots=True)) is because it has to return a new class, and the rest of the dataclass features just modifies the given class in place. I wanted to maintain that conceptual simplicity. But

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Nov 28, 2017 3:55 PM, "Guido van Rossum" <gu...@python.org> wrote: On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith <n...@pobox.com> wrote: > Eh, numpy does use FutureWarning for changes where the same code will > transition from doing one thing to doing some

Re: [Python-Dev] Using async/await in place of yield expression

On Sun, Nov 26, 2017 at 9:33 PM, Caleb Hattingh wrote: > The PEP only says that __await__ must return an iterator, but it turns out > that it's also required that that iterator > should not return any intermediate values. I think you're confused :-). When the iterator

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote: > On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote: >> >> FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real >> code. Probably 80% of those would be fine with yield statements,

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On Fri, Nov 24, 2017 at 9:39 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 25 November 2017 at 15:27, Nathaniel Smith <n...@pobox.com> wrote: >> On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> def example(): >>>

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On Fri, Nov 24, 2017 at 9:04 PM, Nick Coghlan wrote: > def example(): > comp1 = yield from [(yield x) for x in ('1st', '2nd')] > comp2 = yield from [(yield x) for x in ('3rd', '4th')] > return comp1, comp2 Isn't this a really confusing way of

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum wrote: > The more I hear about this topic, the more I think that `await`, `yield` and > `yield from` should all be banned from occurring in all comprehensions and > generator expressions. That's not much different from

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Sun, Nov 19, 2017 at 2:26 AM, Serhiy Storchaka wrote: > It seems to me that most of issues with FutureWarning on GitHub [1] are > related to NumPy and pandas which use FutureWarning for its original nominal > purpose, for warning about using programming interfaces that

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 10:14 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman <et...@stoneleaf.us> wrote: >> The second way is fairly similar, but instead of replacing the entire >> sys.modules entry, its class is updated t

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 5:49 PM, Guido van Rossum wrote: >> If not, why not, and if so, shouldn't PEP 562's __getattr__ also take a >> 'self'? > > Not really, since there's only one module (the one containing the > __getattr__ function). Plus we already have a 1-argument

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote: > The second way is fairly similar, but instead of replacing the entire > sys.modules entry, its class is updated to be the class just created -- > something like sys.modules['mymod'].__class__ = MyNewClass . > > My request:

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

PM, Antoine Pitrou <solip...@pitrou.net> >>> wrote: >>>> >>>> On Sun, 12 Nov 2017 19:48:28 -0800 >>>> Nathaniel Smith <n...@pobox.com> wrote: >>>>> >>>>> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan <ncogh...@

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

Can you give any examples of problems caused by the ast not being standardized? The original motivation of being able to distinguish between foo(x: int) foo(x: "int") isn't very compelling – it's not clear it's a problem in the first place, and even if it is then all we need is some kind of

Re: [Python-Dev] PEP 561 rework

On Sun, Nov 12, 2017 at 11:21 AM, Ethan Smith wrote: > > > On Sun, Nov 12, 2017 at 9:53 AM, Jelle Zijlstra > wrote: >> >> 2017-11-12 3:40 GMT-08:00 Ethan Smith : >>> The name of the stub >>> package >>> MUST follow the scheme

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote: > This change will lead to DeprecationWarning being displayed by default for: > > * code executed directly at the interactive prompt > * code executed directly as part of a single-file script Technically it's orthogonal,

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

On Fri, Nov 10, 2017 at 11:34 PM, Brett Cannon <br...@python.org> wrote: > On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, <n...@pobox.com> wrote: >> - if an envvar CI=true is set, then by default make deprecation warnings >> into errors. (This is an informal standard

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

On Tue, Nov 7, 2017 at 8:45 AM, Nathaniel Smith <n...@pobox.com> 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 imp

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

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

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Thu, Nov 9, 2017 at 1:46 PM, Cameron Simpson wrote: > On 08Nov2017 10:28, Antoine Pitrou wrote: >> >> On Wed, 8 Nov 2017 13:07:12 +1000 >> Nick Coghlan wrote: >>> >>> On 8 November 2017 at 07:19, Evpok Padding

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 7, 2017 12:02 PM, "Barry Warsaw" wrote: On Nov 7, 2017, at 09:39, Paul Sokolovsky wrote: > So, the problem is that there's no "Python language spec”. There is a language specification: https://docs.python.org/3/refe rence/index.html But there are

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

On Nov 7, 2017 06:24, "Nick Coghlan" wrote: On 7 November 2017 at 19:30, Paul Moore wrote: > On 7 November 2017 at 04:09, Nick Coghlan wrote: >> Given the status quo, how do educators learn that the examples they're >> teaching to

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

On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan wrote: > We've been running the current experiment for 7 years, and the main > observable outcome has been folks getting surprised by breaking > changes in CPython releases, especially folks that primarily use > Python interactively

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Nov 5, 2017 2:41 PM, "Paul Ganssle" wrote: I think the question of whether any specific implementation of dict could be made faster for a given architecture or even that the trade-offs made by CPython are generally the right ones is kinda beside the point. It's certainly

Re: [Python-Dev] PEP 561: Distributing and Packaging Type Information

On Thu, Oct 26, 2017 at 3:42 PM, Ethan Smith wrote: > However, the stubs may be put in a sub-folder > of the Python sources, with the same name the ``*.py`` files are in. For > example, the ``flyingcircus`` package would have its stubs in the folder >

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote: In short, I really don't think there's a need for context variables to be faster than instance variables. There really is: currently the cost of looking up a thread local through the C API is a dict lookup, which is faster

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum <gu...@python.org> wrote: > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <gu...@python.org> >> wrote: >> >

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 11:12 AM, Ethan Furman wrote: > What would be really nice is to have attribute access like thread locals. > Instead of working with individual ContextVars you grab the LocalContext and > access the vars as attributes. I don't recall reading in the PEP

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <gu...@python.org> wrote: > On Sun, Oct 15, 2017 at 8:17 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov <yselivanov...@gmail.com> >> wrote: >> &g

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov wrote: > Hi, > > It looks like the discussion about the execution context became > extremely hard to follow. There are many opinions on how the spec for > generators should look like. What seems to be "natural" >

Re: [Python-Dev] Investigating time for `import requests`

On Sun, Oct 1, 2017 at 7:04 PM, INADA Naoki wrote: > 4. http.client > > import time: 1376 | 2448 | email.header > ... > import time: 1469 | 7791 | email.utils > import time: 408 | 10646 |

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Sat, Sep 23, 2017 at 2:45 AM, Antoine Pitrou wrote: >> As to "running_interpreters()" and "idle_interpreters()", I'm not sure >> what the benefit would be. You can compose either list manually with >> a simple comprehension: >> >> [interp for interp in

Re: [Python-Dev] Evil reference cycles caused Exception.__traceback__

On Mon, Sep 18, 2017 at 10:59 AM, Antoine Pitrou <anto...@python.org> wrote: > Le 18/09/2017 à 19:53, Nathaniel Smith a écrit : >>> >>>> Why are reference cycles a problem that needs solving? >>> >>> Because sometimes they are holding up costly resou

Re: [Python-Dev] Evil reference cycles caused Exception.__traceback__

On Mon, Sep 18, 2017 at 9:50 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 18 Sep 2017 09:42:45 -0700 > Nathaniel Smith <n...@pobox.com> wrote: >> >> Obviously it's nice when the refcount system is able to implicitly clean >> things

Re: [Python-Dev] Evil reference cycles caused Exception.__traceback__

On Sep 18, 2017 07:58, "Antoine Pitrou" wrote: Le 18/09/2017 à 16:52, Guido van Rossum a écrit : > > In Python 2 the traceback was not part of the exception object because > there was (originally) no cycle GC. In Python GC we changed the awkward > interface to something more

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Thu, Sep 14, 2017 at 5:44 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 14 September 2017 at 15:27, Nathaniel Smith <n...@pobox.com> wrote: >> I don't get it. With bytes, you can either share objects or copy them and >> the user can't tell the difference, so you

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Sep 13, 2017 9:01 PM, "Nick Coghlan" wrote: On 14 September 2017 at 11:44, Eric Snow wrote: >send(obj): > >Send the object to the receiving end of the channel. Wait until >the object is received. If the channel does not

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum wrote: > > Why not adding both? Properties do have their uses as does __getattr__. > > In that case I would just add __getattr__ to module.c, and add a recipe or > perhaps a utility module that implements a __getattr__ you can

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw <ba...@python.org> wrote: > On Sep 11, 2017, at 18:15, Nathaniel Smith <n...@pobox.com> wrote: > >> Compared to checking it on each call to sys.breakpointhook(), I guess >> the two user-visible differences in behavior woul

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw <ba...@python.org> wrote: > On Sep 10, 2017, at 13:46, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw <ba...@python.org> wrote: >>> For PEP 553, I think it’s a goo

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith <e...@trueblade.com> wrote: > On 9/10/17 11:08 PM, Nathaniel Smith wrote: >> >> Hi Eric, >> >> A few quick comments: >> >> Why do you even have a hash= argument on individual fields? For the >> whol

Re: [Python-Dev] PEP 557: Data Classes

Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the field-level hash= argument is to create a class where

Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT

On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote: > For PEP 553, I think it’s a good idea to support the environment variable > $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get > some feedback. > > Should $PYTHONBREAKPOINT be consulted in

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sep 8, 2017 4:06 PM, "Eric Snow" wrote: run(code): Run the provided Python code in the interpreter, in the current OS thread. If the interpreter is already running then raise RuntimeError in the interpreter that called ``run()``. The

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sep 9, 2017 9:07 AM, "Nick Coghlan" wrote: To immediately realise some level of efficiency benefits from the shared memory space between the main interpreter and subinterpreters, I also think these low level FIFOs should be defined as accepting any object that supports

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Fri, Sep 8, 2017 at 8:54 PM, Michel Desmoulin wrote: > > Le 09/09/2017 à 01:28, Stefan Krah a écrit : >> Still, the argument "who uses subinterpreters?" of course still remains. > > For now, nobody. But if we expose it and web frameworks manage to create > workers as

Re: [Python-Dev] PEP 549 v2: now titled Instance Descriptors

On Fri, Sep 8, 2017 at 1:45 PM, Ethan Furman wrote: > On 09/08/2017 12:44 PM, Larry Hastings wrote: > >> I've updated PEP 549 with a new title--"Instance Descriptors" is a better >> name than "Instance Properties"--and to >> clarify my rationale for the PEP. I've also updated

Re: [Python-Dev] PEP 556: Threaded garbage collection

On Fri, Sep 8, 2017 at 12:13 PM, Antoine Pitrou wrote: > On Fri, 08 Sep 2017 12:04:10 -0700 > Benjamin Peterson wrote: >> I like it overall. >> >> - I was wondering what happens during interpreter shutdown. I see you >> have that listed as a open issue.

Re: [Python-Dev] PEP 553: Built-in debug()

On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw <ba...@python.org> wrote: >> On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith <n...@pobox.com> wrote: >> This would also avoid confusion with IPython's very >> useful debug magic: >> >> https://ip

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi wrote: > Another comment from bystander point of view: it looks like the discussions > of API design and implementation are a bit entangled here. > This is much better in the current version of the PEP, but still there is a >

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function called > debug(). Adding this to your code would invoke a debugger through the hook > function sys.debughook(). The 'import pdb; pdb.set_trace()' dance

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On Tue, Sep 5, 2017 at 3:03 PM, Larry Hastings wrote: > > I've written a PEP proposing a language change: > > https://www.python.org/dev/peps/pep-0549/ > > The TL;DR summary: add support for property objects to modules. I've > already posted a prototype. Interesting idea!

Re: [Python-Dev] To reduce Python "application" startup time

On Tue, Sep 5, 2017 at 11:13 AM, Jelle Zijlstra wrote: > > > 2017-09-05 6:02 GMT-07:00 INADA Naoki : >> With this profile, I tried optimize `python -c 'import asyncio'`, logging >> and http.client. >> >> >>

Re: [Python-Dev] PEP 550 v4: coroutine policy

On Tue, Aug 29, 2017 at 12:59 PM, Yury Selivanov wrote: > b2 = wait_for(bar()) > # bar() was wrapped into a Task and is being running right now > await b2 Ah not quite. wait_for is itself implemented as a coroutine, so it doesn't spawn off bar() into its

Re: [Python-Dev] PEP 550 v4: coroutine policy

On Tue, Aug 29, 2017 at 12:32 PM, Antoine Pitrou wrote: > > > Le 29/08/2017 à 21:18, Yury Selivanov a écrit : >> On Tue, Aug 29, 2017 at 2:40 PM, Antoine Pitrou wrote: >>> On Mon, 28 Aug 2017 17:24:29 -0400 >>> Yury Selivanov

Re: [Python-Dev] PEP 550 v4

On Mon, Aug 28, 2017 at 3:14 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote: > On Sat, Aug 26, 2017 at 3:09 PM, Nathaniel Smith <n...@pobox.com> wrote: >> You might be interested in these notes I wrote to motivate why we need >> a chain of namespaces, and why simple

Re: [Python-Dev] Pep 550 and None/masking

I believe that the current status is: - assigning None isn't treated specially – it does mask any underlying values (which I think is what we want) - there is currently no way to "unmask" - but it's generally agreed that there should be a way to do that, at least in some cases, to handle the

Re: [Python-Dev] PEP 550 v4

On Sat, Aug 26, 2017 at 7:58 AM, Elvis Pranskevichus <elpr...@gmail.com> wrote: > On Saturday, August 26, 2017 2:34:29 AM EDT Nathaniel Smith wrote: >> On Fri, Aug 25, 2017 at 3:32 PM, Yury Selivanov > <yselivanov...@gmail.com> wrote: >> >

Re: [Python-Dev] PEP 550 v4

On Sat, Aug 26, 2017 at 10:25 AM, Eric Snow wrote: > With threads we have a directed graph of execution, rooted at the root > thread, branching with each new thread and merging with each .join(). > Each thread gets its own copy of each threading.local, regardless of >

Re: [Python-Dev] PEP 550 v4

On Fri, Aug 25, 2017 at 3:32 PM, Yury Selivanov wrote: > Coroutines and Asynchronous Tasks > - > > In coroutines, like in generators, context variable changes are local > and are not visible to the caller:: > > import asyncio > >

Re: [Python-Dev] PEP 550 v3 naming

On Thu, Aug 24, 2017 at 1:22 AM, Nick Coghlan wrote: > On 24 August 2017 at 02:19, Yury Selivanov wrote: >> I think that "implicit context" is not an accurate description of what >> LogicalContext is. >> >> "implicit context" only makes sense when we

Re: [Python-Dev] PEP 550 leak-in vs leak-out, why not just a ChainMap

On Wed, Aug 23, 2017 at 9:32 PM, Jim J. Jewett wrote: >> While the context is defined conceptually as a nested chain of >> key:value mappings, we avoid using the mapping syntax because of the >> way the values can shift dynamically out from under you based on who >> called

Re: [Python-Dev] PEP 550 v3 naming

On Tue, Aug 22, 2017 at 8:51 PM, Guido van Rossum <gu...@python.org> wrote: > On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> We could do worse than just plain Context and ContextStack, for that >> matter. > > > I worry th

Re: [Python-Dev] PEP 550 v3 naming

On Tue, Aug 22, 2017 at 8:22 AM, Guido van Rossum wrote: > As I understand the key APIs and constraints of the proposal better, I'm > leaning towards FooContext (LC) and FooContextStack (EC), for some value of > Foo that I haven't determined yet. Perhaps the latter can be

Re: [Python-Dev] Interrupt thread.join() with Ctrl-C / KeyboardInterrupt on Windows

On Tue, Aug 8, 2017 at 2:29 PM, Steve Dower <steve.do...@python.org> wrote: > On 08Aug2017 1151, Nathaniel Smith wrote: >> >> It looks like Thread.join ultimately ends up blocking in >> Python/thread_nt.h:EnterNonRecursiveMutex, which has a maze of #ifdefs >>

Re: [Python-Dev] Interrupt thread.join() with Ctrl-C / KeyboardInterrupt on Windows

On Tue, Aug 8, 2017 at 2:54 AM, Jonathan Slenders wrote: > Hi all, > > Is it possible that thread.join() cannot be interrupted on Windows, while it > can be on Linux? > Would this be a bug, or is it by design? > > > import threading, time > def wait(): > time.sleep(1000)

Re: [Python-Dev] startup time repeated? why not daemon

On Jul 20, 2017 14:18, "Eric Snow" wrote: On Thu, Jul 20, 2017 at 11:53 AM, Jim J. Jewett wrote: > I agree that startup time is a problem, but I wonder if some of the pain > could be mitigated by using a persistent process. > > [snip] > > Is it

Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 3.5 -- why so much difference?

I'd probably start with a regular C-level profiler, like perf or callgrind. They're not very useful for comparing two versions of code written in Python, but here the Python code is the same (modulo changes in the stdlib), and it's changes in the interpreter's C code that probably make the

Re: [Python-Dev] Impact of Namedtuple on startup time

On Jul 17, 2017 5:28 PM, "Steven D'Aprano" wrote: On Mon, Jul 17, 2017 at 09:31:20PM +, Brett Cannon wrote: > As for removing exec() as a goal, I'll back up Christian's point and the > one Steve made at the language summit that removing the use of exec() from > the

Re: [Python-Dev] Helping contributors with chores (do we have to?)

On Jun 25, 2017 10:27, "Larry Hastings" <la...@hastings.org> wrote: On 06/25/2017 10:02 AM, Nathaniel Smith wrote: My dudes, in a previous life I helped invent distributed VCS, but I still get confused by fiddly git BS just like everyone else. Really? I thought Bitkeepe

Re: [Python-Dev] Helping contributors with chores (do we have to?)

On Jun 25, 2017 08:12, "Jakub Wilk" wrote: * Paul Sokolovsky , 2017-06-25, 11:47: A GitHub PR is just a git branch (in somebody else's repository, but also > in the repository it's submitted to). So, like any git branch, you can > fetch it, re-branch to your

Re: [Python-Dev] Handle errors in cleanup code

On Tue, Jun 13, 2017 at 12:10 AM, Nick Coghlan wrote: > > reporting failures from concurrent.futures.wait: > https://pythonhosted.org/futures/#concurrent.futures.wait Yeah, and asyncio.gather is another example in the stdlib. Or there's twisted's DeferredList. Trio is

Re: [Python-Dev] Handle errors in cleanup code

On Mon, Jun 12, 2017 at 1:07 AM, Nick Coghlan wrote: > Aye, agreed. The key challenge we have is that we're trying to > represent the exception state as a linked list, when what we really > have once we start taking cleanup errors into account is an exception > *tree*. [...] >

Re: [Python-Dev] Handle errors in cleanup code

On Mon, Jun 12, 2017 at 6:29 AM, Stefan Ring wrote: > > > Yury in the comment for PR 2108 [1] suggested more complicated code: > > > > do_something() > > try: > > do_something_other() > > except BaseException as ex: > > try: > >

Re: [Python-Dev] PEP 538 warning at startup: please remove it

On Jun 12, 2017 10:50, "Gregory P. Smith" wrote: The problem, as with all warnings, is that it isn't the user who has control over the problem who sees the warning. It is the end use of an application on a system that sees it. I don't think I understand the distinction you're

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Jun 7, 2017 6:29 AM, "Victor Stinner" <victor.stin...@gmail.com> wrote: 2017-06-07 10:56 GMT+02:00 Nathaniel Smith <n...@pobox.com>: > Another testing challenge is that the stdlib ssl module has no way to > trigger a renegotiation, and therefore there's no w

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Tue, Jun 6, 2017 at 10:49 AM, Jim Baker wrote: > With Nick's suggestion of _tls_bootstrap, this has certainly become more > complicated. I'm still thinking of the ramifications for future Jython 2.7 > support, if Python dev goes down this path. It still seems easier to me

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan wrote: > The reason this kind of approach is really attractive to > redistributors from a customer risk management perspective is that > like gevent's monkeypatching of synchronous networking APIs, it's > *opt-in at runtime*, so the

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Jun 5, 2017 7:01 AM, "Nick Coghlan" wrote: On 5 June 2017 at 21:44, Donald Stufft wrote: > Is pip allowed to use the hypothetical _ensurepip_ssl outside of ensurepip? Yes, so something like _tls_bootstrap would probably be a better name for the helper

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Fri, Jun 2, 2017 at 1:29 PM, Terry Reedy wrote: > On 6/2/2017 12:21 PM, Barry Warsaw wrote: >> >> On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote: > > >>> The benefit of making any backport a private API is that it would mean >>> we weren't committing to support that API for

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Jun 2, 2017 7:24 AM, "Ben Darnell" wrote: The PEP's rationale is now "This PEP will help facilitate the future adoption of :pep:`543` across all supported Python versions, which will improve security for both Python 2 and Python 3 users." What exactly are these security

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Jun 1, 2017 9:20 AM, "Chris Angelico" wrote: On Fri, Jun 2, 2017 at 1:01 AM, Cory Benfield wrote: > The answer to that is honestly not clear to me. I chatted with the pip developers, and they have 90%+ of their users currently on Python 2, but more than

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

On Tue, May 23, 2017 at 8:34 PM, David Wilson wrote: > On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote: > >> There are discussions around Requests unvendoring its dependencies >> thanks to the improved nature of pip. This might be a year of pretty >> big

Re: [Python-Dev] Snap Python for simple distribution across multiple Linux distros

Well, it sounds like you have an answer to the question of whether the cpython developers are interested in making official snap releases, but of course this doesn't stop you making unofficial snap releases, and simple standalone python distributions can be pretty handy. I just wanted to point out

Re: [Python-Dev] windows installer and python list mention

On Mon, Apr 10, 2017 at 10:32 AM, Ethan Furman wrote: > Some people find it easier to follow this and other lists via gmane > (http://news.gmane.org/gmane.comp.python.general), a service which > offers a newsgroup interface to many online mailing lists. Also, gmane has been

Re: [Python-Dev] why _PyGen_Finalize(gen) propagates close() to _PyGen_yf() ?

On Thu, Mar 30, 2017 at 11:05 AM, Oleg Nesterov wrote: > On 03/28, Eric Snow wrote: >> >> On Mon, Mar 20, 2017 at 11:30 AM, Oleg Nesterov wrote: >> > Hello, >> > >> > Let me first clarify, I do not claim this is a bug, I am trying to learn >> > python and now I

Re: [Python-Dev] What version is an extension module binary compatible with

On Wed, Mar 29, 2017 at 8:22 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 March 2017 at 17:31, Nathaniel Smith <n...@pobox.com> wrote: >> IMO this is a bug, and depending on how many packages are affected it might >> even call for an emergency 3.6.2. The worst ca

<    1   2   3   4   5   >