On Fri, Nov 2, 2018 at 1:02 PM Victor Stinner wrote:
>
> Le ven. 2 nov. 2018 à 18:32, Neil Schemenauer a
> écrit :
> > A simple approach would be to introduce something like
> > Python-internal.h. If you are a Python internal unit, you can
> > include both Python.h and Python-internal.h. We co
On Tue, Nov 6, 2018 at 8:09 AM Victor Stinner wrote:
> I don't understand the difference between Py_BUILD_CORE and
> Py_BUILD_CORE_BUILTIN defines. Do we need to have two different
> defines? Can't we compile _json with Py_BUILD_CORE?
>
> [snip]
>
> Is it a problem of the visibility/scope of symbo
Hi Stephan,
On Tue, Jan 22, 2019 at 9:25 AM Stephan Reiter wrote:
> I am new to the list and arriving with a concrete problem that I'd
> like to fix myself.
That is great! Statements like that are a good way to get folks
interested in your success. :)
> I am embedding Python (3.6) into my C++
The main problem here seems to be a shortage of communication. :/
Also, I agree on the exceptional nature of merging incomplete PRs.
-eric
On Mon, Feb 4, 2019 at 3:37 AM Łukasz Langa wrote:
>
>
> > On 4 Feb 2019, at 01:49, Guido van Rossum wrote:
> >
> > I think this is now up to the 3.8 releas
On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev <
python-dev@python.org wrote:
>
> I usually use shutil.rmtree for tests that need to create temporary files,
> and create a temporary directory for those files (that is, use
> tempfile.mkdtemp in setUp() and use shutil.rmtree in tearDown(
Hi all,
I've been working on the runtime lately, particularly focused on my
multi-core Python project. One thing that would help simplify changes
in this area is if PyInterpreterState were defined in
Include/internal. This would mean the type would be opaque unless
Py_BUILD_CORE were defined.
T
On Sat, Feb 16, 2019 at 3:34 PM Steve Dower wrote:
> On 16Feb.2019 1332, Antoine Pitrou wrote:
> > This sounds like a reasonable design principle: decree the API
> > non-stable and prone to breakage (it already is, anyway), don't hide it.
>
> As I was chatting with Eric shortly before he posted th
On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou wrote:
> On Sat, 16 Feb 2019 14:34:46 -0800
> Steve Dower wrote:
> > Which seems to suggest that the answer to "which members are important
> > to expose?" is "probably none".
>
> That sounds intuitive. But we don't know what kind of hacks some
> ext
On Sat, Feb 16, 2019 at 3:16 AM Jeroen Demeyer wrote:
> On 2019-02-16 00:37, Eric Snow wrote:
> > One thing that would help simplify changes
> > in this area is if PyInterpreterState were defined in
> > Include/internal.
>
> How would that help anything?
I'm t
I'll take a look tonight.
-eric
On Sun, Feb 24, 2019, 21:54 Raymond Hettinger
wrote:
> I'll been running benchmarks that have been stable for a while. But
> between today and yesterday, there has been an almost across the board
> performance regression.
>
> It's possible that this is a measure
On Sun, Feb 24, 2019 at 10:04 PM Eric Snow wrote:
> I'll take a look tonight.
I made 2 successive runs of the script (on my laptop) for a commit
from early Saturday, and 2 runs from a commit this afternoon (close to
master). The output is below, with the earlier commit first. That
On Mon, Feb 25, 2019 at 10:32 AM Raymond Hettinger
wrote:
> I got it down to two checkins before running out of time:
>
> Between
> git checkout 463572c8beb59fd9d6850440af48a5c5f4c0c0c9
>
> And:
> git checkout 3b0abb019662e42070f1d6f7e74440afb1808f03
>
> So the subinterpreter patch was lik
On Mon, Feb 25, 2019 at 10:42 AM Eric Snow wrote:
> I'll look into it around then too. See https://bugs.python.org/issue33608.
I ran the "performance" suite (https://github.com/python/performance),
which has 57 different benchmarks. In the results, 9 were marked as
"s
Thanks to each of you for the update and the hard work!
-eric
On Fri, Apr 26, 2019 at 8:52 AM Guido van Rossum wrote:
>
> I've posted an update from the Steering Council to our repo:
>
> https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md
>
> I wi
On Sun, Mar 31, 2019 at 9:19 AM Aratz Manterola Lasa via Python-Dev
wrote:
> I was wondering if there was any Python project aiming to implement the actor
> model for python concurrency.
As far as the standard library goes, the explicitly supported
concurrency models are: threading, multiprocess
On Wed, May 1, 2019, 15:49 Nick Coghlan wrote:
> As BDFL-Delegate I'm happy with this version of the PEP, so it's my
> pleasure to accept it for inclusion in Python 3.8.
>
Congratulations, Antoine! This is a big deal and a lot of folks won't
realize it at first. :)
-eric
>
___
I just wanted to share links to my talk about the above, which I gave a
week ago at PyCon. Enjoy! :)
-eric
video: https://youtu.be/7RlqbHCCVyc
slides: https://bit.ly/2UMMJey
project: https://github.com/ericsnowcurrently/multi-core-python
___
Python-
[originally I sent this to typing-sig but I guess it got caught up in
moderation.]
In PEP 554 [1] it says:
- Implement metaclass functionality to detect whether a class is a
protocol or not. Add a class attribute _is_protocol = True if that is
the case. Verify that a protocol class only
On Tue, May 21, 2019, 12:00 Guido van Rossum wrote:
> My guess, without delving into the implementation, is that a Protocol is
> *always* about the class, and that this is entirely a red herring.
>
I think you're right. It makes sense. I must have missed it somehow.
FYI, some protocols (like
On Thu, Jan 28, 2021 at 9:28 AM Mark Shannon wrote:
> Is there a good reason not to start using C11 now?
Would C17 be a better choice? It sounds like it exists to fix
problems with C11 (and doesn't actually add any new features).
-eric
___
Python-Dev
On Fri, Aug 13, 2021 at 11:29 AM Guido van Rossum wrote:
> If these weren't part of the stable ABI, I'd choose (E).
They aren't in the stable ABI (or limited API). Instead, they are
part of the broader public API (declared in Include/cpython/code.h,
along with "struct PyCodeObject" and others).
On Mon, Aug 23, 2021 at 4:16 PM Ammar Askar wrote:
> As part of PEP 588, migrating bugs.python.org issues to Github,
Thanks for working on this!
> 1. Weekly summary emails with bug counts and issues from the week,
> 2. Emails sent to the new-bugs-announce and python-bugs-list for new
I rely on
On Thu, Sep 2, 2021 at 10:46 PM Gregory Szorc wrote:
> Over in https://bugs.python.org/issue45020 there is some exciting work around
> expanding the use of the frozen importer to speed up Python interpreter
> startup. I wholeheartedly support the effort and don't want to discourage
> progress i
On Fri, Sep 3, 2021 at 5:32 AM Paul Moore wrote:
> On Fri, 3 Sept 2021 at 10:29, Simon Cross
> wrote:
> > I think adding a meta path importer that reads from a standard
> > optimized format could be a great addition.
>
> I think the biggest open question would be "what benefits does this
> have
We've frozen most of the stdlib modules imported during "python -c
pass" [1][2], to make startup a bit faster. Import of those modules
is controlled by "-X frozen_modules=[on|off]". Currently it defaults
to "off" but we'd like to default to "on". The blocker is the impact
on contributors. I exp
On Mon, Sep 27, 2021 at 11:09 AM Chris Angelico wrote:
> When exactly does the freezing happen?
When you build the executable (e.g. "make -j8",
".\PCbuild\build.bat"). So your changes to those .py files wouldn't
show up until then.
-eric
___
Python-De
On Mon, Sep 27, 2021 at 10:51 AM Eric Snow wrote:
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on
On Mon, Sep 27, 2021 at 12:40 PM Steve Dower wrote:
> Having it be implied by an "--enable-optimizations" option is totally
> fine (and we'd add one to build.bat for this), but I still think it
> needs to be discoverable later whether the frozen modules build option
> was used or not, independent
On Mon, Sep 27, 2021 at 2:59 PM Brett Cannon wrote:
> What about opting out when `--with-pydebug` is used? I'm not sure how many
> people actively develop in a non-debug build other than testing something,
> but at that point I would be having to run `make` probably anyway for
> whatever I'm mu
On Mon, Sep 27, 2021 at 3:04 PM Barry Warsaw wrote:
> If you’re planning a runtime -X option, then does that mean that the modules
> will be frozen at build time but Python will decide at runtime whether to use
> the frozen modules or the unfrozen ones?
Correct. FYI, this was already done.
>
On Mon, Sep 27, 2021 at 3:31 PM Victor Stinner wrote:
> Which stdlib modules are currently frozen? If I really want to hack
> site.py or os.py for whatever reason, I just have to use "python3 -X
> frozen_modules=off"?
The single-source-of-truth is Tools/scripts/freeze_modules.py. After
running "
On Tue, Sep 28, 2021 at 2:54 AM Ronald Oussoren via Python-Dev
wrote:
> I agree, but… Most CPython tests are run while running from the source tree,
> that means that there will have to be testrunner configurations that run with
> “-X frozen_modules=on”.
If the build option that determines the
On Tue, Sep 28, 2021 at 6:02 AM Ronald Oussoren via Python-Dev
wrote:
> Of course. I mentioned it because the proposal is to add a new option that’s
> enabled after installation, and basically not when the testsuite is run.
> That’s not a problem, we could just enable the option in most CI jobs
On Tue, Sep 28, 2021 at 2:22 AM Marc-Andre Lemburg wrote:
> #3 sounds like a good solution, but how would you detect "running
> from the source tree" ? This sounds like you need another stat call
> somewhere, which is what the frozen modules try to avoid.
We already look for the stdlib dir in Mod
On Tue, Sep 28, 2021 at 6:36 AM Victor Stinner wrote:
> Honestly, for me, #1: always on, is the most reasonable choice.
>
> I dislike when Python behaves differently depending on subtle things
> like "was it built with optimizations" or "is Python started from its
> source tree"?
>
> When I built
On Tue, Sep 28, 2021 at 6:47 AM Pablo Galindo Salgado
wrote:
> One interesting consequence of what Eric mentioned (They have a different
> loader and repr. Also, frozen modules do not
> have __file__ set (and __path__ is always []).) is that frozen modules don't
> have a `__file__` attribute II
On Tue, Sep 28, 2021 at 6:55 AM Eric V. Smith wrote:
> As a compromise, how about go with #1, but print a warning if python
> detects that it's not built with optimizations or is run from a source
> tree (the conditions in #2 and #3)? The warning could suggest running
> with "-X frozen_modules=off
On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote:
> I think you should test with all pickle protocols.
I'll do that.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
On Sat, Feb 16, 2013 at 5:02 PM, Eric Snow wrote:
> On Sat, Feb 16, 2013 at 4:45 PM, Antoine Pitrou wrote:
>> I think you should test with all pickle protocols.
>
> I'll do that.
Out of curiousity, how critical is it to support protocols 0 and 1?
I've made sure SimpleNa
(See http://bugs.python.org/issue16251)
The pickle module looks up special methods on instances rather than
using the behavior described in the language reference (or even just
looking them up on the class). This means that custom
__getattribute__() and __getattr__() implementations may get trigg
On Wed, Feb 20, 2013 at 1:16 PM, ezio.melotti
wrote:
> http://hg.python.org/cpython/rev/9d00c79b27e1
> changeset: 82280:9d00c79b27e1
> branch: 3.3
> parent: 82278:96b4acb253f8
> user:Ezio Melotti
> date:Wed Feb 20 21:42:46 2013 +0200
> summary:
> Rebuild importlib.h
On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan wrote:
> However, pitching this at the enum level also introduces a mandatory
> level of structure we may not care about. All of the arguments about
> enums and what they should and shouldn't allow happen at the higher
> level, to do with the relation
On Wed, Feb 27, 2013 at 12:33 PM, fwierzbi...@gmail.com
wrote:
> There are a couple of spots that might be more controversial. For
> example, Jython has a file Lib/zlib.py that implements zlib in terms
> of the existing Java support for zlib. I do wonder if such a file is
> acceptable in CPython's
Having had some time to think about this problem space, here's my take on it:
===
The problem-space can be broken down into four layers:
1. the items
2. interaction between grouped items
3. the grouping itself
4. conversion from a class to a group
Here are *potential
On Thu, Feb 28, 2013 at 1:35 PM, Brett Cannon wrote:
> That should be fine as that is what we already do for accelerator modules
> anyway. If you want to work towards having an equivalent of CPython's
> Modules/ directory so you can ditch your custom Lib/ modules by treating
> your specific code a
On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic wrote:
> It seems like a good feature that an __int__ implementation can choose to
> return an int subclass with additional (and optional) information. After
> all, int subclass instances should be usable everywhere where ints are,
> including in C cod
On Mon, Apr 1, 2013 at 4:52 PM, Nick Coghlan wrote:
> This is really a quality-of-implementation issue in the import system rather
> than a core language design problem. It's just that those of us with the
> knowledge and ability to fix it aren't inclined to do so because circular
> imports usuall
On May 23, 2013 4:37 PM, "Steven D'Aprano" wrote:
>
> On 24/05/13 01:04, Ethan Furman wrote:
>> If the stdlib is still staying out of the annotation business, then it
should not be allowed.
>
>
>
> Perhaps it is time to relax that ruling? The standard library acts as a
guide to best practice in Py
On Thu, May 23, 2013 at 7:30 PM, Eric Snow wrote:
> If there were more
> discussion and consensus on annotations + decorators I'd be more convinced.
However, this PEP should not be gated on any such discussion.
-eric
___
Python-Dev mailing
The devguide doesn't have anything on performance testing that I could
find. We do have a number of relatively useful resources in this
space though, like pybench and (eventually) speed.python.org. I'd
like to add a page to the devguide on performance testing, including
an explanation of our perf
On Wed, May 29, 2013 at 10:49 AM, R. David Murray wrote:
> Perhaps 'managed_module'?
I was just thinking the same thing.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
On Wed, May 29, 2013 at 2:22 PM, Brett Cannon wrote:
> So module_to_init it is unless someone can convince me the bikeshed is
> a different colour.
Whatever the name is, it should reflect what is happening during the
with statement, and more particularly that the thing will end at the
end of the
On Fri, Jun 21, 2013 at 9:29 AM, Nick Coghlan wrote:
> So why not just replace the *broken* parts of stat.py and keep the
> rest of it?
In some ways this sounds like yet another use case for what amounts to
properties on modules. The sketchy contants that are causing concern
could raise NotImple
There are two relevant class namespaces in this proposal: definition
namespace and __dict__. Currently both are dicts.
For class definition namespaces, I'd like to make the default an
OrderedDict. With the implementation in issue16991, the change is
trivial (basically 1-liners in 2 spots). This
On Thu, Jun 27, 2013 at 2:48 AM, Nick Coghlan wrote:
> I think the main concern I would have is whether other implementations
> are happy they can provide a suitable ordered dictionary for class
> namespace execution.
>
> It's also worth considering what would have to happen for dynamically
> crea
On Thu, Jun 27, 2013 at 9:35 AM, Ethan Furman wrote:
> On 06/27/2013 08:18 AM, Eric Snow wrote:
>> Good points. In either case there is no definition order available.
>> I'm okay with that. Would it be better to represent that as None (and
>> the attribute is always
On Thu, Jul 4, 2013 at 5:21 AM, Chris Withers wrote:
> Hi All,
>
> In Python 2, I can figure out whether I have a method or a function, and,
> more importantly, for an unbound method, I can figure out what class the
> method belongs to:
>
> >>> class MyClass(object):
> ... def method(self): pass
On Feb 27, 2013 4:31 AM, "Michael Foord" wrote:
>
>
> On 27 Feb 2013, at 11:00, David Beazley wrote:
>
> >>
> >> From: Eli Bendersky
> >>
> >> I'll be the first one to admit that pycparser is almost certainly not
> >> generally useful enough to be exposed in the stdlib. So just using it
as an
>
On Thu, Aug 29, 2013 at 3:27 AM, serhiy.storchaka <
python-check...@python.org> wrote:
> http://hg.python.org/cpython/rev/997de0edc5bd
> changeset: 85444:997de0edc5bd
> parent: 85442:676bbd5b0254
> user:Serhiy Storchaka
> date:Thu Aug 29 12:26:23 2013 +0300
> summary:
> I
On Sat, Aug 24, 2013 at 7:07 AM, Stefan Behnel wrote:
> PEP 3121 would no longer be necessary. Extension types can do all we need.
> No more special casing of modules, that was the idea.
>
One nice thing about PEP 3121 is the addition of md_state to module objects
to store internal module state.
On Sat, Aug 24, 2013 at 10:12 PM, PJ Eby wrote:
> I haven't had a chance to address this on the import-sig discussion
> yet about ModuleSpec, but I would like to just mention that one
> property of the existing module system that I'm not sure either this
> proposal or the ModuleSpec proposal pres
On Sat, Aug 31, 2013 at 1:16 PM, Stefan Behnel wrote:
> Nick Coghlan, 31.08.2013 18:49:
> > This is actually my primary motivation for trying to improve the
> > "can this be reloaded or not?" aspects of the loader API in PEP 451.
>
> I assume you mean that the extension module would be able to cl
On Mon, Sep 2, 2013 at 2:16 AM, Antoine Pitrou wrote:
> I think the biggest challenge here is to propose an API that's simple
> and easy to use (i.e. that doesn't make extension module writing more
> complicated than it currently is).
>
+1
>
> The basic concept of putting custom module objects
On Mon, Sep 2, 2013 at 7:02 AM, Nick Coghlan wrote:
> The hook API I currently have in mind is a two step initialisation:
>
> PyImport_PrepareNAME (optional)
> PyImport_ExecNAME
>
Should we also look at an API change for the initfunc() of PyImport_Inittab
entries? Currently the function
On Thu, Sep 19, 2013 at 4:12 AM, Nick Coghlan wrote:
> On 19 Sep 2013 20:00, "Paul Moore" wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren
> wrote:
> > > The first time a method is called the bridge looks for an Objective-C
> selector
> > > with the same name and adds that to the clas
On Thu, Sep 19, 2013 at 4:04 AM, Ronald Oussoren wrote:
> The C code uses PyDict_GetItem and AFAIK that doesn't look for a
> __getitem__
> implementation in a subclass.
>
Yeah, the PyDict_* API is definitely not subclass friendly. :(
-eric
___
Python-D
On Thu, Sep 19, 2013 at 3:49 AM, Ronald Oussoren wrote:
> On 14 Sep, 2013, at 8:30, Nick Coghlan wrote:
> > However, I agree the current wording only conveys that to the handful
> > of people that already know exactly when in the attribute lookup
> > sequence that step occurs, which is a rather n
On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling wrote:
> On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
>> -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
>> +- Issue #19151: Fix docstring and use of _get_suppported_file_loaders() to
>
On Thu, Oct 3, 2013 at 2:21 PM, Barry Warsaw wrote:
> PPProbably not the typppo Andrew was pppointing out.
>
> -Bary
Ohhh, that typppo.
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
=
PEP: 451
Title: A ModuleSpec Type for the Import System
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow
Discussions-To: import-...@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 8-Aug-2013
Python-Version: 3.4
Post-History: 8-Aug-2013, 28
On Sat, Oct 5, 2013 at 1:25 AM, Stefan Behnel wrote:
> As a quick remark, reading the word "name" made me think a couple of times
> whether it's the simple name of the module or the fully qualified name. I
> think it's the FQMN in pretty much all cases, but it would be good to make
> that clear, m
On Tue, Oct 8, 2013 at 5:33 PM, Larry Hastings wrote:
>
> I've contributed a new PEP to humanity. I include the RST for your reading
> pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
>
>
> Discuss,
The PEP doesn't mention anything about inspect.
On Tue, Oct 8, 2013 at 9:02 PM, Terry Reedy wrote:
> I am for having a way to succintly properly describe the signature of C in
> the manual and docstrings and help output. As it is now, the only safe thing
> to do, without trial and exception, is to assume positional only unless one
> knows other
On Oct 9, 2013 4:04 AM, "Paul Moore" wrote:
> But if the intention is that any attempt to add the functionality to
> Python will be constrained to use the syntax here, surely that means
> we need to have all of the usability arguments and bikeshedding *now*.
> otherwise the opportunity is lost?
I
On Wed, Oct 9, 2013 at 8:53 AM, Larry Hastings wrote:
> But that's not how addch works. addch counts how many arguments it
> received; if it is called with one or two, it does one thing, and if it's
> called with three or four it does something else. You can't duplicate these
> semantics with
>
On Wed, Oct 9, 2013 at 11:38 AM, R. David Murray wrote:
> It seems to me, then, that the solution for the
> handle-the-ugly-existing-practice-groups issue is to make case (3)
> (pydoc prototype) match the convention that we have arrived at for the
> documentation: multiple signature lines to repr
On Wed, Oct 9, 2013 at 12:20 PM, Eric Snow wrote:
> For me the allure of positional-only arguments lies in the following:
>
> 1. not having to roll my own *args handling;
> 2. not having to clutter up my code with the *args handling;
> 3. not having to handle positional-or-keyw
On Wed, Oct 9, 2013 at 8:30 AM, Christian Heimes wrote:
> The os module imports MutableMapping from collections.abc. That import
> adds collections, collections.abc and eight more modules. I'm not sure
> if we can do anything about it, though.
Well, that depends on how much we want to eliminate t
Registration is now open for PyCon US 2014. Are there any plans yet
for the language summit? Just the day (e.g. Thursday April 10) will
suffice. Then we can make arrangements appropriately. Thanks.
-eric
___
Python-Dev mailing list
Python-Dev@python.
On Thu, Oct 10, 2013 at 4:18 AM, Christian Heimes wrote:
> We don't have to use a custom module type to get rid of these imports
> (but I like to get my hands a piece of chocolate cake *g*). We can
> either implement yet another mutable mapping class for the os module.
> That would remove the depe
On Fri, Oct 4, 2013 at 11:18 PM, Eric Snow wrote:
> After a few rounds on import-sig PEP 451 is really for general
> consumption. I also have a patch up now.
>
> HTML: http://www.python.org/dev/peps/pep-0451/
> implementation: http://bugs.python.org/issue18864
>
> Y
On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> Just create a _pydecimal module (like _pyio).
>
> That's very fast indeed. There's one minor problem: For backwards
> compatibility
> and pickling [1] I'd need to add
>
> __module__ = 'decimal'
>
> to every class
On Fri, Oct 11, 2013 at 10:04 PM, Nick Coghlan wrote:
> Adopting a suitable set of keywords (like unicode, import, builtins, syntax,
> stdlib, cpython) could be interesting, though.
A couple years ago I started a page on the wiki for a topical listing
of the PEPS [1]. I even brought up having a
On Oct 16, 2013 5:35 AM, "Victor Stinner" wrote:
>
> 2013/10/16 Raymond Hettinger :
> > FWIW, here's a little history:
>
> Thank you! It helped me to understand the story.
>
> > * In February, I presented ignore() in the keynote for the U.S. Pycon.
> > Again, the feedback was positive.
>
> I mis
On Wed, Oct 16, 2013 at 10:26 AM, Facundo Batista
wrote:
> (all this using Python 3.4.0a3+)
>
> In the stdlib, I see that (as an example):
>
import os
os.path.abspath
>
os.path
>
>
>
> However, for other (newer) modules:
>
import urllib
urllib.requests.urlopen
> Tracebac
On Wed, Oct 16, 2013 at 9:24 AM, Barry Warsaw wrote:
> On Oct 16, 2013, at 08:31 AM, Eric Snow wrote:
>>When a module's maintainer makes a decision on a relatively insignificant
>>addition to the module, I'd expect little resistance or even comment (the
>>original
On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote:
> On 6/7/2016 1:51 PM, Eric Snow wrote:
>
>> Note: just to be clear, this PEP is *not* about changing
>
>> ``type.__dict__`` to ``OrderedDict``.
>
> By 'type', do you mean the one and one objected named '
On Tue, Jun 7, 2016 at 11:36 AM, Émanuel Barry wrote:
>> From: Eric Snow
>> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
>
> What does this imply? If I define some __dunder__ methods, will they simply
> not be present in __definition_orde
On Tue, Jun 7, 2016 at 11:45 AM, Ethan Furman wrote:
> On 06/07/2016 11:13 AM, Eric Snow wrote:
>> A __definition_order__ in the class body always takes precedence. So
>> a supplied value will be honored (and not replaced with None).
>
> Will the supplied __definition_or
On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote:
> On 7 June 2016 at 10:51, Eric Snow wrote:
>> * ``__definition_order__`` is a tuple
>> * ``__definition_order__`` is a read-only attribute
>
> Thinking about the class decorator use case, I think this may need to
> b
On Tue, Jun 7, 2016 at 2:34 PM, Nick Coghlan wrote:
> On 7 June 2016 at 14:20, Eric Snow wrote:
>> What would you consider to be the
>> benefit of a mutable (or replaceable) __definition_order__ that
>> outweighs the benefit of a simpler definition of what's in it.
>
On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman wrote:
> On 06/07/2016 02:20 PM, Eric Snow wrote:
>> I think both of those make __definition_order__ more complicated and
>> less useful. As the PEP stands, folks can be confident in what
>> __definition_order__ represents. What
Title: Ordered Class Definition Namespace
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 7-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016
Abstract
This PEP changes the default class definiti
On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote:
> On 06/07/2016 05:50 PM, Eric Snow wrote:
>> __definition_order__ = tuple(k for k in locals()
>> if (!k.startswith('__') or
>>
On Tue, Jun 7, 2016 at 6:09 PM, Steven D'Aprano wrote:
> On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote:
>> I mean the latter, "type" -> the class being defined.
>
> Could you clarify that in the PEP please? Like Terry, I too found it
> unclear.
On Wed, Jun 8, 2016 at 12:07 AM, Franklin? Lee
wrote:
> On Jun 7, 2016 8:52 PM, "Eric Snow" wrote:
>> * the default class *definition* namespace is now ``OrderdDict``
>> * the order in which class attributes are defined is preserved in the
>
> By using an OrderedD
On Wed, Jun 8, 2016 at 1:07 AM, Victor Stinner wrote:
>> Abstract
>>
>>
>> This PEP changes the default class definition namespace to ``OrderedDict``.
>> Furthermore, the order in which the attributes are defined in each class
>> body will now be preserved in ``type.__definition_order__``
On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote:
> I'm guessing Ethan is suggesting defining it as:
>
> __definition_order__ = tuple(ns["__definition_order__"])
>
> When the attribute is present in the method body.
Ah. I'd rather stick to "consenting adults" in the case that
__definition_
On Thu, Jun 9, 2016 at 12:41 PM, wrote:
> Is there any further thoughts on including this in 3.6?
I don't have any plans and I don't know of anyone willing to champion
the PEP for 3.6. Note that the implementation itself shouldn't take
very long.
> Similar to the
> recent discussion on Ordere
On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote:
> As stated by Guido (and pointed out in the PEP):
>
> Making **kwds ordered is still open, but requires careful design and
> implementation to avoid slowing down function calls that don't benefit.
>
> The PEP has not been updated in a while, th
201 - 300 of 572 matches
Mail list logo
