On 21/04/20 10:23 am, Eric Snow wrote:
with the current spec channels get automatically closed
sooner, effectively as soon as all wrapping objects *that were used*
are garbage collected (or released).
Maybe I'm missing something, but just because an object
hasn't been used *yet* doesn't mean it
Nathaniel,
Your tone and approach to this conversation concern me. I appreciate
that you have strong feelings here and readily recognize I have my own
biases, but it's becoming increasingly hard to draw any constructive
insight from what tend to be very longs posts from you. It ends up
being a l
On Mon, Apr 20, 2020 at 5:36 PM Edwin Zimmerman wrote:
>
> On 4/20/2020 7:33 PM, Nathaniel Smith wrote:
> > On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman
> > wrote:
> >> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> >>> We already have robust support for threads for low-isolation and
> >>> su
On 4/20/2020 7:33 PM, Nathaniel Smith wrote:
> On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman
> wrote:
>> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
>>> We already have robust support for threads for low-isolation and
>>> subprocesses for high-isolation. Can you name some use cases where
>>> n
On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> We already have robust support for threads for low-isolation and
> subprocesses for high-isolation. Can you name some use cases where
> neither of these are appropriate and you instead want an in-between
> isolation – like subprocesses, but more fragil
On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman wrote:
>
> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> > We already have robust support for threads for low-isolation and
> > subprocesses for high-isolation. Can you name some use cases where
> > neither of these are appropriate and you instead w
This will be a nice improvement.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.pyt
Please consider adding underscores to the names: remove_prefix() and
remove_suffix().
The latter method causes a mental hiccup when first read as removes-uffix,
forcing mental backtracking to get to remove-suffix. We had a similar problem
with addinfourl initially being read as add-in-four-l b
On Mon, Apr 20, 2020 at 4:23 PM Eric Snow wrote:
> As I've gone to update the PEP for this I'm feeling less comfortable
> with changing it.
Also, the resulting text of the PEP makes it a little harder to follow
when an interpreter gets associated. However, this is partly an
artifact of the struc
On Fri, Apr 17, 2020 at 3:57 PM Eric Snow wrote:
>
> On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote:
> > I think some perspective might be useful here :-).
> >
> > The last time we merged a new concurrency model in the stdlib, it was
> > asyncio.
> >
> > [snip]
> >
> > OTOH, AFAICT the ne
On Mon, Apr 20, 2020 at 4:19 PM Greg Ewing wrote:
>
> On 21/04/20 8:29 am, Eric Snow wrote:
> > * Would a low-level channel implementation based on callbacks or locks
> > be better (simpler, faster, etc.) than one based on buffering?
>
> Depends on what you mean by "better". Callbacks are more
> v
On Mon, Apr 20, 2020 at 2:22 PM Eric Snow wrote:
> On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> > * The "association" timing seems quirky and potentially annoying: an
> > interpreter only becomes associated with a channel the first time it
> > calls recv() or send(). How about, i
On 21/04/20 8:29 am, Eric Snow wrote:
* Would a low-level channel implementation based on callbacks or locks
be better (simpler, faster, etc.) than one based on buffering?
Depends on what you mean by "better". Callbacks are more
versatile; a buffered channel just does buffering, but
with callba
Congrats Paul! This one wasn't easy!
When Paul got promoted, I asked him if he could write a PEP about the
local timezone. Well, here we are ;-)
Paul: can I now also get nanosecond resolution? :-D
https://bugs.python.org/issue15443
Oh, and leap seconds?
https://bugs.python.org/issue23574
I comm
Congrats Paul! I am very happy that we'll get tz support built into the
stdlib.
On Mon, Apr 20, 2020 at 1:33 PM Barry Warsaw wrote:
> The Python Steering Council accepts PEP 615 - Support for the IANA Time
> Zone Database in the Standard Library:
>
> https://www.python.org/dev/peps/pep-0615/
>
On Mon, 20 Apr 2020 14:22:03 -0600
Eric Snow wrote:
>
> > The appeal of the PEP for experimentations is multiple:
> > 1) ability to concurrently run independent execution environments
> >without spawning child processes (which on some platforms and in some
> >situations may not be very de
Congrats Dennis! I hope your PR lands soon.
On Mon, Apr 20, 2020 at 12:40 PM Eric V. Smith wrote:
> Congratulations, Dennis!
>
> Not 10 minutes ago I was writing code that could have used this
> functionality. And I got it wrong on my first attempt! I'm looking
> forward to it in 3.9.
>
> Eric
>
On Sat, Apr 18, 2020 at 6:50 PM Greg Ewing wrote:
> On 19/04/20 5:02 am, Antoine Pitrou wrote:
> > * How hard would it be, in the current implementation, to add buffering
> >to channels?
> >
> > * In the same vein, I think channels should allow adding readiness
> >callbacks
>
> Of these, I
The Python Steering Council accepts PEP 615 - Support for the IANA Time Zone
Database in the Standard Library:
https://www.python.org/dev/peps/pep-0615/
Congratulations Paul Ganssle!
This is a fantastic, well written PEP, and we appreciate Paul’s engagement with
the SC to clear up our last qu
Thanks for the feedback, Antoine. I've responded inline below and
will be making appropriate changes to the PEP. One point I'd like to
reinforce before my comments is the PEP's emphasis on minimalism.
>From PEP 554:
This proposal is focused on enabling the fundamental capability of
mult
On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> * I do think a minimal synchronization primitive would be nice.
> Either a Lock (in the Python sense) or a Semaphore: both should be
> relatively easy to provide, by wrapping an OS-level synchronization
> primitive. Then you can recre
Congratulations, Dennis!
Not 10 minutes ago I was writing code that could have used this
functionality. And I got it wrong on my first attempt! I'm looking
forward to it in 3.9.
Eric
On 4/20/2020 2:26 PM, Victor Stinner wrote:
Hi,
The Python Steering Council accepts the PEP 616 "String met
Congratulations!
On Mon, Apr 20, 2020, 9:30 PM Brett Cannon wrote:
> The steering council is happy to announce that we have accepted PEP 617!
> Thanks to the PEP authors for all their hard work (which includes sending a
> PR to update the acceptance of the PEP 😉).
>
Hi,
The Python Steering Council accepts the PEP 616 "String methods to
remove prefixes and suffixes":
https://www.python.org/dev/peps/pep-0616/
Congrats Dennis Sweeney!
We just have one last request: we expect the documentation to explain
well the difference between removeprefix()/removesuffix()
The steering council is happy to announce that we have accepted PEP 617!
Thanks to the PEP authors for all their hard work (which includes sending a PR
to update the acceptance of the PEP 😉).
___
Python-Dev mailing list -- python-dev@python.org
To unsu
And thank you, Benjamin!
Where's the virtual party?
--Guido
On Mon, Apr 20, 2020 at 08:09 Benjamin Peterson wrote:
> I'm eudaemonic to announce the immediate availability of Python 2.7.18.
>
> Python 2.7.18 is a special release. I refer, of course, to the fact that
> "2.7.18" is the closest an
I'm eudaemonic to announce the immediate availability of Python 2.7.18.
Python 2.7.18 is a special release. I refer, of course, to the fact that
"2.7.18" is the closest any Python version number will ever approximate e,
Euler's number. Simply exquisite!
A less transcendent property of Python 2.
> In every use-case that I've ever had, and every one that I can
> imagine, I've not cared about the difference between "US/Eastern" and
> "America/New_York". In fact, if ZoneInfo("US/Eastern") returned
> something that had a name of "America/New_York", I would be fine with
> that. Similarly, Austr
> In every use-case that I've ever had, and every one that I can
> imagine, I've not cared about the difference between "US/Eastern" and
> "America/New_York". In fact, if ZoneInfo("US/Eastern") returned
> something that had a name of "America/New_York", I would be fine with
> that. Similarly, Austr
29 matches
Mail list logo
