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

INADA Naoki wrote: > Current `python -v` is not useful to optimize import. > So I use this patch to profile import time. > https://gist.github.com/methane/e688bb31a23bcc437defcea4b815b1eb I have implemented DTrace probes that do almost the same thing. Your patch is better

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

> I’m not sure however whether burying imports inside functions (as a kind of > poor man’s lazy import) is ultimately going to be satisfying. First, it’s > not natural, it generally violates coding standards (e.g. PEP 8), and can > make linters complain. Of course, I tried to move imports

[Python-Dev] Map and Wirelessly Control the Human Brain Using 50 Nanometer Particles and Radio Waves

If you are not able to see this mail, click http://r.sciencemedia.eu/336n1lt27ors7f.htmlHello, I'm a computer programmer from Romania. I'm very interested in neuroscience. I have some ideas for an international science project. The project is about increasing the worldwide efforts to map the

Re: [Python-Dev] PEP 550 v4

On Wednesday, September 6, 2017 8:06:36 PM EDT Greg Ewing wrote: > Nathaniel Smith wrote: > > The implementation strategy changed radically between v1 > > and v2 because of considerations around generator (not coroutine) > > semantics. I'm not sure what more it can do to dispel these > > feelings>

[Python-Dev] New C API not leaking implementation details: an usable stable ABI

Hi, I am currently at a CPython sprint 2017 at Facebook. We are discussing my idea of writing a new C API for CPython hiding implementation details and replacing macros with function calls. I wrote a short blog post to explain the issue of the current API, the link between the API and the ABI,

[Python-Dev] Python 3.3.7rc1 now available prior to Python 3.3 end-of-life

On behalf of the Python development community and the Python 3.3 release teams, I would like to announce the availability of Python 3.3.7rc1, the release candidate of Python 3.3.7. It is a security-fix source-only release. Python 3.3.0 was released 5 years ago on 2012-09-29 and has been in

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

On Sep 6, 2017, at 16:55, Fernando Perez wrote: > > If I may suggest a small API tweak, I think it would be useful if > breakpoint() accepted an optional header argument. In IPython, the equivalent > for non-postmortem debugging is IPython.embed, which can be given a

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 5:06 PM, Greg Ewing wrote: > Nathaniel Smith wrote: >> >> The implementation strategy changed radically between v1 >> and v2 because of considerations around generator (not coroutine) >> semantics. I'm not sure what more it can do to dispel

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 5:00 PM, Greg Ewing wrote: > Nathaniel Smith wrote: >> >> Literally the first motivating example at the beginning of the PEP >> ('def fractions ...') involves only generators, not coroutines, and >> only works correctly if generators get special

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 4:27 PM, Greg Ewing wrote: > Ivan Levkivskyi wrote: >> >> Normal generators fall out from this "scheme", and it looks like their >> behavior is determined by the fact that coroutines are implemented as >> generators. > > > This is what I

Re: [Python-Dev] PEP 550 v4

Nathaniel Smith wrote: The implementation strategy changed radically between v1 and v2 because of considerations around generator (not coroutine) semantics. I'm not sure what more it can do to dispel these feelings :-). I can't say the changes have dispelled any feelings on my part. The

Re: [Python-Dev] PEP 550 v4

Nathaniel Smith wrote: Literally the first motivating example at the beginning of the PEP ('def fractions ...') involves only generators, not coroutines, and only works correctly if generators get special handling. (In fact, I'd be curious to see how Greg's {push,pop}_local_storage could handle

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

If I may suggest a small API tweak, I think it would be useful if breakpoint() accepted an optional header argument. In IPython, the equivalent for non-postmortem debugging is IPython.embed, which can be given a header. This is useful to provide the user with some information about perhaps

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 1:39 PM, Koos Zevenhoven wrote: [..] > Now this was of course a completely fictional example, and hopefully I > didn't introduce any bugs or syntax errors other than the ones I described. > I haven't seen code like this anywhere, but somehow we caught the

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

On Sep 6, 2017, at 00:42, INADA Naoki wrote: > Additionally, faster startup time (and smaller memory footprint) is good > for even Web applications. > For example, CGI is still comfortable tool sometimes. > Another example is GAE/Python. > > Anyway, I think researching

Re: [Python-Dev] PEP 550 v4

Ivan Levkivskyi wrote: Normal generators fall out from this "scheme", and it looks like their behavior is determined by the fact that coroutines are implemented as generators. This is what I disagree with. Generators don't implement coroutines, they implement *parts* of coroutines. We want

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum wrote: > I'm actually not in favor of this. It's another way to do the same thing. > Sorry to rain on your dream! So it goes :) I learned things by going through the process, so it wasn't wasted time for me even if (or

