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

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 gu...@python.org 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

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

On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com 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.

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

On Sat, Apr 4, 2015 at 9:33 PM, Nick Coghlan ncogh...@gmail.com 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

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

On Fri, Apr 3, 2015 at 8:44 AM, Martin Teichmann lkb.teichm...@gmail.com 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.

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

On Fri, Apr 3, 2015 at 11:04 AM, Nick Coghlan ncogh...@gmail.com 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

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

On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan ncogh...@gmail.com 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,

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

On Wed, Apr 1, 2015 at 10:39 PM, Nick Coghlan ncogh...@gmail.com wrote: On 2 April 2015 at 07:35, PJ Eby p...@telecommunity.com 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

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

On Thu, Apr 2, 2015 at 1:42 PM, PJ Eby p...@telecommunity.com 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

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

On Thu, Apr 2, 2015 at 9:31 PM, Nick Coghlan ncogh...@gmail.com wrote: On 3 April 2015 at 08:24, Martin Teichmann lkb.teichm...@gmail.com 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

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

On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann lkb.teichm...@gmail.com 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

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

On Thu, Apr 2, 2015 at 10:29 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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

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

On Thu, Apr 2, 2015 at 4:46 AM, Nick Coghlan ncogh...@gmail.com wrote: On 2 April 2015 at 16:38, PJ Eby p...@telecommunity.com 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 essentially

[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

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

On Mon, Apr 28, 2014 at 7:26 PM, Paul Sokolovsky pmis...@gmail.com 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

Re: [Python-Dev] PEP 451 update

On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan ncogh...@gmail.com wrote: On 31 Oct 2013 18:52, Eric Snow ericsnowcurren...@gmail.com wrote: On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan ncogh...@gmail.com wrote: There's also the option of implementing the constraint directly in the finder,

Re: [Python-Dev] PEP 451 update

On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] PEP 451 update

On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote: On 28 Oct 2013 02:37, PJ Eby p...@telecommunity.com wrote: On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com wrote: Now, regarding the signature of exec_module(): I'm back to believing that loaders

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*

Re: [Python-Dev] PEP 451 update

On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon br...@python.org wrote: On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com 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

Re: [Python-Dev] PEP 451 update

On Fri, Oct 25, 2013 at 3:15 PM, Brett Cannon br...@python.org wrote: On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby p...@telecommunity.com wrote: On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon br...@python.org wrote: On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com wrote: At least

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

On Tue, Oct 15, 2013 at 8:57 AM, Nick Coghlan ncogh...@gmail.com 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,

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

On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou solip...@pitrou.net 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

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

On Sun, Oct 13, 2013 at 1:58 PM, Alexander Belopolsky alexander.belopol...@gmail.com 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

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

On Fri, Sep 20, 2013 at 9:54 AM, Jesus Cea j...@jcea.es 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

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

On Fri, Aug 23, 2013 at 4:50 AM, Stefan Behnel stefan...@behnel.de 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

Re: [Python-Dev] Classes with ordered namespaces

On Thu, Jun 27, 2013 at 4:48 AM, Nick Coghlan ncogh...@gmail.com 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

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

On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam ron3...@gmail.com 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] doctest and pickle

On Fri, Jun 7, 2013 at 1:54 PM, Mark Janssen dreamingforw...@gmail.com wrote: On Fri, Jun 7, 2013 at 10:50 AM, Mark Janssen dreamingforw...@gmail.com wrote: from pickle import dumps, loads Fruit.tomato is loads(dumps(Fruit.tomato)) True Why are you using is here instead of

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

On Fri, Jun 7, 2013 at 10:27 AM, Thomas Wouters tho...@python.org 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

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

On Fri, Jun 7, 2013 at 5:16 PM, Łukasz Langa luk...@langa.pl wrote: On 7 cze 2013, at 22:50, PJ Eby p...@telecommunity.com wrote: On Fri, Jun 7, 2013 at 10:27 AM, Thomas Wouters tho...@python.org wrote: This isn't a new bug, but it's exposed by always importing weakref and atexit during

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

