Re: [Python-Dev] PEP: Collecting information about git

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

Re: [Python-Dev] Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)

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.

Re: [Python-Dev] async/await in Python; v2

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 `

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

[Python-Dev] PEP 487 vs 422 (dynamic class decoration)

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

Re: [Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] PEP 451 update

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

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

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

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

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

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

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

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

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.

Re: [Python-Dev] sys.intern should work on bytes

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

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

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

Re: [Python-Dev] Classes with ordered namespaces

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

Re: [Python-Dev] eval and triple quoted strings

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' > >

Re: [Python-Dev] [Python-checkins] cpython: Add reference implementation for PEP 443

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

Re: [Python-Dev] [Python-checkins] cpython: Add reference implementation for PEP 443

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

Re: [Python-Dev] doctest and pickle

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 >>

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

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

Re: [Python-Dev] __subclasses__() return order

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

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

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

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

Re: [Python-Dev] class name spaces inside an outer function

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

Re: [Python-Dev] relative import circular problem

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

Re: [Python-Dev] relative import circular problem

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

Re: [Python-Dev] Can I introspect/reflect to get arguments exec()?

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

Re: [Python-Dev] Can I introspect/reflect to get arguments exec()?

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

Re: [Python-Dev] Safely importing zip files with C extensions

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

Re: [Python-Dev] wsgi validator with asynchronous handlers/servers

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

Re: [Python-Dev] Planning on removing cache invalidation for file finders

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

Re: [Python-Dev] [Distutils] PEP 426 is now the draft spec for distribution metadata 2.0

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,

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

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

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum wrote: > Hi Nick, > > I think this will make a fine addition to the language. I agree that > it is superior to the alternatives and fulfills a real (if rare) need. > > I only have a few nits/questions/suggestions. > > - With PJE, I think __init_cl

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

On Fri, Feb 8, 2013 at 5:44 PM, Stefan Behnel wrote: > Argh - sorry, got it all wrong. "__instancecheck__()" works exactly the > other way round. In the type check above, it's the FunctionType type that > gets asked for an instance check, which doesn't help at all in this case > because it simply

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel wrote: > So, the way to explain it to users would be 1) don't use it, 2) if you > really need to do something to a class, use a decorator, 3) if you need to > decide dynamically what to do, define __init_class__() and 4) don't forget > to call super'

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan wrote: >class Example: >@classmethod >def __init_class__(cls): Is the @classmethod required? What happens if it's not present? Second, will type have a default __init_class__? (IMO, it should, otherwise it will be impossible to

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote: > Nick Coghlan, 08.02.2013 16:20: >> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote: >>> 2013/2/8 Stefan Behnel: I'm wondering about the purpose of this code in inspect.Signature.from_function(): """ if not

Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)

On Sun, Feb 3, 2013 at 8:08 AM, Nick Coghlan wrote: > The rationale for the distutils freeze is "don't break setuptools". > That rationale still holds. IIRC, the historical issue that triggered the freeze was not that the distutils refactoring broke setuptools, but that it did so in what was supp

Re: [Python-Dev] Accessing value stack

On Mon, Jan 7, 2013 at 11:32 AM, Brett Cannon wrote: > On Mon, Jan 7, 2013 at 10:46 AM, Maciej Fijalkowski wrote: >> On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman wrote: >>> On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek >>> wrote: Hi, is it possible to access the values stored on

Re: [Python-Dev] More compact dictionaries with faster iteration

On Wed, Dec 12, 2012 at 5:06 PM, Dag Sverre Seljebotn wrote: > Perfect hashing already separates "hash table" from "contents" (sort of), > and saves the memory in much the same way. > > Yes, you can repeat the trick and have 2 levels of indirection, but that > then requires an additional table of

Re: [Python-Dev] More compact dictionaries with faster iteration

On Wed, Dec 12, 2012 at 3:37 PM, Dag Sverre Seljebotn wrote: > On 12/12/2012 01:15 AM, Nick Coghlan wrote: >> >> On Wed, Dec 12, 2012 at 5:37 AM, Dino Viehland > > wrote: >> >> OTOH changing certain dictionaries in IronPython (such as keyword >> args) to be >>

Re: [Python-Dev] More compact dictionaries with faster iteration

On Mon, Dec 10, 2012 at 5:14 PM, Andrew Svetlov wrote: > Please, no. dict and kwargs should be unordered without any assumptions. Why? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: htt

Re: [Python-Dev] More compact dictionaries with faster iteration

On Mon, Dec 10, 2012 at 4:29 PM, Tim Delaney wrote: > Whilst I think Python should not move to ordered dictionaries everywhere, I > would say there is an argument (no pun intended) for making **kwargs a > dictionary that maintains insertion order *if there are no deletions*. Oooh. Me likey. The

Re: [Python-Dev] More compact dictionaries with faster iteration

On Mon, Dec 10, 2012 at 1:01 PM, Armin Rigo wrote: > On Mon, Dec 10, 2012 at 5:16 PM, PJ Eby wrote: >> On the other hand, this would also make a fast ordered dictionary >> subclass possible, just by not using the free list for additions, >> combined with periodic compaction

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull wrote: > PJ Eby writes: > > > By "clear", I mean "free of prior assumptions". > > Ah, well, I guess I've just run into a personal limitation. I can't > imagine thinking that is "free

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Sun, Dec 9, 2012 at 10:38 PM, Andrew McNabb wrote: > On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote: >> If the packages have files in conflict, they won't be both installed. >> If they don't have files in conflict, there's nothing important to be >>

Re: [Python-Dev] More compact dictionaries with faster iteration

On Mon, Dec 10, 2012 at 10:48 AM, Antoine Pitrou wrote: > Le Mon, 10 Dec 2012 10:40:30 +0100, > Armin Rigo a écrit : >> Hi Raymond, >> >> On Mon, Dec 10, 2012 at 2:44 AM, Raymond Hettinger >> wrote: >> > Instead, the data should be organized as follows: >> > >> > indices = [None, 1, None, N

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Sun, Dec 9, 2012 at 8:48 PM, Stephen J. Turnbull wrote: > PJ Eby writes: > > This is a good example of what I meant about clear thinking on > > concrete use cases, vs. simply copying fields from distro tools. In > > the distro world, these kinds of fields ref

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Sun, Dec 9, 2012 at 12:54 AM, Nick Coghlan wrote: > On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby wrote: >> >> On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan wrote: >> > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby wrote: >> >> >> >> So if package A includ

Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]

On Sat, Dec 8, 2012 at 10:22 PM, MRAB wrote: > On 2012-12-09 01:15, Steven D'Aprano wrote: >> >> On 09/12/12 08:14, MRAB wrote: >> >>> If package A says that it conflicts with package B, it may or may not >>> be symmetrical, because it's possible that package B has been updated >>> since the autho

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan wrote: > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby wrote: >> >> So if package A includes a "Conflicts: B" declaration, I recommend the >> following: >> >> * An attempt to install A with B already present re

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan wrote: > That's not what a Conflicts field is for. It's to allow a project to say > *they don't support* installing in parallel with another package. If that's the actual intended use case, the PEP needs some revision. In particular, if there's a behav

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Fri, Dec 7, 2012 at 12:01 PM, Toshio Kuratomi wrote: > On Fri, Dec 07, 2012 at 01:18:40AM -0500, PJ Eby wrote: >> On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi wrote: >> > On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote: >> >> Nobody has actually pro

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi wrote: > On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote: >> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft >> wrote: >> >> Nobody has actually proposed a better one, outside of package renaming >> -- and th

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > >> The wheel implementation makes sure all the metadata (the .dist-info >> directory) >> is at the end of the .zip archive. It's possible to read the metadata with a >> single HTTP partial request for the end

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Thu, Dec 6, 2012 at 8:39 AM, Daniel Holth wrote: > It will be Obsoleted-By:. The "drop in replacement" requirement will be > removed. The package manager will say "you are using these obsolete > packages; check out these non-obsolete ones" but will not automatically pull > the replacement witho

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft wrote: > Arguing over Obsoletes vs Renames is a massive bikeshedding argument. And is entirely beside the point. The substantive question is whether it's Obsoletes or Obsoleted-By - i.e., which side is it declared on. > So it's a bad example. Hardly

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Wed, Dec 5, 2012 at 5:30 PM, Daniel Holth wrote: > My desire is to invent the useful "wheel" binary package format in a > reasonable and limited amount of time by making changes to Metadata 1.2 and > implementing the new metadata format and wheel in distribute and pip. Help > me out by allowing

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft wrote: > There's nothing preventing an installer from, during it's attempt to > install B, see it Obsoletes A, looking at what depends on A and > warning the user what is going to happen and prompt it. Unless the user wrote those things that depend on

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth wrote: > How to use Obsoletes: > > The author of B decides A is obsolete. > > A releases an empty version of itself that Requires: B > > B Obsoletes: A > > The package manager says "These packages are obsolete: A". Would you like to > remove them? > > U

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull wrote: > Daniel Holth writes: > > > When I used Obsoletes, it meant "I am no longer developing this other > > package that is identical to this re-named package". > > But as a user I could care less! The authors may care, but I don't > care

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 6:43 PM, Daniel Holth wrote: > No. We trust the packages we install, including the way they decide to use > the metadata. A bad package could delete all our files or cause dependency > resolution to fail. Mostly they won't. > That's sort of beside the point. The *only* u

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 5:01 PM, Daniel Holth wrote: > http://www.python.org/dev/peps/pep-0314/ says: > > The most common use of this field will be in case a package name > changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. > When you install Torqued Python, the Gor

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman wrote: > On 11/20/2012 12:46 PM, PJ Eby wrote: > > I personally don't think that forks claiming to "provide" something is > really a good thing to encourage; ISTM that saying a package *conflicts* > with another is

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip wrote: > Also: what happens when a requirement is for setuptools (>= X.Y), but the > distribute fork hasn't kept pace, and so only supports setuptools at a > lower > version than X.Y? I take it we're entirely comfortable with installing > setuptools X.

Re: [Python-Dev] Accept just PEP-0426

On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth wrote: > I think this PEP is a significant improvement from its predecessor. It > represents features like extras (provides-extra) and build requirements > (setup-requires-dist) that are in use in the Python community but cannot be > represented in ol

Re: [Python-Dev] AST optimizer implemented in Python

On Sat, Aug 11, 2012 at 8:03 PM, Brett Cannon wrote: > > It would also be very easy to expand importlib.abc.SourceLoader to add a > method which is called with source and returns the bytecode to be written > out which people could override with AST optimizations before sending the > bytecode back.

Re: [Python-Dev] Requesting pronouncement on PEP 0424

On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum wrote: > - Most importantly: calling len(obj) and catching TypeError can only > be a substitute for the real implementation, which IMO ought to check > for the presence of a tp_len slot. Alas, checking hasattr(obj, > '__len__') doesn't quite cut i

Re: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging

On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore wrote: > For complex stuff, subpackages > ("import X.Y") might be needed, but that's rare (and even then, key > names should be exposed directly from X). > > Paul. > > PS Having said all this, I don't maintain any code on PyPI - I'm a > user not a prod

Re: [Python-Dev] Empty directory is a namespace?

On Sun, Jun 24, 2012 at 3:27 PM, "Martin v. Löwis" wrote: > >> In short, it's not worth worrying about, and definitely nothing that > >> should cause people to spread an idea that __init__.py somehow speeds > >> things up. > > > > The best way to avoid people spreading that idea would be to show h

Re: [Python-Dev] Empty directory is a namespace?

On Sun, Jun 24, 2012 at 3:51 AM, "Martin v. Löwis" wrote: > On 23.06.2012 17:58, Antoine Pitrou wrote: > > On Sat, 23 Jun 2012 17:55:24 +0200 > > mar...@v.loewis.de wrote: > >>> That's true. I would have hoped for it to be recognized only when > >>> there's at least one module or package inside, b

Re: [Python-Dev] Status of packaging in 3.3

On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn < d.s.seljeb...@astro.uio.no> wrote: > On 06/22/2012 10:40 AM, Paul Moore wrote: > >> On 22 June 2012 06:05, Nick Coghlan wrote: >> >>> distutils really only plays at the SRPM level - there is no defined OS >>> neutral RPM equivalent. That's w

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore wrote: > End users should not need packaging tools on their machines. > Well, unless they're developers. ;-) Sometimes, the "end user" is a developer making use of a library. Development tools like distutils2, distribute/setuptools, bento would > *

Re: [Python-Dev] import too slow on NFS based systems

On Thu, Jun 21, 2012 at 10:08 AM, Daniel Braniss wrote: > > On Thu, 21 Jun 2012 13:17:01 +0300 > > Daniel Braniss wrote: > > > Hi, > > > when lib/python/site-packages/ is accessed via NFS, open/stat/access > is very > > > expensive/slow. > > > > > > A simple solution is to use an in memory direct

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé wrote: > telling us no one that is willing to maintain setuptools is able to do so. > (according to him) Perhaps there is some confusion or language barrier here: what I said at that time was that the only people who I already *knew* to be capable of

Re: [Python-Dev] Status of packaging in 3.3

On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough wrote: > On 06/21/2012 11:37 AM, PJ Eby wrote: > >> >> On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" > <mailto:zo...@zooko.com>> wrote: >> > >> > Philip J. Eby provisionally

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012 10:12 AM, "Chris McDonough" wrote: > - Install "package resources", which are non-Python source files that > happen to live in package directories. I love this phrasing, by the way ("non-Python source files"). A pet peeve of mine is the insistence by some people that such files

Re: [Python-Dev] Status of packaging in 3.3

On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O'Hearn" wrote: > > Philip J. Eby provisionally approved of one of the patches, except for > some specific requirement that I didn't really understand how to fix > and that now I don't exactly remember: > > http://mail.python.org/pipermail/distutils-sig/2009

Re: [Python-Dev] Status of packaging in 3.3

On Wed, Jun 20, 2012 at 11:57 PM, Nick Coghlan wrote: > > Right - clearly enumerating the features that draw people to use > setuptools over just using distutils should be a key element in any > PEP for 3.4 > > I honestly think a big part of why packaging ended up being incomplete > for 3.3 is tha

  1   2   >