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 support the >object then TypeError is raise

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

On Wed, Sep 13, 2017 at 11:56 PM, Nick Coghlan wrote: [..] >>send(obj): >> >>Send the object to the receiving end of the channel. Wait until >>the object is received. If the channel does not support the >>object then TypeError is raised. Currently only bytes are >>

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

On 14 September 2017 at 11:44, Eric Snow wrote: > I've updated PEP 554 in response to feedback. (thanks all!) There > are a few unresolved points (some of them added to the Open Questions > section), but the current PEP has changed enough that I wanted to get > it out there first. > > Notably ch

Re: [Python-Dev] PEP 553, v3

On 9/13/2017 10:12 PM, Barry Warsaw wrote: Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class feature. I’ve also updated PR #3355 with the implementation to match. Looks pretty good to me. Reading the PR eliminated my remaining uncertainties. -- Terry Jan Reedy ___

[Python-Dev] PEP 553, v3

Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class feature. I’ve also updated PR #3355 with the implementation to match. Cheers, -Barry PEP: 553 Title: Built-in breakpoint() Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017-09

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

I've updated PEP 554 in response to feedback. (thanks all!) There are a few unresolved points (some of them added to the Open Questions section), but the current PEP has changed enough that I wanted to get it out there first. Notably changed: * the API relative to object passing has changed som

Re: [Python-Dev] parallelizing

On Wed, Sep 13, 2017 at 12:11 PM, Matthieu Bec wrote: > Regarding your example, I think it gives the illusion to work because > sleep() is GIL aware under the hood. > > It'll work for anything -- it just may not buy you any performance. I don't know off the top of my head if file I/O captures th

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

On Wed, Sep 13, 2017 at 3:01 PM, Ivan Levkivskyi wrote: > @Guido > > One would have to introduce some kind of convention > > where you can write properties with a leading _ > > One doesn't even need the @property decorator in this case. > For example: > > def __getattr__(name): > g = globals(

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

@Guido > One would have to introduce some kind of convention > where you can write properties with a leading _ One doesn't even need the @property decorator in this case. For example: def __getattr__(name): g = globals() name = '_' + name if name in g: return g[name]() rai

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

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

Re: [Python-Dev] A reminder for PEP owners

> But someone has to > review and accept all those PEPs, and I can't do it all by myself. An alternate definition for BDFL is "Benevolent Delegator For Life." :-) Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/lis

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 put into your > mod

Re: [Python-Dev] parallelizing

Thank you, I'll take your advice. Regarding your example, I think it gives the illusion to work because sleep() is GIL aware under the hood. I don't think it works for process() that mainly runs bytecode, because of the GIL. Sorry if I wrongly thought that was a language level discussion.

[Python-Dev] A reminder for PEP owners

I know there's a lot of excitement around lots of new ideas. And the 3.7 feature freeze is looming (January is in a few months). But someone has to review and accept all those PEPs, and I can't do it all by myself. If you want your proposal to be taken seriously, you need to include a summary of t

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

> 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 put into your module if you want @property support. That way you can have both but yo

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

Why not adding both? Properties do have their uses as does __getattr__. Cheers, Sven On 13.09.2017 11:43, Larry Hastings wrote: On 09/12/2017 12:38 AM, Larry Hastings wrote: On 09/11/2017 07:22 PM, Guido van Rossum wrote: The prototype is linked to from the PEP; for your convenience

Re: [Python-Dev] parallelizing

This really isn't the place to ask this kind of question. If you want to know how to do something with python, try python-users , stack overflow, etc. If you have an idea about a new feature you think python could have, then the python-ideas list is the place for that. But if you want anyone to t

Re: [Python-Dev] Reminder: snapshots and releases coming up in the next several days

I know the issue of the Google Calendar feed has come up before and we should either maintain it or remove it from the web site. I don't know who has or had the "keys" to it. I'm traveling the next couple of days but I'll look into it afterwards. If anyone has info about it, please contact me di

Re: [Python-Dev] Reminder: snapshots and releases coming up in the next several days

On Wed, Sep 13, 2017 at 12:35 PM, Ned Deily wrote: > Lots of releases coming up soon! There's a "Python Release Schedule" calendar on Google Calendar that used to be maintained, but that appears to have been dropped, though I found it useful. Is there any sort of calendar feed available with thi

[Python-Dev] Reminder: snapshots and releases coming up in the next several days

Lots of releases coming up soon! 2017-09-16: - Python 2.7.14 final release 2017-09-18 1200 UTC cutoff: - Python 3.6.3 rc1 - Python 3.3.7 final release (following by retirement) If you know of any issues that you feel need to be addressed in these releases, please make sure there is an open issu

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

On 09/12/2017 12:38 AM, Larry Hastings wrote: On 09/11/2017 07:22 PM, Guido van Rossum wrote: The prototype is linked to from the PEP; for your convenience here's a link: https://github.com/larryhastings/cpython/tree/module-properties

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

On 9/10/2017 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 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 fiel