On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen ro...@uw.edu 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

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

On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa luk...@langa.pl 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

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

On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan ncogh...@gmail.com 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

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

On Sat, May 25, 2013 at 9:18 AM, Antoine Pitrou solip...@pitrou.net 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

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

On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa luk...@langa.pl 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:

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

On Thu, May 23, 2013 at 11:57 PM, Nick Coghlan ncogh...@gmail.com 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

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

On Thu, May 23, 2013 at 11:11 AM, Paul Moore p.f.mo...@gmail.com 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

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

On Thu, May 23, 2013 at 2:59 PM, PJ Eby p...@telecommunity.com 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

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

On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt benh...@gmail.com 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

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

On Mon, May 6, 2013 at 4:46 AM, Armin Rigo ar...@tunes.org 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

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

On Sun, Apr 28, 2013 at 7:37 PM, Steven D'Aprano st...@pearwood.info 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:

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

On Sat, Apr 27, 2013 at 2:27 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] relative import circular problem

On Thu, Apr 4, 2013 at 11:17 AM, Guido van Rossum gu...@python.org 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

Re: [Python-Dev] relative import circular problem

On Thu, Apr 4, 2013 at 4:42 PM, Guido van Rossum gu...@python.org 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

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

On Thu, Mar 28, 2013 at 6:43 AM, Rocky Bernstein ro...@gnu.org 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

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

On Wed, Mar 27, 2013 at 5:19 PM, Bradley M. Froehle brad.froe...@gmail.com 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

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

On Tue, Mar 26, 2013 at 11:00 PM, Rocky Bernstein ro...@gnu.org 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

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

On Sun, Mar 3, 2013 at 12:31 PM, Brett Cannon br...@python.org 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

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 m...@egenix.com 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

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 ncogh...@gmail.com 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

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

On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum gu...@python.org 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

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

On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan ncogh...@gmail.com 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

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

On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel stefan...@behnel.de 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

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 stefan...@behnel.de 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

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

On Sun, Feb 3, 2013 at 8:08 AM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] Accessing value stack

On Mon, Jan 7, 2013 at 11:32 AM, Brett Cannon br...@python.org wrote: On Mon, Jan 7, 2013 at 10:46 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman p...@phdru.name wrote: On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek dim...@gmail.com wrote:

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

