On Wed, Jul 16, 2014 at 7:47 AM, R. David Murray wrote:
> After I hit send on my previous message, I thought more about your
> example. One of the issues here is that modifying the dict breaks an
> invariant of the API. I have a similar situation in the email module,
> and I used the same soluti
On Sun, Nov 30, 2014 at 6:25 PM, Donald Stufft wrote:
>The technical benefits mostly come from Github generally being a higher
> quality product than it’s competitors, both FOSS and not.
Here's a solution to allow contribution via PR while not requiring
anything to switch VCS or hosting:
1. Set
On Sun, Nov 30, 2014 at 6:40 PM, Donald Stufft wrote:
> I’m not sure if it got lost in the discussion or if it was purposely left
> out. However I did come up with another idea, where we enable people to make
> PRs against these repositories with PR integration within roundup. Using the
> fact tha
On Sun, Nov 30, 2014 at 6:44 PM, Donald Stufft wrote:
> Yea this is essentially what I meant. We already have “unofficial” mirrors
> for PEPs and CPython itself on Github that are updated a few times a day.
> It wouldn’t be very difficult I think to make them official mirrors and
> update them imm
On Tue, Dec 2, 2014 at 6:24 AM, Nick Coghlan wrote:
> P.S. I'll also bring up some of the RFEs raised in this discussion
> around making it possible for folks to submit pull requests via
> GitHub/BitBucket, even if the master repositories are hosted on PSF
> infrastructure.
In case it helps with
On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon wrote:
> So I was waiting for Nick to say what he wanted to do for the peps repo
> since I view it as I get 2/3 of the choices and he gets the other third.
>
> The way I view it, the options are:
>
> Move to GitHub
> Move to Bitbucket
> Improve our curr
ally that code and time has not
> materialized. Our code review tool is a fork that probably should be
> replaced as only Martin von Löwis can maintain it. Basically Ezio Melotti
> maintains the issue tracker's code.
Doing something about those two tools is something to consider. Wou
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec wrote:
>
>
> Attached patch defines a new type struct_timespec for the time module. A new
> capsule exports the type along with to/from converters - opening a bridge
> for C, and for example the datetime module.
I'd recommend opening a new issue in th
On Sat, Jan 24, 2015 at 3:50 AM, Maciej Fijalkowski wrote:
> I would like to point out that we implemented rhettingers idea in PyPy
> that makes all the dicts ordered by default and we don't have any
> adverse performance effects (in fact, there is quite significant
> memory saving coming from it)
On Mon, Feb 2, 2015 at 12:36 PM, Cyd Haselton wrote:
> After fixing a segfault issue (many thanks Ryan) I'm back to the same issue
> I was having with Python 2.7.8; the newly built python throws an undefined
> reference to dlopen when running setup.py...specifically when importing
> just-built ext
On Fri, Feb 13, 2015 at 3:49 PM, Zachary Ware
wrote:
> On Fri, Feb 13, 2015 at 4:09 PM, Paul Moore wrote:
>> I'm working on a patch for the Python launcher. I built Python
>> (current tip, on MS Windows, with VS 2015), and I've just noticed that
>> hg status shows:
>>
hg status -mard
>> M Doc
On Fri, Mar 6, 2015 at 9:34 AM, Brett Cannon wrote:
> Not specifying the optimization level when it is at 0
> -
>
> It has been suggested that for the common case of when the
> optimizations are at level 0 that the entire part of the file name
>
On Mar 21, 2015 7:44 AM, "Brett Cannon" wrote:
>
> Thanks! PEP 488 is now marked as accepted. I expect I will have PEP 488
implemented before the PyCon sprints are over (work will be tracked in
http://bugs.python.org/issue23731).
>
> On Fri, Mar 20, 2015 at 8:06 PM Guido van Rossum wrote:
>>
>> A
On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann
wrote:
>> When I first wrote PEP 422 I was of the view that "Python 2 allows
>> class definition postprocessing injection, we should allow it in
>> Python 3 as well". I've since changed my view to "Having to declare
>> post-processing of a class def
On Sat, Apr 4, 2015 at 6:40 PM, Greg Ewing wrote:
> Eric Snow wrote:
>>
>> I've felt for a long time that it would be helpful in some situations
>> to have a reverse descriptor protocol.
>
> Can you elaborate on what you mean by that?
Sure. It's more python
On Fri, Apr 3, 2015 at 6:44 AM, Martin Teichmann
wrote:
> Nick, I couldn't agree more with you, yet I think PJ actually brought
> up a very interesting point. Post-processing is a very common thing
> these days, and has been re-written so many times that I think it is
> about time that something l
_PyObject_LookupSpecial is used in place of obj.__getattribute__ for
looking up special methods. (As far as I recall it is not exposed in
the stdlib, e.g. inspect.getattr_special.) Correct me if I'm wrong
(please!), but there are two key reasons:
* access to special methods in spite of obj.__ge
On Mon, Apr 20, 2015 at 2:20 AM, Guido van Rossum wrote:
> (I suppose this new thread is a result of some research you did regarding
> the thread complaining about callable()?)
Yep. :)
> On Sun, Apr 19, 2015 at 4:03 PM, Eric Snow
> wrote:
>>
>> _PyObject_LookupSpecial
On Mon, Apr 20, 2015 at 4:37 AM, Guido van Rossum wrote:
> OK, so I think there isn't anything we can or should do here. Yes, it's
> possible that type(x).__add__ succeeds but x.__add__ fails. That's how you
> spell descriptor. :-) You could also use a random number generator in
> __getattribube__
On Mon, Apr 20, 2015 at 1:35 PM, Łukasz Langa wrote:
> Yeah, so agreed, this is pretty busy. For such cases, reformatting makes
> it less confusing (see: Screenshot 1).
>
>
>
While it helps, this sort of best-practice is still unsettled (and
apparently not obvious). In the short term it would ma
*
PEP: 554
Title: Multiple Interpreters in the Stdlib
Author: Eric Snow
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-05
Python-Version: 3.7
Post-History:
Abstract
This proposal introduces the stdlib ``interpreters`` module. It exposes
the basic f
On Fri, Sep 8, 2017 at 4:28 PM, Stefan Krah wrote:
> The most promising model to me is to put *all* globals in a tls structure
> and cache the whole structure. Extrapolating from my experiences with the
> context, this might have a slowdown of "only" 4%.
Yeah, this is actually something I've bee
On Sat, Sep 9, 2017 at 1:04 AM, Paul Moore wrote:
> On 9 September 2017 at 00:04, Eric Snow wrote:
>>add_recv_fifo(name=None):
>>add_send_fifo(name=None):
>
> Personally, I *always* read these names backwards - from the POV of
> the caller. So when I see "add
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 fast as multiprocessing and a
On Sat, Sep 9, 2017 at 4:45 AM, Antoine Pitrou wrote:
> How does the other interpreter get the FIFO "tied" to it?
> Is it `get_current().get_fifo(name)`? Something else?
Yep, that's it. I've added some examples to the PEP to illustrate.
That said, I'm re-working the method names since they conf
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. Not sure there's
> a point in choosing a different name here.
Yeah, in the
On Sat, Sep 9, 2017 at 11:04 AM, Nathaniel Smith wrote:
> This phrase "bubble up" here is doing a lot of work :-). Can you elaborate
> on what you mean? The text now makes it seem like the exception will just
> pass from one interpreter into another, but that seems impossible
I've updated the PEP
has moved down below the examples
Please let me know what you think. I'm especially interested in
feedback about the channels. Thanks!
-eric
PEP: 554
Title: Multiple Interpreters in the Stdlib
Author: Eric Snow
Status: Draft
Type: Standa
Thanks for the feedback, Antoine. Sorry for the delay; it's been a
busy week for me. I just pushed an updated PEP to the repo. Once
I've sorted out the question of passing bytes through channels I plan
on posting the PEP to the list again for another round of discussion.
In the meantime, I've re
On Thu, Sep 14, 2017 at 8:44 PM, Nick Coghlan wrote:
> Not really, because the only way to ensure object separation (i.e no
> refcounted objects accessible from multiple interpreters at once) with
> a bytes-based API would be to either:
>
> 1. Always copy (eliminating most of the low overhead comm
After having looked it over, I'm leaning toward supporting buffering,
as well as not blocking by default. Neither adds much complexity to
the implementation.
On Sat, Sep 23, 2017 at 5:45 AM, Antoine Pitrou wrote:
> On Fri, 22 Sep 2017 19:09:01 -0600
> Eric Snow wrote:
>>
On Mon, Oct 2, 2017 at 9:31 PM, Eric Snow wrote:
> On DECREF there shouldn't be a problem except possibly with a small
> race between decrementing the refcount and checking for a refcount of
> 0. We could address that several different ways, including allowing
> the pending c
On Mon, Sep 25, 2017 at 8:42 PM, Nathaniel Smith wrote:
> It's fairly reasonable to implement a mutex using a CSP-style
> unbuffered channel (send = acquire, receive = release). And the same
> trick turns a channel with a fixed-size buffer into a bounded
> semaphore. It won't be as efficient as a
On Wed, Sep 27, 2017 at 1:26 AM, Nick Coghlan wrote:
> It's also the case that unlike Go channels, which were designed from
> scratch on the basis of implementing pure CSP,
FWIW, Go's channels (and goroutines) don't implement pure CSP. They
provide a variant that the Go authors felt was more in-
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
>> important enough to be worth including it in the PEP. It can be added
>> l
On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote:
> The problem relates to the fact that there aren't any memory barriers
> around CPython's INCREF operations (they're implemented as an ordinary
> C post-increment operation), so you can get the following scenario:
>
> * thread on CPU A has the
On Tue, Oct 3, 2017 at 8:55 AM, Antoine Pitrou wrote:
> I think we need a sharing protocol, not just a flag. We also need to
> think carefully about that protocol, so that it does not imply
> unnecessary memory copies. Therefore I think the protocol should be
> something like the buffer protocol
On Thu, Oct 5, 2017 at 4:57 AM, Nick Coghlan wrote:
> This would be hard to get to work reliably, because "orig.tp_share()" would
> be running in the receiving interpreter, but all the attributes of "orig"
> would have been allocated by the sending interpreter. It gets more reliable
> if it's *Cha
On Nov 7, 2017 08:12, "INADA Naoki" wrote:
Additionally, class namespace should keep insertion order. It's language
spec from 3.6. So we should have two mode for such optimization.
It makes dict more complicated.
FWIW, PEP 520 (Preserving Class Attribute Definition Order) originally
specified
On Nov 18, 2017 19:20, "Nick Coghlan" wrote:
OK, in that case I think the answer to Victor's question is:
1. Breaking calling Py_DecodeLocale() before calling Py_Initialize()
is a compatibility break with the API implied by our own usage
examples, and we'll need to revert the breakage for 3.7,
On Mon, Nov 20, 2017 at 8:43 AM, Victor Stinner
wrote:
> 2017-11-20 16:31 GMT+01:00 Eric Snow :
>> That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an
>> implementation detail.
>
> Py_DecodeLocale() uses PyMem_RawMalloc(), and so its result must be
> freed
On Mon, Nov 20, 2017 at 3:03 PM, Victor Stinner
wrote:
> To statically initialize PyMemAllocatorEx fields, you need to export a
> lot of allocator functions. I would prefer to not do that.
>
> [snip]
>
> The rules to choose the allocator to each domain are also complex
> depending if pymalloc is e
On Mon, Nov 27, 2017 at 10:05 AM, Larry Hastings wrote:
> I'd like inspect.signature to guarantee that the order of keyword-only
> parameters always matches the order they were declared in. Technically this
> isn't a language feature, it's a library feature. But making this guarantee
> would req
channels" an explicit
keyword argument).
-eric
I've include the latest full text
(https://www.python.org/dev/peps/pep-0554/) below:
+++++
PEP: 554
Title: Multiple Interpreters in the Stdlib
Author: Eric Snow
Status: Draft
Type: Standards Track
Content
On Dec 5, 2017 23:49, "Nick Coghlan" wrote:
Nice updates! I like this version.
Great! :)
My one suggestion here would be to consider a dedicated exception type
like "interpreters.SubinterpreterError", rather than re-using
RuntimeError directly. That way you can put the extracted traceback on
a
On Dec 6, 2017 20:31, "Guido van Rossum" wrote:
If the point is just to be able to test the existing API better, no PEP is
needed, right? It would be an unsupported, undocumented API.
In the short term that's one major goal. In the long term the
functionality provided by the PEP is a prerequis
On Dec 6, 2017 21:14, "Guido van Rossum" wrote:
OK, then please just change the PEP's Version: header to 3.8.
Will do. Have a nice vacation! :)
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
Overall, I like this PEP. It's definitely easier to follow
conceptually than PEP 550. Thanks for taking the time to re-think the
idea. I have a few comments in-line below.
-eric
On Tue, Dec 12, 2017 at 10:33 AM, Yury Selivanov
wrote:
> This is a new proposal to implement context storage in Py
On Tue, Dec 12, 2017 at 4:49 PM, Victor Stinner
wrote:
>> The ``Token`` API exists to make the current proposal forward
>> compatible with :pep:`550`, in case there is demand to support
>> context variables in generators and asynchronous generators in the
>> future.
>
> Cool. I like the idea of st
On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum wrote:
> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
Does that include preserving order after deletion?
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
On Fri, Dec 15, 2017 at 11:35 AM, Serhiy Storchaka wrote:
> In this case I suggest to make __class_getitem__ an automatic class method
> like __init_subclass__.
+1 I was just about to suggest the same thing.
-eric
___
Python-Dev mailing list
Python-De
On Thu, Dec 21, 2017 at 4:21 PM, Gregory P. Smith wrote:
> It seems a suggested use is "from dataclasses import dataclass"
>
> But people are already familiar with "from collections import namedtuple"
> which suggests to me that "from collections import dataclass" would be a
> more natural soundin
On Sat, Jan 27, 2018 at 2:02 PM, Barry Warsaw wrote:
> please welcome your next release manager…
>
> Łukasz Langa!
Congrats, Łukasz! (or condolences? )
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
On Thu, Feb 22, 2018 at 9:30 AM, Paul Moore wrote:
> My experience on pip is that automated style review is helpful for
> avoiding debates over subjective details.
This is the allure of Go's official linting tools. Nobody is happy
with *all* the style choices but there isn't any room to fuss abo
On Tue, Apr 17, 2018 at 7:55 AM, Steve Dower wrote:
> Agree with Paul. The PEP is well thought out and well presented, but I
> really don’t think we need this in Python (and I say this as someone who
> uses it regularly in C/C#).
>
> -1 on the idea; no disrespect intended toward to people who did
Thanks for thinking this through, Yury. :)
FWIW, I'm still unconvinced that an assignment expression is worth it.
It's hard to say, though, without seeing how much folks would actually
use it (and I don't have my own time machine unfortunately). IIRC, in
the past several proposed syntax (e.g. dec
In pondering our approach to future Python major releases, I found
myself considering the experience we've had with Python 3. The whole
Py3k effort predates my involvement in the community so I missed a
bunch of context about the motivations, decisions, and challenges.
While I've pieced some of th
On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow wrote:
> In pondering our approach to future Python major releases, I found
> myself considering the experience we've had with Python 3. The whole
> Py3k effort predates my involvement in the community so I missed a
> bunch of
On Thu, Apr 26, 2018 at 12:52 AM, Greg Ewing
wrote:
> [snip]
> here we would be *creating* one (two different assignment
> operators with overlapping use cases) that we won't be
> able to get rid of without a Python 4000 (that Guido has
> promised won't happen).
The edict about "Python 4000" is m
On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow wrote:
> In pondering our approach to future Python major releases, I found
> myself considering the experience we've had with Python 3. The whole
> Py3k effort predates my involvement in the community so I missed a
> bunch of
On Fri, Apr 27, 2018 at 7:23 PM, Nick Coghlan wrote:
> The key missing piece for doing that would be to define how we'd want a `py`
> launcher to work on *nix systems, and then provide that as part of CPython
> 3.8+ (and potentially backport it to a 3.7x maintenance release).
I was thinking along
FWIW, this thread is about what "Python 4000" means and does not mean.
Namely, Python feature deprecation and removal is not prohibited but
the bar is high (as always), especially for syntax. While I
appreciate the level of interest in certain under-consideration
proposals, you'd be better served
On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan wrote:
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea.
Note that the PEP specifically applies to "syntax, semantics, and
built-ins". Here's the full abstract [1]:
This P
On Wed, May 30, 2018 at 7:36 AM, Nick Coghlan wrote:
> There are a few key details here:
>
> 1. We currently need to run post-merge CI anyway, as we're not doing
> linearised commits (where core devs just approve a change without merging
> it, and then a gating system like Zuul ensures that the te
I've pointed out in bpo-21142 the similar script I added last year to
track C globals:
https://github.com/python/cpython/tree/master/Tools/c-globals
-eric
On Mon, Jun 4, 2018 at 1:17 AM, Ronald Oussoren wrote:
>
>
> On 4 Jun 2018, at 08:35, Ronald Oussoren wrote:
>
>
>
> On 3 Jun 2018, at 17
Thanks for doing this Jake.
-eric
On Wed, Jun 6, 2018 at 3:56 PM, Jake Edge wrote:
>
> Hola python-dev,
>
> I have been remiss in posting about my coverage from this year's Python
> Language Summit -- not to mention remiss in getting it all written up.
> But I am about half-way done with the ses
(see http://bugs.python.org/issue16991)
I an working on resolving an intermittent segfault that my C
OrderedDict patch introduces. The failure happens in
test_configparser (RawConfigParser uses OrderedDict internally), but
only sporadically. However, Ned pointed out to me that it appears to
be r
Good catch. Unfortunately, sticking "keys = ((PyDictObject
*)od)->ma_keys;" right after "hash = ..." did not make a difference.
I still get the same segfault.
-eric
On Thu, May 21, 2015 at 11:17 AM, MRAB wrote:
> On 2015-05-21 15:55, Eric Snow wrote:
>>
On Thu, May 21, 2015 at 4:06 PM, MRAB wrote:
> On 2015-05-21 22:52, Eric Snow wrote:
>> Good catch. Unfortunately, sticking "keys = ((PyDictObject
>> *)od)->ma_keys;" right after "hash = ..." did not make a difference.
>> I still get the same segf
On Thu, May 21, 2015 at 4:41 PM, MRAB wrote:
> On 2015-05-21 23:17, Eric Snow wrote:
>> The segfault is consistent if I use the same seed (e.g. 7):
>>
>> PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic
>> test_configparser
>>
>> Some seeds always
On Thu, May 21, 2015 at 5:55 PM, MRAB wrote:
> I'm not looking at the use of "PyTuple_Pack". As I understand it,
> "PyTuple_Pack" borrows the
> references of the objects passed, and when the tuple itself is DECREFed,
> those objects will be
> DECREFed
>From the docs [1] it seems that PyTuple_Pack
On Thu, May 21, 2015 at 6:22 PM, MRAB wrote:
> Oh, well, I'll keep looking...
Thanks!
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyth
On Thu, May 21, 2015 at 6:22 PM, MRAB wrote:
> Oh, well, I'll keep looking...
I've posted some data to http://bugs.python.org/issue16991 that I hope
will shed some light on the issue. We can continue the conversation
there.
-eric
___
Python-Dev mailin
Hi all,
After extended discussion over the last several months on import-sig,
the resulting proposal for multi-phase (PEP 451) extension module
initialization has finalized. The resulting PEP provides a clean,
straight-forward, and backward-compatible way to import extension
modules using ModuleS
.snow wrote:
>>
>> https://hg.python.org/peps/rev/1fbc23a1078c
>> changeset: 5874:1fbc23a1078c
>> user:Eric Snow
>> date:Fri May 22 15:45:38 2015 -0600
>> summary:
>> PEP 489: The PEP is accepted.
>>
>> files:
>> pep-0489.
tl;dr Are there any objections to making making the default
cls.__prepare__ return OrderedDict instead of dict (and preserve that
order in a list on the class)?
A couple years ago [1][2] I proposed making class definition
namespaces use OrderedDict by default. Said Guido [3]:
I'm fine with d
code that
does that. :-)
I was planning on setting it to None if the order is not available. At the
moment that's just a check for OrderedDict.
-eric
>
> On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan wrote:
>>
>> On 24 May 2015 at 12:04, Nick Coghlan wrote:
>> > O
On May 24, 2015 3:35 AM, "Nick Coghlan" wrote:
> Is it specifically necessary to save the order by default? Metaclasses
> would be able to access the ordered namespace in their __new__ method
> regardless, and for 3.6, I still like the __init_subclass__ hook idea
> proposed in PEP 487, which inclu
On May 24, 2015 4:52 PM, "Nick Coghlan" wrote:
>
>
> On 25 May 2015 07:26, "Guido van Rossum" wrote:
> >
> > On Sun, May 24, 2015 at 1:36 PM, Eric Snow
wrote:
> >> If you still think that's not enough justification then we can table
__defin
On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou wrote:
> On Sat, 23 May 2015 20:14:56 -0700
> Larry Hastings wrote:
>> Yeah, I'm willing to grant the feature freeze exception, assuming he can
>> find general approval from the community (and assuming he still has
>> Guido's blessing). I just want
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy wrote:
> On 5/25/2015 3:40 PM, Eric Snow wrote:
>> Since Larry already gave an exception,
>
> Conditional on 'general approval of the community'.
Unless I misunderstood him, Larry gave me an unconditional exception
for Order
On Mon, May 25, 2015 at 6:30 PM, Larry Hastings wrote:
> Eric asked for one for this C reimplementation of OrderedDict; the coding
> was done, the debugging wasn't.
>
> And yes, as Eric said, I made separate pronouncements. I said COrderedDict
> could go in as long as it was in before beta 2; "th
On Thu, May 28, 2015 at 5:01 PM, Paul Sokolovsky wrote:
> That said, making a demo of self-contained webapp server in 350-400K is
> definitely on my TODO list (package support for frozen modules is the
> only blocker for that).
It may be worth taking this over to import-...@python.org for more di
On Aug 22, 2015 9:02 AM, "Patrascu, Alecsandru" <
alecsandru.patra...@intel.com> wrote:
[snip]
> For instance, as shown from attached sample performance results from the
Grand Unified Python Benchmark, >20% speed up was observed.
Are you referring to the tests in the benchmarks repo? [1]
How does
On Aug 24, 2015 3:51 PM, "Stewart, David C"
wrote:
>
> (Sorry about the format here - I honestly just subscribed to Python-dev so
> be gentle ...)
:)
>
> > Date: Sat, 22 Aug 2015 11:25:59 -0600
> > From: Eric Snow
>
> >On Aug 22, 2015 9:02 AM
In a recent tracker issue about OrderedDict [1] we've had some
discussion about the use of type(od) as a replacement for
od.__class__. It came up because the pure Python implementation of
OrderedDict uses self.__class__ in 3 different methods (__repr__,
__reduce__, and copy). The patch in that is
A recent discussion in a tracker issue [1] brought up the matter of
compatibility between the pure Python implementation of OrderedDict
and the new C implementation. In working on that port I stuck as
closely as possible to the Python implementation. This meant some
parts of the code are bit more
On Mon, Oct 19, 2015 at 3:00 PM, Guido van Rossum wrote:
> Apart from Serhiy's detraction of the 3.5 bug report there wasn't any
> discussion in this thread. I also don't really see any specific questions,
> so maybe you don't have any. Are you just asking whether it's okay to merge
> your code? O
On Tue, Oct 20, 2015 at 2:38 AM, Maciej Fijalkowski wrote:
> For what is worth, that level of differences already exists on pypy
> and it's really hard to get the *exact* same semantics if things are
> implemented in python vs C or the other way around.
>
> Example list of differences (which I thi
On Tue, Oct 20, 2015 at 9:10 AM, Guido van Rossum wrote:
> Please go ahead and update PEP 399.
Will do.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
On Wed, Oct 21, 2015 at 9:32 AM, Raymond Hettinger
wrote:
> I'm re-opening
> https://mail.python.org/pipermail/python-dev/2015-October/141993.html
Presumably you meant http://bugs.python.org/issue24379. :)
-eric
___
Python-Dev mailing list
Python-Dev@
On Wed, Oct 28, 2015 at 6:35 AM, Eric V. Smith wrote:
> In issue 25483 I'm adding an opcode to make f-string formatting more
> robust and faster. As part of that, I'm bumping the .pyc magic number.
>
> While doing that, I notice Lib/importlib/_bootstrap_external.h includes
> this comment:
>
> # St
On Wed, Oct 28, 2015 at 8:28 AM, Eric V. Smith wrote:
> Thanks. That part I've done (but forgot to mention). I was just
> concerned about the "magic tag" part, which Barry cleared up.
Ah, I misread. :) Yeah, that comment is out of date.
-eric
___
Pyth
On Tue, Feb 2, 2016 at 10:15 PM, Steve Dower wrote:
> I was throwing around some ideas with colleagues about how we detect Python
> installations on Windows from within Visual Studio, and it came up that
> there are many Python distros that install into different locations but
> write the same reg
On Wed, Mar 2, 2016 at 8:02 AM, Barry Warsaw wrote:
> As BDFL-Delegate, I am officially accepting PEP 493.
>
> Congratulations Nick, Robert, and MAL. I want to personally thank Nick for
> taking my concerns into consideration, and re-working the PEP to resolve
> them. Thanks also to everyone who
On Apr 6, 2016 14:00, "Barry Warsaw" wrote:
> Aside from the name of the attribute (though I'm partial to __path__),
Ahem, pkg.__path__.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On Apr 7, 2016 1:22 AM, "Georg Brandl" wrote:
>
> On 04/06/2016 07:26 PM, Brett Cannon wrote:
> > 1. Name: __path__, __fspath__, or something else?
>
> __path__ is already taken as a module attribute, so I would avoid it.
> __fspath__ is fine with me, although the more explicit variants are also
On Apr 6, 2016 11:11 PM, "Raymond Hettinger"
wrote:
> Having worked through the API when it is first released, I find it to be
highly forgettable (i.e. I have to re-read the docs each time I've
revisited it).
Agreed, though it's arguably better than argparse, logging, unittest, or
several other s
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
> I personally still like __ospath__ as well.
Same here. The strings are essentially an OS-dependent serialization,
rather than related to a particular file system.
-eric
___
Python-Dev mailing list
On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow wrote:
> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file s
1 - 100 of 572 matches
Mail list logo