Re: [Python-Dev] Compiling without multithreading support -- still useful?

2017-09-06 22:19 GMT+02:00 Berker Peksağ : > Do we still have buildbots for testing the --without-threads option? We had such buildbot once, but it's gone. I just removed its unused class from the buildbot configuration:

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 1:39 PM, Koos Zevenhoven wrote: > On Wed, Sep 6, 2017 at 8:16 PM, Guido van Rossum wrote: > >> On Wed, Sep 6, 2017 at 8:07 AM, Koos Zevenhoven >> wrote: >> >>> I think yield from should have the same semantics as

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

On Sep 6, 2017, at 14:59, Terry Reedy wrote: > > Currently, the debugger is started in response to a menu seletion in the IDLE > process while the python process is idle. One reason for the 'idle' > requirement' is because when code is exec-uting, the loop that reads >

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

On Sep 6, 2017, at 10:14, Fabio Zadrozny wrote: > > I think it's a nice idea. Great! > Related to the name, on the windows c++ there's "DebugBreak": > https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx, > which I think is a better name (so,

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

> On 6 Sep 2017, at 00:03, 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

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

On 9/6/2017 10:42 AM, Barry Warsaw wrote: I don’t think that’s a good idea. pdb is a thing, and that thing is the standard library debugger. I don’t think ‘pdb’ should be the term we use to describe a generic Python debugger interface. That to me is one of the advantages of PEP 553; it

Re: [Python-Dev] Cherry picker bot deployed in CPython repo

Update: Older merged PRs not yet backported? == A core developer can re-apply the `needs backport ..` label to trigger the backport. Meaning, remove the existing label, then add it back. If there was no label and now you want it to be backported, adding the label will

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

On Wed, Sep 6, 2017 at 1:52 AM, Nathaniel Smith wrote: ​[...]​ > import sys, types > class _MyModuleType(types.ModuleType): > @property > def ... > > @property > def ... > sys.modules[__name__].__class__ = _MyModuleType > > It's definitely true though that

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 8:22 PM, Yury Selivanov wrote: ​[...] ​ > PEP 550 treats coroutines and generators as objects that support out > of order execution. ​Out of order? More like interleaved.​ ​​ > PEP 555 still doesn't clearly explain how exactly it is different

Re: [Python-Dev] Consolidate stateful runtime globals

On 9/6/2017 1:18 PM, Gregory P. Smith wrote: I'm not concerned about moving things into a state structure rather than wildly scattered globals declared all over the place.  It is good code hygiene. It ultimately moves us closer (much more work to be done) to being able to actually have

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 8:16 PM, Guido van Rossum wrote: > On Wed, Sep 6, 2017 at 8:07 AM, Koos Zevenhoven wrote: > >> I think yield from should have the same semantics as iterating over the >> generator with next/send, and PEP 555 has no issues with this. >>

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, 06 Sep 2017 20:18:52 + "Gregory P. Smith" wrote: > > For commonly typed things that get annoying, > > #define _Py_grail _PyRuntme.ceval.holy.grail > > within the .c source file that does a lot of grail flinging seems fine to > me. That sounds fine to me too.

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

On Sep 6, 2017, at 10:19, Guido van Rossum wrote: > > 99% of the time I use a debugger I use pdb.set_trace(). The pm() stuff is > typically useful for debugging small, simple programs only -- complex > programs likely hide the exception somewhere (after logging it) so there's

Re: [Python-Dev] Compiling without multithreading support -- still useful?

On Tue, Sep 5, 2017 at 7:42 PM, Victor Stinner wrote: > I'm strongly in favor of dropping this option from Python 3.7. It > would remove a lot of code! +1 Do we still have buildbots for testing the --without-threads option? --Berker

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017 at 10:26 AM Benjamin Peterson wrote: > > On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote: > > On Wed, 06 Sep 2017 09:42:29 -0700 > > Benjamin Peterson wrote: > > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > > > > >

Re: [Python-Dev] Compiling without multithreading support -- still useful?

My take on platforms without thread support is that they should provide a their own fake/green/virtual threading APIs. I don't know how practical that thought actually is for things like web assembly but I'm with Antoine here. The maintenance burden for --without-threads builds is a pain I'd

Re: [Python-Dev] Compiling without multithreading support -- still useful?

Certainly, I understand it can be burdensome. I suppose I can use 3.6 branch for the initial port, so it shouldn't be an issue. On Wed, Sep 6, 2017 at 11:13 AM, Antoine Pitrou wrote: > On Wed, 6 Sep 2017 10:50:11 -0700 > Ethan Smith wrote: > > I think

Re: [Python-Dev] Compiling without multithreading support -- still useful?

On Wed, 6 Sep 2017 10:50:11 -0700 Ethan Smith wrote: > I think this is useful as it can make porting easier. I am using it in my > attempts to cross compile CPython to WebAssembly (since WebAssembly in its > MVP does not support threading). The problem is that the burden of

Re: [Python-Dev] Compiling without multithreading support -- still useful?

I think this is useful as it can make porting easier. I am using it in my attempts to cross compile CPython to WebAssembly (since WebAssembly in its MVP does not support threading). On Wed, Sep 6, 2017 at 10:15 AM, Antoine Pitrou wrote: > > I made an experimental PR to

Re: [Python-Dev] PEP 548: More Flexible Loop Control

I'm actually not in favor of this. It's another way to do the same thing. Sorry to rain on your dream! On Wed, Sep 6, 2017 at 9:34 AM, R. David Murray wrote: > On Wed, 06 Sep 2017 15:05:51 +1000, Chris Angelico > wrote: > > On Wed, Sep 6, 2017 at 10:11

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 8:07 AM, Koos Zevenhoven wrote: > On Wed, Sep 6, 2017 at 10:07 AM, Greg Ewing > wrote: >> >> Yury Selivanov wrote: >>> >>> Greg, have you seen this new section: >>> >>>

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

99% of the time I use a debugger I use pdb.set_trace(). The pm() stuff is typically useful for debugging small, simple programs only -- complex programs likely hide the exception somewhere (after logging it) so there's nothing for pdb.pm() to look at. I think Barry is wisely focusing on just the

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote: > On Wed, 06 Sep 2017 09:42:29 -0700 > Benjamin Peterson wrote: > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > > > > > Hello, > > > > > > I'm a bit concerned about > > >

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 8:07 AM, Koos Zevenhoven wrote: > I think yield from should have the same semantics as iterating over the > generator with next/send, and PEP 555 has no issues with this. > I think the onus is on you and Greg to show a realistic example that shows why

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

On Wed, Sep 6, 2017 at 10:26 AM, Guido van Rossum wrote: > > So we've seen a real use case for __class__ assignment: deprecating things on > access. That use case could also be solved if modules natively supported > defining __getattr__ (with the same "only used if attribute

Re: [Python-Dev] Compiling without multithreading support -- still useful?

I made an experimental PR to remove support for threads-less builds: https://github.com/python/cpython/pull/3385 The next effect is to remove almost 2000 lines of code (including many #ifdef sections in C code). Regards Antoine. On Tue, 5 Sep 2017 18:36:51 +0200 Antoine Pitrou

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

Hi Barry, I think it's a nice idea. Related to the name, on the windows c++ there's "DebugBreak": https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx, which I think is a better name (so, it'd be debug_break for Python -- I think it's better than plain breakpoint(),

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, 06 Sep 2017 09:42:29 -0700 Benjamin Peterson wrote: > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > > > Hello, > > > > I'm a bit concerned about > > https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd940923357351 > > > > My main gripe

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 10:07 AM, Greg Ewing wrote: > Yury Selivanov wrote: > >> Greg, have you seen this new section: >> https://www.python.org/dev/peps/pep-0550/#should-yield-from- >> leak-context-changes >> > > That section seems to be addressing the idea of a

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

On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw wrote: >> On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith wrote: >> This would also avoid confusion with IPython's very >> useful debug magic: >> >>

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

On Wed, Sep 6, 2017 at 9:15 AM, Ivan Levkivskyi wrote: > > On 6 September 2017 at 17:26, Guido van Rossum wrote: > >> >> Is there a real use case for @property? Otherwise, if we're going to mess >> with module's getattro, it makes more sense to add

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > Hello, > > I'm a bit concerned about > https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd940923357351 > > My main gripe is that makes writing C code more tedious. Simple C > global variables such as "_once_registry"

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

On Sep 6, 2017, at 07:46, Guido van Rossum wrote: > > IIRC they indeed insinuate debug() into the builtins. My suggestion is also > breakpoint(). breakpoint() it is then! I’ll rename the sys hooks too, but keep the naming scheme of the existing sys hooks. Cheers, -Barry

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On Wed, 06 Sep 2017 15:05:51 +1000, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray > wrote: > > I've written a PEP proposing a small enhancement to the Python loop > > control statements. Short version: here's what feels to me

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

On 6 September 2017 at 17:26, Guido van Rossum wrote: > > Is there a real use case for @property? Otherwise, if we're going to mess > with module's getattro, it makes more sense to add __getattr__, which would > have made Nathaniel's use case somewhat simpler. (Except for the

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

So we've seen a real use case for __class__ assignment: deprecating things on access. That use case could also be solved if modules natively supported defining __getattr__ (with the same "only used if attribute not found otherwise" semantics as it has on classes), but it couldn't be solved using

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

> Anyway, I think researching import tree of popular library is good > startline > about optimizing startup time. > I agree -- in this case, you've identified that asyncio is expensive -- good to know. In the jinja2 case, does it always need asyncio? Pep8 as side, I think it often makes sense

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

On Wed, Sep 6, 2017 at 10:46 AM, Guido van Rossum wrote: > IIRC they indeed insinuate debug() into the builtins. My suggestion is > also breakpoint(). > I'm also a bigger fan of the `breakpoint` name. `debug` as a name is already pretty widely used, plus breakpoint is more

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 12:07 AM, Greg Ewing wrote: > Yury Selivanov wrote: [..] > I don't see a lot of value in trying to automagically > isolate changes to global state *only* in generators. > > Under PEP 550, if you want to e.g. change the decimal > context

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

IIRC they indeed insinuate debug() into the builtins. My suggestion is also breakpoint(). On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw wrote: > On Sep 5, 2017, at 20:15, Guido van Rossum wrote: > > > > Yeah, I like the idea, but I don't like the debug() name

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 5:58 AM, Ivan Levkivskyi wrote: > On 6 September 2017 at 11:13, Nathaniel Smith wrote: >> >> On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi >> wrote: >> > Normal generators fall out from this "scheme", and it

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

On Wed, Sep 6, 2017 at 3:49 AM, INADA Naoki wrote: > OK, I stop worring about thread safety and other implementation > detail behavior on edge cases. > That sounds like overreacting. At the risk of stating the obvious: I want the data structure itself to maintain its

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

On Sep 5, 2017, at 19:31, Giampaolo Rodola' wrote: > > True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" > -> TAB it auto completes it. > > Somehow I think debug() would make this a bit harder as it's more likely a > "debug()" line will pass

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

On Wednesday, September 6, 2017, INADA Naoki wrote: > > How significant is application startup time to something that uses > > Jinja2? Are there short-lived programs that use it? Python startup > > time matters enormously to command-line tools like Mercurial, but far > >

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

On Sep 5, 2017, at 20:15, Guido van Rossum wrote: > > Yeah, I like the idea, but I don't like the debug() name -- IIRC there's a > helper named debug() in some codebase I know of that prints its arguments > under certain circumstances. > > On Tue, Sep 5, 2017 at 7:58 PM,

Re: [Python-Dev] PEP 550 v4

On 6 September 2017 at 11:13, Nathaniel Smith wrote: > On Wed, Sep 6, 2017 at 1:49 AM, Ivan Levkivskyi > wrote: > > Normal generators fall out from this "scheme", and it looks like their > > behavior is determined by the fact that coroutines are implemented

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

https://www.youtube.com/watch?v=pNe1wWeaHOU=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i=1 On Wed, Sep 6, 2017 at 5:49 PM, INADA Naoki wrote: > OK, I stop worring about thread safety and other implementation > detail behavior on edge cases. > > Thanks, > > INADA Naoki

Re: [Python-Dev] PEP 548: More Flexible Loop Control

https://www.youtube.com/watch?v=pNe1wWeaHOU=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i=1 Thank you, -Alex Goretoy On Wed, Sep 6, 2017 at 7:05 PM, Ben Hoyt wrote: > I think Serhiy's response is excellent and agree with it. My gut reaction is > "this looks like Perl" (and not in a good

Re: [Python-Dev] PEP 548: More Flexible Loop Control

I think Serhiy's response is excellent and agree with it. My gut reaction is "this looks like Perl" (and not in a good way), but more specifically it makes the control flow almost invisible. So I'm definitely -1 on this. The current while True ... break idiom is not pretty, but it's also very

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

OK, I stop worring about thread safety and other implementation detail behavior on edge cases. Thanks, INADA Naoki On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore wrote: > On 6 September 2017 at 11:09, Antoine Pitrou wrote: >> On

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

On 6 September 2017 at 11:09, Antoine Pitrou wrote: > On Wed, 6 Sep 2017 11:26:52 +0900 > INADA Naoki wrote: >> >> Like that, should we say "atomic & threadsafe __setitem__ for simple >> key is implementation detail of CPython and PyPy. We recommend

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

On Wed, 6 Sep 2017 11:26:52 +0900 INADA Naoki wrote: > > Like that, should we say "atomic & threadsafe __setitem__ for simple > key is implementation detail of CPython and PyPy. We recommend > using mutex when using OrderedDict from multiple thread."? I think you may be

[Python-Dev] Consolidate stateful runtime globals

Hello, I'm a bit concerned about https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd940923357351 My main gripe is that makes writing C code more tedious. Simple C global variables such as "_once_registry" are now spelled "_PyRuntime.warnings.once_registry". The most

Re: [Python-Dev] PEP 550 v4

On Wed, Sep 6, 2017 at 12:13 PM, Nathaniel Smith wrote: > 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

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 550 v4

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 _feelling_ that some design decisions are influenced by the implementation strategy.

Re: [Python-Dev] PEP 548: More Flexible Loop Control

On 6 September 2017 at 08:42, Serhiy Storchaka wrote: > 06.09.17 03:11, R. David Murray пише: > >> I've written a PEP proposing a small enhancement to the Python loop >> control statements. Short version: here's what feels to me like a >> Pythonic way to spell "repeat

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

> How significant is application startup time to something that uses > Jinja2? Are there short-lived programs that use it? Python startup > time matters enormously to command-line tools like Mercurial, but far > less to something that's designed to start up and then keep running > (eg a web app,

Re: [Python-Dev] PEP 550 v4

Yury Selivanov wrote: Greg, have you seen this new section: https://www.python.org/dev/peps/pep-0550/#should-yield-from-leak-context-changes That section seems to be addressing the idea of a generator behaving differently depending on whether you use yield-from on it. I never suggested that,

Re: [Python-Dev] PEP 548: More Flexible Loop Control

06.09.17 03:11, R. David Murray пише: I've written a PEP proposing a small enhancement to the Python loop control statements. Short version: here's what feels to me like a Pythonic way to spell "repeat until": while: break if The PEP goes into some detail on why this