On Wed, Dec 12, 2012 at 3:37 PM, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote: On 12/12/2012 01:15 AM, Nick Coghlan wrote: On Wed, Dec 12, 2012 at 5:37 AM, Dino Viehland di...@microsoft.com mailto:di...@microsoft.com wrote: OTOH changing certain dictionaries in IronPython (such

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

On Wed, Dec 12, 2012 at 5:06 PM, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no 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

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

On Mon, Dec 10, 2012 at 10:48 AM, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 10 Dec 2012 10:40:30 +0100, Armin Rigo ar...@tunes.org a écrit : Hi Raymond, On Mon, Dec 10, 2012 at 2:44 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: Instead, the data should be organized as

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

On Sun, Dec 9, 2012 at 10:38 PM, Andrew McNabb amcn...@mcnabbs.org 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 informed of. If one

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

On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull step...@xemacs.org 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 of prior assumptions. Not my ownwink

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

On Mon, Dec 10, 2012 at 1:01 PM, Armin Rigo ar...@tunes.org wrote: On Mon, Dec 10, 2012 at 5:16 PM, PJ Eby p...@telecommunity.com 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

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

On Mon, Dec 10, 2012 at 4:29 PM, Tim Delaney tim.dela...@aptare.com 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*.

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

On Mon, Dec 10, 2012 at 5:14 PM, Andrew Svetlov andrew.svet...@gmail.com wrote: Please, no. dict and kwargs should be unordered without any assumptions. Why? ___ Python-Dev mailing list Python-Dev@python.org

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

On Sun, Dec 9, 2012 at 12:54 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby p...@telecommunity.com wrote: On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com wrote: So

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

On Sun, Dec 9, 2012 at 8:48 PM, Stephen J. Turnbull step...@xemacs.org 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 reflect the *results

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

On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com wrote: So if package A includes a Conflicts: B declaration, I recommend the following: * An attempt to install A with B already present refuses to install

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

On Sat, Dec 8, 2012 at 10:22 PM, MRAB pyt...@mrabarnett.plus.com 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

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

On Fri, Dec 7, 2012 at 12:01 PM, Toshio Kuratomi a.bad...@gmail.com 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 a.bad...@gmail.com wrote: On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote: Nobody has actually proposed

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

On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan ncogh...@gmail.com 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,

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

On Thu, Dec 6, 2012 at 8:39 AM, Daniel Holth dho...@gmail.com 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

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

On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Daniel Holth dholth at 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

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

On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi a.bad...@gmail.com 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 donald.stu...@gmail.com wrote: Nobody has actually proposed a better one, outside of package renaming

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

On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft donald.stu...@gmail.com 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

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

On Wed, Dec 5, 2012 at 5:30 PM, Daniel Holth dho...@gmail.com 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

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

On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft donald.stu...@gmail.com 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

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

On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth dho...@gmail.com 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?

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

On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote: 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

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

On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman v+pyt...@g.nevcal.comwrote: 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 more accurate

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

On Tue, Nov 20, 2012 at 5:01 PM, Daniel Holth dho...@gmail.com 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

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

On Tue, Nov 20, 2012 at 6:43 PM, Daniel Holth dho...@gmail.com 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.

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

On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull step...@xemacs.orgwrote: 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

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

On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth dho...@gmail.com 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

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

On Sat, Aug 11, 2012 at 8:03 PM, Brett Cannon br...@python.org 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

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

On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum gu...@python.org 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__')

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

On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore p.f.mo...@gmail.com 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

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

On Sun, Jun 24, 2012 at 3:51 AM, Martin v. Löwis mar...@v.loewis.dewrote: 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

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

On Sun, Jun 24, 2012 at 3:27 PM, Martin v. Löwis mar...@v.loewis.dewrote: 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

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 Coghlanncogh...@gmail.com wrote: distutils really only plays at the SRPM level - there is no defined OS neutral RPM equivalent.

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

On Wed, Jun 20, 2012 at 11:57 PM, Nick Coghlan ncogh...@gmail.com 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

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

On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com 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:

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

On Jun 21, 2012 10:12 AM, Chris McDonough chr...@plope.com 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

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

On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough chr...@plope.com wrote: On 06/21/2012 11:37 AM, PJ Eby wrote: On Jun 21, 2012 11:02 AM, Zooko Wilcox-Oapos;Hearn zo...@zooko.com mailto:zo...@zooko.com wrote: Philip J. Eby provisionally approved of one of the patches, except

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

On Thu, Jun 21, 2012 at 1:20 PM, Tarek Ziadé ta...@ziade.org 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

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

On Thu, Jun 21, 2012 at 10:08 AM, Daniel Braniss da...@cs.huji.ac.ilwrote: On Thu, 21 Jun 2012 13:17:01 +0300 Daniel Braniss da...@cs.huji.ac.il wrote: Hi, when lib/python/site-packages/ is accessed via NFS, open/stat/access is very expensive/slow. A simple solution is to use

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

On Thu, Jun 21, 2012 at 4:01 PM, Paul Moore p.f.mo...@gmail.com 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,

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

On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote: Agreed, especially if the proven in the wild criterion is required (people won't rush to another third-party distutils replacement, IMHO). The

Re: [Python-Dev] PEP 362: 4th edition

On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray rdmur...@bitdance.comwrote: On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner victor.stin...@gmail.com wrote: 1. Should we keep 'Parameter.implemented' or not. *Please vote* -1 to implemented. I still disagree with the deepcopy. I read

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy jdha...@gmail.com wrote: On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow ericsnowcurren...@gmail.com wrote: Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is

  1   2   >