On Sun, 05 Apr 2015 01:06:01 -0700
Larry Hastings wrote:
>
> On 04/04/2015 08:21 PM, Nathaniel Smith wrote:
> > (I guess you could call Larry or someone, read them a hash over the
> > phone, and then have them create the actual gpg signatures.)
>
> By sheer coincidence, I believe Steve and I bot
On Tue, 07 Apr 2015 03:11:30 +0100
Rob Cliffe wrote:
>
> On 07/04/2015 02:08, Guido van Rossum wrote:
> > I've taken the liberty of adding the following old but good rule to
> > PEP 8 (I was surprised to find it wasn't already there since I've
> > lived by this for ages):
> >
> > *
> >
> >
On Mon, 20 Apr 2015 20:43:38 -0400
"R. David Murray" wrote:
> +1 to this from me too. I'm afraid that means I'm -1 on the PEP.
>
> I didn't write this in my earlier email because I wasn't sure about it,
> but my gut reaction after reading Harry's email was "if type annotations
> are used in the s
On Tue, 21 Apr 2015 22:47:23 +1000
Steven D'Aprano wrote:
>
> Ironically, type hinting will *reduce* the need for intrusive,
> anti-duck-testing explicit calls to isinstance() at runtime:
It won't, since as you pointed out yourself, type checks are purely
optional and entirely separate from com
On Tue, 21 Apr 2015 23:16:19 +1000
Steven D'Aprano wrote:
>
> I could keep going, but I hope I've made my point.
I don't think so. Just because other languages are looking at it
doesn't mean it will end up successful. It means it's an interesting
idea, that's all.
A litmus test for this PEP wou
Le 21/04/2015 15:50, Paul Sokolovsky a écrit :
> Hello,
>
> On Tue, 21 Apr 2015 15:08:27 +0200
> Antoine Pitrou wrote:
>
> []
>
>> Because the user might not run the type checker, obviously. To quote
>> you: """When we say that type checking is
On Tue, 21 Apr 2015 09:28:45 -0700
Guido van Rossum wrote:
> On Tue, Apr 21, 2015 at 12:49 AM, Antoine Pitrou
> wrote:
>
> > On Mon, 20 Apr 2015 20:43:38 -0400
> > "R. David Murray" wrote:
> > > +1 to this from me too. I'm afraid that means I'm
On Tue, 21 Apr 2015 18:27:50 +0300
Paul Sokolovsky wrote:
> Let me try: MicroPython already uses type annotations for statically
> typed functions. E.g.
>
> def add(x:int, y:int):
> return x + y
>
> will translate the function to just 2 machine instructions.
That's quite nice.
> Oh really,
Hi,
I agree with most of Wolfgang's points below. As a data point, I
haven't used asyncio for anything real (despite having approved the
PEP!), but I have some extensive prior experience with Twisted and
Tornado :-)
Regards
Antoine.
On Thu, 23 Apr 2015 09:30:30 +0200
Wolfgang Langner wrote:
On Thu, 23 Apr 2015 09:21:11 +0200
Andrea Griffini wrote:
> It's not the first time someone is confused by the server example of
>
> https://docs.python.org/3/library/socketserver.html
>
> where the receiving side is not making a loop over recv.
This is a trivial example indeed. If you think so
On Thu, 23 Apr 2015 09:58:33 -0700
Guido van Rossum wrote:
> I think this is the nail in PEP 3152's coffin.
If you only put one nail, it might manage to get out.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
On Thu, 30 Apr 2015 10:02:17 +0100
Paul Moore wrote:
>
> Of course, if asyncio and the PEP *are* only really relevant to
> network protocols, then my impressions are actually correct and I
> should drop out of the discussion. But if that's the case, it seems
> like a lot of language change for a
On Thu, 30 Apr 2015 09:59:34 +0200
"M.-A. Lemburg" wrote:
>
> Can we please make the monkeypatch a regular part of Python's
> site.py which can enabled via an environment variable, say
> export PYTHONHTTPSVERIFY=0.
-1 (already explained in the bug below).
> See http://bugs.python.org/issue23857
On Thu, 30 Apr 2015 12:32:02 -0700
Guido van Rossum wrote:
>
> No, this is the name we've been using since PEP 342 and it's still the same
> concept.
The fact that all syntax uses the word "async" and not "coro" or
"coroutine" hints that it should really *not* be called a coroutine
(much less a
On Fri, 1 May 2015 13:10:01 -0700
Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett wrote:
>
> > If there are more tasks than executors, yield is a way to release your
> > current executor and go to the back of the line. I'm pretty sure I
> > saw several examples of that
Using an environment variable to disable a security feature sounds like
an extremely bad idea. Environment variables are hidden state.
Generally you don't know up front which values they will have when
running an executable, and people don't think about inspecting them.
This opens the door to mist
I'm in entire agreement with Donald below.
Regards
Antoine.
On Mon, 11 May 2015 06:23:11 -0400
Donald Stufft wrote:
>
> I don't really agree that the decision to disable TLS is an environment one,
> it's really a per application decision. This is why I was against having some
> sort of glob
On Tue, 12 May 2015 10:04:39 -0700
Larry Hastings wrote:
>
> Workflow 1
> ==
>
> When I ship beta 1, we create the 3.5 branch. trunk become 3.6.
>
> When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically
> visible repo /on bitbucket/ for 3.5.0, and we use bitbucket "
On Wed, 13 May 2015 18:15:10 -0400
Terry Reedy wrote:
> On 5/13/2015 5:45 PM, Zachary Ware wrote:
> > On Wed, May 13, 2015 at 4:05 PM, Terry Reedy wrote:
> >> Python 2.7.8+ (default, May 13 2015, 16:46:29) [MSC v.1500 32 bit (Intel)]
> >> on win32
> >>
> >> Shouldn't this be 2.7.9+ or 2.7.10rc1?
On Fri, 15 May 2015 09:28:07 +0300
Serhiy Storchaka wrote:
> On 14.05.15 00:38, yury.selivanov wrote:
> > https://hg.python.org/cpython/rev/ee31277386cb
> > changeset: 96038:ee31277386cb
> > user:Yury Selivanov
> > date:Wed May 13 17:18:41 2015 -0400
> > summary:
> >inspect:
I've proposed a PEP 11 update in this PR:
https://github.com/python/peps/pull/394
Regards
Antoine.
On Tue, 5 Sep 2017 18:36:51 +0200
Antoine Pitrou wrote:
> Hello,
>
> It's 2017 and we are still allowing people to compile CPython without
> threads support. It add
This is now in git master after being merged by Victor in
https://github.com/python/cpython/pull/3385.
Regards
Antoine.
On Tue, 5 Sep 2017 18:36:51 +0200
Antoine Pitrou wrote:
> Hello,
>
> It's 2017 and we are still allowing people to compile CPython without
> threads suppo
On Thu, 7 Sep 2017 11:30:12 -0600
Neil Schemenauer wrote:
>
> * The GC process would work nearly the same as it does now. Rather than
> only traversing the linked list, we would also have to crawl over the
> GC object arenas, check blocks of memory that have the tracked bit
> set.
Small n
On Thu, 07 Sep 2017 13:39:21 -0700
Benjamin Peterson wrote:
> Hello,
> I've written a short PEP about an import extension to allow pycs to be
> more deterministic by optional replacing the timestamp with a hash of
> the source file: https://www.python.org/dev/peps/pep-0552/
Why isn't https://gith
On Thu, 07 Sep 2017 14:08:58 -0700
Benjamin Peterson wrote:
> On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote:
> > On Thu, 07 Sep 2017 13:39:21 -0700
> > Benjamin Peterson wrote:
> > > Hello,
> > > I've written a short PEP about an import ex
On Thu, 07 Sep 2017 14:32:19 -0700
Benjamin Peterson wrote:
> >
> > Not sure how common that situation is (certainly the source tree wasn't
> > read-only when you checked it out or untar'ed it), but isn't it easily
> > circumvented by copying the source tree before building?
>
> Well, yes, in
On Thu, 07 Sep 2017 14:40:33 -0700
Benjamin Peterson wrote:
> On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> > Nice one.
> >
> > It would be nice to specify the various APIs needed as well.
>
> The compileall and py_compile ones?
>
> >
> > Why do you keep the mtime-based format as
On Thu, 7 Sep 2017 18:47:20 -0700
Nick Coghlan wrote:
> However, I do wonder whether we could encode *all* the mode settings
> into the magic number, such that we did something like reserving the
> top 3 bits for format flags:
>
> * number & 0x1FFF -> the traditional magic number
> * number & 0x8
On Fri, 8 Sep 2017 12:04:52 +0200
Antoine Pitrou wrote:
> On Thu, 7 Sep 2017 18:47:20 -0700
> Nick Coghlan wrote:
> > However, I do wonder whether we could encode *all* the mode settings
> > into the magic number, such that we did something like reserving the
> > top
Hi,
Is it possible to install pygments on the machine which builds and
renders PEPs? It would allow syntax highlighting in PEPs, making
example code more readable.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
On Fri, 8 Sep 2017 07:49:46 -0700
Nick Coghlan wrote:
> On 8 September 2017 at 03:04, Antoine Pitrou wrote:
> > On Thu, 7 Sep 2017 18:47:20 -0700
> > Nick Coghlan wrote:
> >> However, I do wonder whether we could encode *all* the mode settings
> >> into t
Hello,
I've written a PEP by which you can tell the GC to run in a dedicated
thread. The goal is to solve reentrancy issues with finalizers:
https://www.python.org/dev/peps/pep-0556/
Regards
Antoine.
PS: I did not come up with the idea for this PEP while other people
were having nightmares.
On Fri, 8 Sep 2017 10:03:33 -0700
Nick Coghlan wrote:
> On 8 September 2017 at 08:05, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > I've written a PEP by which you can tell the GC to run in a dedicated
> > thread. The goal is to solve reentr
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. How about simply shutting down the
> finalization thread and not guaranteeing that finalizers are actually
On Fri, 8 Sep 2017 12:40:34 -0700
Nathaniel Smith wrote:
>
> PyPy just abandons everything when shutting down, instead of running
> finalizers. See the last paragraph of :
> http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies
>
> So that mi
On Fri, 8 Sep 2017 16:59:57 +0200
Ivan Levkivskyi wrote:
> I already made a PR that would highlight code in PEPs half-year ago, but it
> was rejected with the reason that they will be moved to RtD soon.
Perhaps we can revive that PR? Browsing through old peps PRs, I can
see that other people we
On Sat, 9 Sep 2017 09:04:59 +0100
Paul Moore wrote:
> On 9 September 2017 at 00:04, Eric Snow wrote:
> >add_recv_fifo(name=None):
> >
> > Create a new FIFO, associate the two ends with the involved
> > interpreters, and return the side associated with the interpreter
> > in
On Fri, 8 Sep 2017 16:04:27 -0700
Eric Snow wrote:
>
> The module provides the following functions:
>
> ``list()``::
>
>Return a list of all existing interpreters.
It's called ``enumerate()`` in the threading module. Not sure there's
a point in choosing a different name here.
> The modul
On Sat, 9 Sep 2017 11:46:30 -0700
Barry Warsaw wrote:
>
> Rationale
> =
>
> It is trivial to implement a no-op function in Python. It's so easy in fact
> that many people do it many times over and over again. It would be useful in
> many cases to have a common built-in function that do
On Tue, 12 Sep 2017 14:43:43 -0700
Eric Snow wrote:
> On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou wrote:
> > On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow
> > wrote:
> >> ``list()``::
> >
> > It's called ``enumerate()`` in the threading module. N
On Mon, 18 Sep 2017 11:31:12 +0200
Victor Stinner wrote:
>
> Ideally, CPython 3.x should never create reference cycles. Removing
> Exception.__traceback__ is the obvious "fix" for the issue. But I
> expect that slowly, a lot of code started to rely on the attribute,
> maybe even for good reasons
Hi,
First my high-level opinion about the PEP: the CSP model can probably
be already implemented using Queues. To me, the interesting promise of
subinterpreters is if they allow to remove the GIL while sharing memory
for big objects (such as Numpy arrays). This means the PEP should
probably foc
On Mon, 18 Sep 2017 20:07:42 +1000
Nick Coghlan wrote:
> On 18 September 2017 at 19:48, Antoine Pitrou wrote:
> > On Mon, 18 Sep 2017 11:31:12 +0200
> > Victor Stinner wrote:
> >>
> >> Ideally, CPython 3.x should never create reference cycles. Removing
&g
On Mon, 18 Sep 2017 20:35:02 +1000
Nick Coghlan wrote:
> On 18 September 2017 at 20:18, Victor Stinner
> wrote:
> > 2017-09-18 12:07 GMT+02:00 Nick Coghlan :
> >> I wonder if it might be reasonable to have tracebacks only hold a weak
> >> reference to their frame objects when "__debug__ == Fal
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 useful, because we could depend on GC. Why
> are we now trying to ro
On Mon, 18 Sep 2017 09:42:45 -0700
Nathaniel Smith wrote:
>
> Obviously it's nice when the refcount system is able to implicitly clean
> things up in a prompt and deterministic way, but there are already tools to
> handle the cases where it doesn't (ResourceWarning, context managers, ...),
> and
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 resources in memory when
>> people don't expect them to. Such as large Numpy arrays :-)
>
> Do we have any reason to believe that this
On Mon, 18 Sep 2017 13:25:47 -0700
Nathaniel Smith wrote:
> >> If it is then it might make sense to look at the cycle collection
> >> heuristics; IIRC they're based on a fairly naive count of how many
> >> allocations have been made, without regard to their size.
> >
> > Yes... But just because
Hi Eric,
On Fri, 22 Sep 2017 19:09:01 -0600
Eric Snow wrote:
>
> Please elaborate. I'm interested in understanding what you mean here.
> Do you have some subinterpreter-based concurrency improvements in
> mind? What aspect of CSP is the PEP following too faithfully?
See below the discussion
On Mon, 25 Sep 2017 17:42:02 -0700
Nathaniel Smith wrote:
> 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
On Mon, 02 Oct 2017 18:56:15 +
Brett Cannon wrote:
>
> So Mercurial specifically is an odd duck because they already do lazy
> importing (in fact they are using the lazy loading support from importlib).
Do they? I was under the impression they had their own home-baked,
GPL-licensed, lazy-lo
On Mon, 2 Oct 2017 11:15:35 -0400
Barry Warsaw wrote:
>
> I think there are opportunities for an explicit API for lazy compilation of
> regular expressions, but I’m skeptical of the adoption curve making it
> worthwhile. But maybe I’m wrong!
We already have two caching schemes available in th
On Mon, 2 Oct 2017 22:15:01 -0400
Eric Snow wrote:
>
> I'm still not convinced that sharing synchronization primitives is
> important enough to be worth including it in the PEP. It can be added
> later, or via an extension module in the meantime. To that end, I'll
> add a mechanism to the PEP f
On Tue, 3 Oct 2017 10:21:55 -0400
Barry Warsaw wrote:
> On Oct 3, 2017, at 01:41, Serhiy Storchaka wrote:
> >
> > 03.10.17 06:29, INADA Naoki пише:
> >> More optimization can be done with implementing sre_parse and sre_compile
> >> in C.
> >> But I have no time for it in this year.
> >
> >
On Tue, 3 Oct 2017 08:36:55 -0600
Eric Snow wrote:
> On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou wrote:
> > On Mon, 2 Oct 2017 22:15:01 -0400
> > Eric Snow wrote:
> >>
> >> I'm still not convinced that sharing synchronization primitives is
> >&g
On Tue, 3 Oct 2017 08:15:04 -0700
Guido van Rossum wrote:
> It's really not that hard. You just check the magic number and if it's the
> new one, skip 4 words. No need to understand the internals of the header.
Still, I agree with Barry that an API would be nice.
Regards
Antoine.
>
> On Oct 3
On Wed, 4 Oct 2017 11:52:32 +0200
Victor Stinner wrote:
>
> It's also hard to find open bugs of a specific module on
> bugs.python.org, since almost all bugs are in the very generic
> "Library" category. Using full text returns "false positives".
>
> I would prefer to see more specific categorie
On Mon, 2 Oct 2017 21:31:30 -0400
Eric Snow wrote:
>
> > By contrast, if we allow an actual bytes object to be shared, then
> > either every INCREF or DECREF on that bytes object becomes a
> > synchronisation point, or else we end up needing some kind of
> > secondary per-interpreter refcount whe
On Wed, 4 Oct 2017 10:14:22 -0400
Barry Warsaw wrote:
> On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
>
> > I'm not sure turning the implementation details of our internal formats
> > into APIs is the way to go.
>
> I still think an API in the stdlib would be useful and appropriate, but
On Wed, 4 Oct 2017 15:22:48 +0200
Victor Stinner wrote:
> 2017-10-04 14:36 GMT+02:00 Antoine Pitrou :
> > If there's a crash in socket.sendmsg() that affects mainly
> > multiprocessing, should it be in "Networking", "Security" or
> > "Parall
On Wed, 4 Oct 2017 09:39:21 -0400
Barry Warsaw wrote:
> On Oct 4, 2017, at 05:52, Victor Stinner wrote:
>
> > My problem is that almost all changes go into "Library" category. When
> > I read long changelogs, it's sometimes hard to identify quickly the
> > context (ex: impacted modules) of a cha
On Wed, 4 Oct 2017 17:50:33 +0200
Antoine Pitrou wrote:
> On Mon, 2 Oct 2017 21:31:30 -0400
> Eric Snow wrote:
> >
> > > By contrast, if we allow an actual bytes object to be shared, then
> > > either every INCREF or DECREF on that bytes object becomes a
> &
On Wed, 4 Oct 2017 14:06:48 -0400
Barry Warsaw wrote:
> Victor brings up a good question in his review of the PEP 553 implementation.
>
> https://github.com/python/cpython/pull/3355
> https://bugs.python.org/issue31353
>
> The question is whether $PYTHONBREAKPOINT should be ignored if -E is give
Hi,
On Mon, 16 Oct 2017 12:42:30 +0200
Victor Stinner wrote:
>
> ``time.time()`` returns seconds elapsed since the UNIX epoch: January
> 1st, 1970. This function loses precision since May 1970 (47 years ago)::
This is a funny sentence. I doubt computers (Unix or not) had
nanosecond clocks in
On Mon, 16 Oct 2017 17:23:15 +0200
Victor Stinner wrote:
> 2017-10-16 17:06 GMT+02:00 Antoine Pitrou :
> >> This PEP adds five new functions to the ``time`` module:
> >>
> >> * ``time.clock_gettime_ns(clock_id)``
> >> * ``time.clock_settime_ns(clock_id, tim
On Mon, 16 Oct 2017 18:06:06 +0200
Victor Stinner wrote:
> 2017-10-16 17:42 GMT+02:00 Antoine Pitrou :
> > Restricting this PEP to the time module would be fine with me.
>
> Maybe I should add a short sentence to keep the question open, but
> exclude it from the direct sco
On Mon, 16 Oct 2017 18:53:18 +0200
Victor Stinner wrote:
> 2017-10-16 18:28 GMT+02:00 Antoine Pitrou :
> >> What do you think?
> >
> > It sounds fine to me!
>
> Ok fine, I updated the PEP. Let's start simple with the few functions
> (5 "clock&qu
On Mon, 16 Oct 2017 19:20:44 +0200
Victor Stinner wrote:
> Oh, now I'm confused. I misunderstood your previous message. I understood
> that you changed you mind and didn't want to add process_time_ns().
>
> Can you elaborate why you consider that time.process_time_ns() is needed,
> but not the na
Hi Victor,
I made some small fixes to the PEP.
As far as I'm concerned, the PEP is ok and should be approved :-)
Regards
Antoine.
On Mon, 16 Oct 2017 12:42:30 +0200
Victor Stinner wrote:
> Hi,
>
> While discussions on this PEP are not over on python-ideas, I proposed
> this PEP directly on
On Tue, 24 Oct 2017 09:00:45 +0200
Victor Stinner wrote:
> By the way, you mentionned that clocks are not synchronized. That's another
> revelant point. Even if system clocks are synchronized on a single
> computer, I read that you cannot reach nanosecond resolution for a NTP
> synchronization eve
Le 24/10/2017 à 13:20, Victor Stinner a écrit :
>> See https://blog.cloudflare.com/how-to-achieve-low-latency/
>
> This article doesn't mention NTP, synchronization or nanoseconds.
NTP is layered over UDP. The article shows base case UDP latencies of
around 15µs over 10Gbps Ethernet.
Regards
On Thu, 26 Oct 2017 11:24:54 +0200
Victor Stinner wrote:
>
> We are using Mailman 3 for the new buildbot-status mailing list and it
> works well:
>
> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
>
> I prefer to read archives with this UI, it's simpler to follow
> thread
Le 26/10/2017 à 12:15, Victor Stinner a écrit :
> 2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
>> Is it possible to have a
>> pipermail-style UI as an alternative?
>
> I don't know pipermail. Do you have an example?
https://mail.python.org/pipermail/python-dev/ :
Le 26/10/2017 à 14:40, Nick Coghlan a écrit :
>
> If folks want to see MM3 in action with some more active lists, I'd
> suggest looking at the Fedora MM3 instance, especially the main dev
> list:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org>
> There's a 100 messag
Le 26/10/2017 à 16:01, Donald Stufft a écrit :
>
>> On Oct 26, 2017, at 6:19 AM, Antoine Pitrou > <mailto:anto...@python.org>> wrote:
>>
>> The pipermail UI isn't perfect (the monthly segregation can be annoying
>> as you point out), but at least it
On Thu, 26 Oct 2017 15:42:19 -0700
Ethan Smith wrote:
> Stub Only Packages
> ''
>
> For package maintainers wishing to ship stub files containing all of their
> type information, it is prefered that the ``*.pyi`` stubs are alongside the
> corresponding ``*.py`` files. However, the
On Fri, 27 Oct 2017 11:31:04 +0200
Antoine Pitrou wrote:
> On Thu, 26 Oct 2017 15:42:19 -0700
> Ethan Smith wrote:
> > Stub Only Packages
> > ''''''''''''''''''
> >
> >
On Wed, 1 Nov 2017 13:46:27 +0100
Christian Heimes wrote:
>
> > This work would target the master branch (that is Python 3). I would
> > be interested in hearing your thoughts on this idea.
>
> In general your proposal sounds like a good idea. A new platform may
> require a PEP, though.
It wo
Sounds good to me :-)
Regards
Antoine.
On Fri, 3 Nov 2017 12:01:28 +0200
Serhiy Storchaka wrote:
> Currently the implementation of re and curses related modules is sparsed
> over several files:
>
> re:
> Lib/re.py
> Lib/sre_compile.py
> Lib/sre_constants.py
> Lib/sre_par
On Fri, 3 Nov 2017 12:46:33 -0400
"Eric V. Smith" wrote:
> On 11/3/2017 12:15 PM, Victor Stinner wrote:
> > Hi,
> >
> > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> >> Maybe we should remove typing from the stdlib?
> >> https://github.com/python/typing/issues/495
>
> > The typing module i
n 3 November 2017 at 17:47, Antoine Pitrou wrote:
>> On Fri, 3 Nov 2017 12:46:33 -0400
>> "Eric V. Smith" wrote:
>>> On 11/3/2017 12:15 PM, Victor Stinner wrote:
>>>> Hi,
>>>>
>>>> 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>>
Le 03/11/2017 à 19:34, Stéfane Fermigier a écrit :
>
> On Fri, Nov 3, 2017 at 6:47 PM, Antoine Pitrou <mailto:solip...@pitrou.net>> wrote:
>
> I don't think other modules should start relying on the typing module at
> runtime.
>
> They already do
On Sun, 5 Nov 2017 21:06:12 +0100
Stefan Krah wrote:
> On Sun, Nov 05, 2017 at 09:35:38PM +0200, Serhiy Storchaka wrote:
> > 05.11.17 21:20, Stefan Krah пише:
> > >On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote:
> > >>Do you suggest to make dictionary displays producing Orde
On Sun, 5 Nov 2017 20:18:07 -0800
Lukasz Langa wrote:
>
> Interestingly enough, at Facebook we found out that using f-strings is
> *faster* at runtime than the lazy form of logging.log("format with %s and
> %d", arg1, arg2), including for cases when the log message is not emitted.
I suspect th
I think that Paul has a point. Interestingly, at the same time we're
talking about guaranteeing the order of dicts, we're talking about
using another, unordered, data structure (hash array mapped tries) to
improve the performance of something that resembles a namespace. It
seems the "unordered"
On Mon, 6 Nov 2017 12:05:07 +1000
Nick Coghlan wrote:
>
> So my proposal is simple (and not really new): let's revert back to
> the way things were in 2.6 and earlier, with DeprecationWarning being
> visible by default, and app devs having to silence it explicitly
> during application startup (be
On Mon, 6 Nov 2017 12:45:27 +0100
Antoine Pitrou wrote:
>
> I'm on the fence on this.
>
> I was part of the minority who opposed the original decision. So I
> really appreciate your sentiment. Since then, I had to deal with a lot
> of very diverse third-party librar
Hello,
Is there a known reason why 3.5.4 doesn't appear in the changelogs at
the bottom of https://docs.python.org/3.7/whatsnew/index.html ?
(all releases until 3.5.3 do)
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
On Tue, 7 Nov 2017 00:14:35 +1100
Steven D'Aprano wrote:
> On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote:
>
> > The ordered-ness of dicts could instead become one of those stable
> > CPython implementation details, such as the fact that resources are
&
On Mon, 6 Nov 2017 23:23:25 +1000
Nick Coghlan wrote:
> On 6 November 2017 at 21:58, Antoine Pitrou wrote:
> > I guess my takeaway point is that many situations are complicated, and
> > many third-party library developers are much less disciplined than what
> > some of us
On Mon, 6 Nov 2017 18:41:30 +0100
Victor Stinner wrote:
>
> Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc.
We support POSIX-compatible platforms. Do OpenBSD and NetBSD need
special care?
Regards
Antoine.
___
Python-Dev mai
On Mon, 6 Nov 2017 22:49:06 +0100
Victor Stinner wrote:
>
> CPython already contais 11 "#ifdef (...) __OpenBSD__" in C and 11
> sys.platform.startswith('openbsd') in Python. Supporting a "POSIX"
> platform requires some changes :-)
Yes... So, the question is: does OpenBSD already maintain a Pyth
On Tue, 7 Nov 2017 09:30:19 +
Paul Moore wrote:
>
> I understand the "but no-one actually does this" argument. And I
> understand that breakage as a result is worse than a few warnings. But
> enabling deprecation warnings by default feels to me like favouring
> the developer over the end user
On Wed, 8 Nov 2017 00:01:04 +1000
Nick Coghlan wrote:
> On 7 November 2017 at 23:48, Stefan Krah wrote:
> >
> >
> > This is just a reminder that the current dict is not an "OrderedDict":
> >
> from collections import OrderedDict
> OrderedDict(a=0, b=1) == OrderedDict(b=1, a=0)
> >
On Wed, 8 Nov 2017 01:56:42 +1100
Steven D'Aprano wrote:
>
> I think that Nick's intent was not to say that after a single deletion,
> the ordering guarantee goes away "forever", but that a deletion may be
> permitted to reorder the keys, after which further additions will honour
> insertion o
On Tue, 7 Nov 2017 09:44:07 -0500
Yury Selivanov wrote:
>
> One common pattern that I see frequently is this:
>
> def foo(**kwargs):
> kwargs.pop('somekey', None)
> bar(**kwargs)
I see it frequently too, but that's in code meant to be
Python 2-compatible (and therefore
On Wed, 8 Nov 2017 06:19:46 +1100
Chris Angelico wrote:
>
> I've used a good few dictionary objects in my time, but most of them
> have literally never had any items deleted from them.
Well... It really depends what kind of problem you're solving. I
certainly delete or pop items from dicts quit
On Wed, 8 Nov 2017 11:35:13 +1000
Nick Coghlan wrote:
> On 8 November 2017 at 10:03, Guido van Rossum wrote:
> > OK, so let's come up with a set of heuristics that does the right thing for
> > those cases specifically. I'd say whenever you're executing code from a
> > zipfile or some such it's n
On Wed, 8 Nov 2017 13:07:12 +1000
Nick Coghlan wrote:
> On 8 November 2017 at 07:19, Evpok Padding wrote:
> > On 7 November 2017 at 21:47, Chris Barker wrote:
> >> if dict order is preserved in cPython , people WILL count on it!
> >
> > I won't, and if people do and their code break, they'll
Le 08/11/2017 à 22:43, Nick Coghlan a écrit :
>
> However, between them, the following two guidelines should provide
> pretty good deprecation warning coverage for the world's Python code:
>
> 1. If it's in __main__, it will emit deprecation warnings at runtime
> 2. If it's not in __main__, it s
201 - 300 of 4909 matches
Mail list logo
