I recently got an inquiry from some of my users about porting some of
my libraries to Python 3 that make use of the Python 2 __metaclass__
facility. While checking up on the status of PEP 422 today, I found
out about its recently proposed replacement, PEP 487.
While PEP 487 is a generally fine PE
On Wed, Apr 1, 2015 at 10:39 PM, Nick Coghlan wrote:
> On 2 April 2015 at 07:35, PJ Eby wrote:
>> I recently got an inquiry from some of my users about porting some of
>> my libraries to Python 3 that make use of the Python 2 __metaclass__
>> facility. While checking up on
On Thu, Apr 2, 2015 at 4:46 AM, Nick Coghlan wrote:
> On 2 April 2015 at 16:38, PJ Eby wrote:
>>
>> IOW, there's no need to modify the core just to have *that* feature,
>> since if you control the base class you can already do what PEP 487
>> does in essential
On Thu, Apr 2, 2015 at 1:42 PM, PJ Eby wrote:
> If the PEP 487 metaclass library,
> however, were to just port some bits of my code to Python 3 this could
> be a done deal already and available in *all* versions of Python 3,
> not just the next one.
Just for the heck of it, here
On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann
wrote:
> The whole point of PEP 487 was to reduce PEP 422 so much that
> it can be written in python and back-ported.
As I said earlier, it's a fine feature and should be in the stdlib for
Python 3. (But it should have a `noconflict` feature added
On Thu, Apr 2, 2015 at 10:29 PM, Greg Ewing wrote:
> On 04/03/2015 02:31 PM, Nick Coghlan wrote:
>>
>> If I'm understanding PJE's main concern correctly it's that this
>> approach requires explicitly testing that the decorator has been
>> applied correctly in your automated tests every time you us
On Thu, Apr 2, 2015 at 9:31 PM, Nick Coghlan wrote:
> On 3 April 2015 at 08:24, Martin Teichmann wrote:
> However, I'm also now wondering if it may be possible to reach out to
> the pylint authors (similar to what Brett did for the "pylint --py3k"
> flag) and ask for a way to make it easy to regi
On Fri, Apr 3, 2015 at 8:44 AM, Martin Teichmann
wrote:
> This proposal can actually be seen as an extension to the __class__
> and super() mechanism of normal methods: methods currently have the
> priviledge to know which classes they are defined in, while descriptors
> don't. So we could unify a
On Fri, Apr 3, 2015 at 11:04 AM, Nick Coghlan wrote:
> Extending the descriptor protocol to include a per-descriptor hook that's
> called at class definition time sounds like a potentially nice way to go to
> me. While you *could* still use it to arbitrarily mutate the class object,
> it's much cl
On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while folks that t
On Sat, Apr 4, 2015 at 9:33 PM, Nick Coghlan wrote:
> So actually reading https://gist.github.com/pjeby/75ca26f8d2a7a0c68e30
> properly, you're starting to convince me that a "noconflict" metaclass
> resolver would be a valuable and viable addition to the Python 3 type
> system machinery.
>
> The
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
> It is an error to pass a regular context manager without ``__aenter__``
> and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
> to use ``async with`` outside of a coroutine.
I find this a little weird. Why not just have `
On Mon, May 11, 2015 at 6:05 PM, Guido van Rossum wrote:
> OTOH you may look at micropython's uasyncio -- IIRC it doesn't have Futures
> and it definitely has I/O waiting.
Here's a sketch of an *extremely* minimal main loop that can do I/O
without Futures, and might be suitable as a PEP example.
On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman wrote:
> The plan is to extend the PEP in the future collecting information
> about equivalence of Mercurial and git scenarios to help migrating
> Python development from Mercurial to git.
I couldn't find any previous discussion about this, but I fig
I've not really had time to review this PEP yet, but from skimming
discussion to date, the only thing I'm still worried about is whether
this will break lazy import schemes that use a module subclass that
hooks __getattribute__ and calls reload() in order to perform what's
actually an *initial* loa
On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon wrote:
>
> On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
>> At least through all 2.x, reload() just uses module.__name__ to
>> restart the module find-and-load process, and does not assume that
>> __loader__ is valid in adv
On Fri, Oct 25, 2013 at 3:15 PM, Brett Cannon wrote:
> On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby wrote:
>> On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon wrote:
>> > On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
>> >> At least through all 2.x, reload() just uses mo
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
> Now, regarding the signature of exec_module(): I'm back to believing
> that loaders should receive a clear indication that a reload is taking
> place. Legacy loaders have to figure that out for themselves (by
> seeing that the module already e
On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
>
> On 28 Oct 2013 02:37, "PJ Eby" wrote:
>>
>> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
>> > Now, regarding the signature of exec_module(): I'm back to believing
>> > that load
On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan wrote:
>
> On 31 Oct 2013 18:52, "Eric Snow" wrote:
>>
>> On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote:
>> > There's also the option of implementing the constraint directly in the
>> > finder, which *does* have the necessary info (with the ch
On Mon, Apr 28, 2014 at 7:26 PM, Paul Sokolovsky wrote:
> Well, sure I did, as I mentioned, but as that's first time I see that
> code (that specific piece is in typeobject.c:extra_ivars()), it would
> take quite some time be sure I understand all aspects of it. Thanks for
> confirming that it's
On Wed, Feb 20, 2013 at 5:30 AM, M.-A. Lemburg wrote:
> The wording in the PEP alienates the egg format by defining
> an incompatible new standard for the location of the metadata
> file:
This isn't a problem, because there's not really a use case at the
moment for eggs to include a PEP 426-forma
On Tue, Feb 19, 2013 at 6:42 AM, Nick Coghlan wrote:
> Nothing in the PEP is particularly original - almost all of it is
> either stolen from other build and packaging systems, or is designed
> to provide a *discoverable* alternative to existing
> setuptools/distribute/pip practices (specifically,
On Sun, Mar 3, 2013 at 12:31 PM, Brett Cannon wrote:
> But how about this as a compromise over introducing write_module():
> invalidate_caches() can take a path for something to specifically
> invalidate. The path can then be passed to the invalidate_caches() on
> sys.meta_path. In the case of Pat
On Sat, Mar 23, 2013 at 3:05 PM, Luca Sbardella
wrote:
> The pseudocode above does yields bytes before start_response, but they are
> not *body* bytes, they are empty bytes so that the asynchronous wsgi server
> releases the eventloop and call back at the next eventloop iteration.
>
> I'm I misint
On Wed, Mar 27, 2013 at 5:19 PM, Bradley M. Froehle
wrote:
> I implemented just such a path hook zipimporter plus the magic required
> for C extensions --- as a challenge to myself to learn more about the Python
> import mechanisms.
>
> See https://github.com/bfroehle/pydzipimport.
FYI, ther
On Tue, Mar 26, 2013 at 11:00 PM, Rocky Bernstein wrote:
> Okay. But is the string is still somewhere in the CPython VM stack? (The
> result of LOAD_CONST 4 above). Is there a way to pick it up from there?
Maybe using C you could peek into the frame's value stack, but that's
not exposed to any Py
On Thu, Mar 28, 2013 at 6:43 AM, Rocky Bernstein wrote:
> Of course the debugger uses sys.settrace too, so the evil-ness of that is
> definitely not a concern. But possibly I need to make sure that since the
> DecoratorTools and the debugger both hook into trace hooks they play nice
> together and
On Thu, Apr 4, 2013 at 11:17 AM, Guido van Rossum wrote:
> I don't really see what we could change to avoid breaking code in any
> particular case
Actually, the problem has *nothing* to do with circularity per se;
it's that "import a.b" and "from a import b" behave differently in
terms of how the
On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum wrote:
> I do think it would be fine if "from a import b" returned the
> attribute 'b' of module 'a' if it exists, and otherwise look for
> module 'a.b' in sys.modules.
Technically, it already does that -- but inside of __import__, not in
the IMPOR
On Sat, Apr 27, 2013 at 2:27 PM, Ethan Furman wrote:
> I filed bug http://bugs.python.org/issue17853 last night.
>
> If somebody could point me in the right direction (mainly which files to
> look in), I'd be happy to attempt a patch.
Wow. I had no idea Python actually did this (override class-l
On Sun, Apr 28, 2013 at 7:37 PM, Steven D'Aprano wrote:
> I have also suggested that that the enum package provide a decorator
> which can be used to explicitly flag values to *not* be turned into
> enum values. See here:
>
> http://mail.python.org/pipermail/python-dev/2013-April/125641.html
In t
On Mon, May 6, 2013 at 4:46 AM, Armin Rigo wrote:
> This is clearly a language design issue though. I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong. It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries
On Thu, May 23, 2013 at 11:11 AM, Paul Moore wrote:
> Is the debate between 1 and 2, or 1 and 3? Is it even possible to implement
> 3 without having 2 different names for "register"?
Yes. You could do it as either:
@func.register
def doit(foo: int):
...
by checking for the first
On Thu, May 23, 2013 at 2:59 PM, PJ Eby wrote:
> I generally lean towards returning the undecorated function, so that if you
> say:
>
> @func.register
> def do_int(foo: int):
> ...
Oops, forgot to mention: one other advantage to returning the
undecorated fu
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt wrote:
> It seems no one has provided
> decent use-case examples (apart from contrived ones)
Um, copy.copy(), pprint.pprint(), a bunch of functions in pkgutil
which are actually *based on this implementation already* and have
been since Python 2.5... I d
On Thu, May 23, 2013 at 11:57 PM, Nick Coghlan wrote:
> We should be able to use it to help deal with the "every growing
> importer API" problem, too. I know that's technically what pkgutil
> already uses it for, but elevating this from "pkgutil implementation
> detail" to "official stdlib functio
On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa wrote:
> The most important
> change in this version is that I introduced ABC support and completed
> a reference implementation.
Excellent! A couple of thoughts on the implementation...
While the dispatch() method allows you to look up what impleme
On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan wrote:
> Given the global nature of the cache invalidation, it may be better as
> a module level abc.get_cache_token() function.
Well, since the only reason to ever use it is to improve performance,
it'd be better to expose it as an attribute than as
On Sat, May 25, 2013 at 9:18 AM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue17936, I proposed making tp_subclasses
> (the internal container implementing object.__subclasses__) a dict.
> This would make the return order of __subclasses__ completely
> undefined, while it is right now sl
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
> So, the latest document is live:
> http://www.python.org/dev/peps/pep-0443/
>
> The code is here:
> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
>
> The documentation here:
> http://hg.python.org/features/pep-443/file/t
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
> Is it true that this cannot be used for instance and class methods? It
> dispatches based on the first argument, which is "self" for instance
> methods, whereas the second argument would almost certainly be the
> argument one would want to
On Fri, Jun 7, 2013 at 1:54 PM, Mark Janssen wrote:
> On Fri, Jun 7, 2013 at 10:50 AM, Mark Janssen
> wrote:
>>> >>> from pickle import dumps, loads
>>> >>> Fruit.tomato is loads(dumps(Fruit.tomato))
>>> True
>>
>> Why are you using is here instead of ==? You're making a circular
>>
On Fri, Jun 7, 2013 at 10:27 AM, Thomas Wouters wrote:
> This isn't a new bug, but it's exposed by always importing weakref and
> atexit during interpreter startup. I'm wondering if that's really necessary
> :)
Importing it during startup isn't necessary per se; imports needed
only by the generic
On Fri, Jun 7, 2013 at 5:16 PM, Łukasz Langa wrote:
> On 7 cze 2013, at 22:50, PJ Eby wrote:
>
>> On Fri, Jun 7, 2013 at 10:27 AM, Thomas Wouters wrote:
>>> This isn't a new bug, but it's exposed by always importing weakref and
>>> atexit during inte
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam wrote:
>
>
> On 06/14/2013 10:36 AM, Guido van Rossum wrote:
>>
>> Not a bug. The same is done for file input -- CRLF is changed to LF before
>> tokenizing.
>
>
>
> Should this be the same?
>
>
> python3 -c 'print(bytes("""\r\n""", "utf8"))'
> b'\r\n'
>
>
On Thu, Jun 27, 2013 at 4:48 AM, Nick Coghlan wrote:
> I'd be tempted to kill PEP 422 as not worth the hassle if we did this.
I assume you mean the "namespace" keyword part of PEP 422, since PEP
422's class initialization feature is entirely orthogonal to
definition order or namespace customizati
On Fri, Aug 23, 2013 at 4:50 AM, Stefan Behnel wrote:
> Reloading and Sub-Interpreters
> ==
>
> To "reload" an extension module, the module create function is executed
> again and returns a new module type. This type is then instantiated as by
> the original module load
On Fri, Sep 20, 2013 at 9:54 AM, Jesus Cea wrote:
> Why str/bytes doesn't support weakrefs, beside memory use?
The typical use case for weakrefs is to break reference cycles, but
str and bytes can't *be* part of a reference cycle, so outside of
interning-like use cases, there's no need for weakre
On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou wrote:
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.
FWIW, I'm -1 also; the thread quickly convinced me that this is a
horrible idea, at least with the current name.
On Sun, Oct 13, 2013 at 1:58 PM, Alexander Belopolsky
wrote:
> People who write code using contextlib
> are expected to know
People who *read* that code while learning Python cannot be expected
to know that it is not really possible to ignore errors in Python.
If this feature is used under any n
On Tue, Oct 15, 2013 at 11:52 AM, R. David Murray wrote:
> I think 'trap' would be much clearer.
+1. Short and sweet, and just ambiguous enough that you don't leap to
the conclusion that the error is ignored. I agree that "suppress" is
basically a synonym for "ignore"; trap at least *implies* s
On Tue, Oct 15, 2013 at 8:57 AM, Nick Coghlan wrote:
> So, having been convinced that "ignore" was the wrong choice of name,
> reviewing the docs made it clear to me what the name *should* be.
>From the point of view of code *outside* a block, the error is indeed
suppressed.
But, as one of those
On Thu, Oct 6, 2011 at 12:02 PM, Barry Warsaw wrote:
> Well, I have to be honest, I've *always* thought "nest" would be a good
> choice
> for a feature like this, but years ago (IIRC) PJE wanted to reserve that
> term
> for something else, which I'm not sure ever happened.
>
Actually, it was pre
On Sun, Oct 9, 2011 at 3:15 AM, Éric Araujo wrote:
> After all, if setuptools and then pkg_resources were turned
> down for inclusion in Python 2.5, it’s not now that we have packaging
that we’ll change our mind and just bless eggs.
Actually, that's not what happened. I withdrew the approved
On Sun, Oct 9, 2011 at 4:14 PM, Paul Moore wrote:
> As regards the format, bdist_dumb is about the right level - but
> having just checked it has some problems (which if I recall, have been
> known for some time, and are why bdist_dumb doesn't get used).
> Specifically, bdist_dumb puts the locati
On Tue, Oct 11, 2011 at 12:14 PM, Toshio Kuratomi wrote:
> This may not be the preferred manner to write decorators but it's fairly
> straightforward and easy to remember compared to, say, porting away from
> the
> with statement.
>
You can emulate 'with' using decorators, actually, if you don't
On Mon, Oct 17, 2011 at 8:55 AM, Sam Partington wrote:
> Yes it is a bit annoying to have to treat those specially, but other
> than -c/-m it does not need to understand pythons args, just check
> that the arg is not an explicit version specifier. -q/-Q etc have no
> impact on how to treat the fi
On Mon, Oct 17, 2011 at 8:00 PM, Mark Hammond wrote:
> On 18/10/2011 3:24 AM, PJ Eby wrote:
>
>> What about -S (no site.py) and -E (no environment)? These are needed
>> for secure setuid scripts on *nix; I don't know how often they'd be used
>> in practice on
On Sun, Oct 30, 2011 at 6:52 PM, Paul Moore wrote:
> On 30 October 2011 18:04, Ned Deily wrote:
> > Has anyone analyzed the current packages on PyPI to see how many provide
> > binary distributions and in what format?
>
> A very quick and dirty check:
>
> dmg: 5
> rpm: 12
> msi: 23
> dumb: 132
>
10:24 PM, PJ Eby wrote:
> On Sun, Oct 30, 2011 at 6:52 PM, Paul Moore wrote:
>
>> On 30 October 2011 18:04, Ned Deily wrote:
>> > Has anyone analyzed the current packages on PyPI to see how many provide
>> > binary distributions and in what format?
>>
>
On Sun, Nov 6, 2011 at 7:29 AM, Nick Coghlan wrote:
> I think this was based on the assumption that *existing* namespace
> package approaches would break under the new scheme. Since that is not
> the case, I suspect those previous objections were overstated (and all
> packaging related code manag
On Sat, Nov 26, 2011 at 11:53 AM, Éric Araujo wrote:
> > Le 11/08/2011 20:30, P.J. Eby a écrit :
> >> At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote:
> >>> I’ll just regret that it's not possible to provide a module docstring
> >>> to inform that this is a namespace package used for X and Y.
> >
On Fri, Dec 9, 2011 at 10:11 AM, Barry Warsaw wrote:
> As Chris points out, this seems to be a use case tied to WSGI and PEP
> . I
> guess it's an unfortunate choice for so recent a PEP, but maybe there was
> no
> way to do better.
For the record, "native strings" are defined the way they
On Fri, Dec 9, 2011 at 11:11 PM, Terry Reedy wrote:
> This just gave me the idea of tagging tracebacks with the Python version
> number. Something like
>
> Traceback (Py3.2.2, most recent call last):
>
> and perhaps with the platform also
>
> Traceback (most recent call last) [Py3.2.2 on win23]:
On Sat, Dec 10, 2011 at 5:30 PM, Terry Reedy wrote:
> Is doctest really insisting that the whole line
> Traceback (most recent call last):
> exactly match, with nothing added? It really should not, as that is not
> part of the language spec. This seems like the tail wagging the dog.
>
It's a re
On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough wrote:
> Truth be told, in the vast majority of WSGI apps only high-level WSGI
> libraries (like WebOb and Werkzeug) and standalone middleware really
> needs to work with native strings. And the middleware really should be
> using the high-level l
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou wrote:
> On Tue, 13 Dec 2011 15:28:31 +0100
> "Laurence Rowe" wrote:
> >
> > The approach that most people seem to have settled on for porting
> > libraries to Python 3 is to make a single codebase that is compatible
> with
> > both Python 2 and Py
On Tue, Dec 13, 2011 at 7:30 PM, Antoine Pitrou wrote:
> On Tue, 13 Dec 2011 14:02:45 -0500
> PJ Eby wrote:
> >
> > Among other things, it means that:
> >
> > * There's only one codebase
> > * If the conversion isn't perfect, you only have
On Thu, Dec 29, 2011 at 8:32 AM, Christian Heimes wrote:
> IMHO we don't have to alter the outcome of hash("some string"), hash(1)
> and all other related types. We just need to reduce the change the an
> attacker can produce collisions in the dict (and set?) code that looks
> up the slot (PyDict
On Sat, Dec 31, 2011 at 7:03 AM, Stephen J. Turnbull wrote:
> While the dictionary probe has to start with a hash for backward
> compatibility reasons, is there a reason the overflow strategy for
> insertion has to be buckets containing lists? How about
> double-hashing, etc?
>
This won't help,
On Sat, Dec 31, 2011 at 4:04 PM, Jeffrey Yasskin wrote:
> Hash functions are already unstable across Python versions. Making
> them unstable across interpreter processes (multiprocessing doesn't
> share dicts, right?) doesn't sound like a big additional problem.
> Users who want a distributed has
On Sun, Jan 1, 2012 at 7:37 PM, Jim Jewett wrote:
> Well, there is nothing wrong with switching to a different hash function
> after N
> collisions, rather than "in the first place". The perturbation
> effectively does by
> shoving the high-order bits through the part of the hash that survives t
On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett wrote:
> Given the wording requiring a real dictionary, I would have assumed
> that it was OK (if perhaps not sensible) to do pointer arithmetic and
> access the keys/values/hashes directly. (Though if the breakage was
> between python versions, I woul
On Mon, Jan 2, 2012 at 4:07 PM, Jim Jewett wrote:
> On Mon, Jan 2, 2012 at 1:16 AM, PJ Eby wrote:
> > On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett
> wrote:
> >>
> >> Given the wording requiring a real dictionary, I would have assumed
> >> that it was OK
On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote:
> STM is a relatively new technology being experimented with in newer
> languages, and in a number of 3rd party libraries (both Peak [#Peak]_
> and Kamaelia [#Kamaelia]_ provide STM facilities).
I don't know about Kamaelia, but PEAK's STM (part
On Wed, Jan 11, 2012 at 7:01 PM, Mike Meyer wrote:
> On Wed, 4 Jan 2012 00:07:27 -0500
> PJ Eby wrote:
> > On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote:
> > > For
> > > instance, combining STM with explicit locking would allow explicit
> > > locking
On Tue, Jan 17, 2012 at 7:58 PM, "Martin v. Löwis" wrote:
> Am 17.01.2012 22:26, schrieb Antoine Pitrou:
> > Only 2 bits are used in ob_sstate, meaning 30 are left. These 30 bits
> > could cache a "hash perturbation" computed from the string and the
> > random bits:
> >
> > - hash() would use ob_s
On Jan 18, 2012 12:55 PM, Martin v. Löwis wrote:
>
> Am 18.01.2012 17:01, schrieb PJ Eby:
> > On Tue, Jan 17, 2012 at 7:58 PM, "Martin v. Löwis" > <mailto:mar...@v.loewis.de>> wrote:
> >
> > Am 17.01.2012 22:26, schrieb Antoine Pitrou:
> >
2012/1/24 Alexis Métaireau
> Entrypoints basically are a plugin system. They are storing information in
> the metadata and then retrieving them when needing them. The problem with
> this, as everything when trying to get information from metadata is that we
> need to parse all the metadata for al
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
> Such a protocol can easily be extended to any other type - the time
> module could provide conversion functions for integers and float
> objects (meaning results may have lower precision than the underlying
> system calls), while the existing
On Jan 31, 2012 11:08 PM, "Nick Coghlan" wrote:
> PJE is quite right that using a new named protocol rather than a
> callback with a particular signature could also work, but I don't see
> a lot of advantages in doing so.
The advantage is that it fits your brain better. That is, you don't have
t
On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon wrote:
> So, if there is going to be some baseline performance target I need to hit
> to make people happy I would prefer to know what that (real-world)
> benchmark is and what the performance target is going to be on a non-debug
> build. And if people
On Tue, Feb 7, 2012 at 5:24 PM, Brett Cannon wrote:
>
> On Tue, Feb 7, 2012 at 16:51, PJ Eby wrote:
>
>> On Tue, Feb 7, 2012 at 3:07 PM, Brett Cannon wrote:
>>
>>> So, if there is going to be some baseline performance target I need to
>>> hit to make p
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy wrote:
> importlib could provide a parameterized decorator for functions that are
> the only consumers of an import. It could operate much like this:
>
> def imps(mod):
>def makewrap(f):
>def wrapped(*args, **kwds):
>print('first
On Wed, Feb 8, 2012 at 4:08 PM, Brett Cannon wrote:
>
> On Wed, Feb 8, 2012 at 15:31, Terry Reedy wrote:
>
>> For top-level imports, unless *all* are made lazy, then there *must* be
>> some indication in the code of whether to make it lazy or not.
>>
>
> Not true; importlib would make it dead-si
On Feb 9, 2012 9:58 AM, "Brett Cannon" wrote:
> This actually depends on the type of ImportError. My current solution
actually would trigger an ImportError at the import statement if no finder
could locate the module. But if some ImportError was raised because of some
other issue during load then
On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer wrote:
> For those of you not watching -ideas, or ignoring the "Python TIOBE
> -3%" discussion, this would seem to be relevant to any discussion of
> reworking the import mechanism:
>
> http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801
On Thu, Feb 9, 2012 at 5:34 PM, Robert Kern wrote:
> On 2/9/12 10:15 PM, Antoine Pitrou wrote:
>
>> On Thu, 9 Feb 2012 17:00:04 -0500
>> PJ Eby wrote:
>>
>>> On Thu, Feb 9, 2012 at 2:53 PM, Mike Meyer wrote:
>>>
>>> For those of you not wat
On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote:
>
>
> On Thu, Feb 9, 2012 at 17:00, PJ Eby wrote:
>
>> I did some crude timeit tests on frozenset(listdir()) and trapping failed
>> stat calls. It looks like, for a Windows directory the size of the 2.7
>> stdli
On Feb 10, 2012 3:38 PM, "Brett Cannon" wrote:
> On Fri, Feb 10, 2012 at 15:07, PJ Eby wrote:
>> On Fri, Feb 10, 2012 at 1:05 PM, Brett Cannon wrote:
>>> First is that if this were used on Windows or OS X (i.e. the OSs we
support that typically have case-insensi
On Mon, Feb 20, 2012 at 1:20 PM, Brett Cannon wrote:
> On Sun, Feb 19, 2012 at 22:15, Nick Coghlan wrote:
>
>> However, "very cool" on adding the caching in the default importers :)
>
>
> Thanks to PJE for bringing the idea up again and Antoine discovering the
> approach *independently* from PJE
On Sat, Mar 3, 2012 at 5:02 AM, Lennart Regebro wrote:
> I'm not sure that's true at all. In most cases where you support both
> Python 2 and Python 3, most strings will be "native", ie, without
> prefix in either Python 2 or Python 3. The native case is the most
> common case.
>
Exactly. The r
On Wed, Mar 7, 2012 at 8:39 PM, Victor Stinner wrote:
> So my question is: what is the use case of such dict?
Well, I use them for this:
http://pypi.python.org/pypi/AddOns
(And I have various other libraries that depend on that library.)
Short version: AddOns are things you can use to dynamic
On Thu, Mar 8, 2012 at 2:43 AM, Ethan Furman wrote:
>
> PJ Eby wrote:
>>
>> Short version: AddOns are things you can use to dynamically extend
instances -- a bit like the "decorator" in "decorator pattern" (not to be
confused with Python decorators). Rathe
On Sat, Mar 10, 2012 at 5:49 PM, Thomas Wouters wrote:
> (And, yes, I'm zipping up the stdlib for Python 2.7 at Google, to reduce
> the impact on the aforementioned million of machines :)
>
You might want to consider instead backporting the importlib caching
facility, since it provides some of t
Ugh; this was supposed to be sent to the list, not just Guido. (I wish
Gmail defaulted to reply-all in the edit box.)
-- Forwarded message --
From: PJ Eby
Date: Mon, Mar 12, 2012 at 12:16 AM
Subject: Re: [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace
packages)?
To
On Wed, Mar 14, 2012 at 5:02 AM, Antoine Pitrou wrote:
> On Wed, 14 Mar 2012 04:26:16 +
> Kristján Valur Jónsson wrote:
> > Hi there.
> > I want to mention some issues I've had with the socketserver module, and
> discuss if there's a way to make it nicer.
> > So, for a long time we were able
On Wed, Mar 14, 2012 at 12:29 PM, Antoine Pitrou wrote:
> On Wed, 14 Mar 2012 12:17:06 -0400
> PJ Eby wrote:
> > That's not really the point; the frameworks that implement nonblocking
> I/O
> > by replacing the socket module (and Stackless is only one of many) won&
On Mar 19, 2012 1:20 PM, "Ned Deily" wrote:
>
> In article <20120319142539.7e83c...@pitrou.net>,
> Antoine Pitrou wrote:
> > [...] As for svn.python.org, is anyone
> > using it?
>
> The repo for the website (www.python.org) is maintained there.
It's also still setuptools' official home, though
1 - 100 of 190 matches
Mail list logo
