Re: [Python-Dev] Playing with a new theme for the docs

On Mar 21, 2012 12:00 PM, "Guido van Rossum" wrote: > > On Mar 21, 2012 5:44 AM, "Ned Batchelder" wrote: > > The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. > > Please, no, not even this "i

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

On Mar 22, 2012 2:57 PM, "VanL" wrote: > That said, while I think that the above is a good idea, my personal ambitions are more modest: If the names of the top-level directories only were changed to 'bin', 'lib', and 'include' - never mind differences under 'lib' - I would be happy. In fact, even

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

On Mar 23, 2012 1:37 PM, "VanL" wrote: > > On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote: >> >> Even if you are using tools that don't use distutils' configuration settings for these directories, why not simply fix those tools so that they do? > >

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

On Mar 23, 2012 4:19 PM, "VanL" wrote: > > Three notes. FIrst, distutils.cfg doesn't always work because it is centered around the idea of set paths that are the same each time - which doesn't always work with virtualenvs. And the virtualenv doesn't contain its own copy of distutils.cfg? > Secon

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

On Mar 23, 2012 3:53 PM, "Carl Meyer" wrote: > > Hi PJ, > > On 03/23/2012 12:35 PM, PJ Eby wrote: > > AFAICT, virtualenvs are overkill for most development anyway. If you're > > not using distutils except to install dependencies, then configure > >

Re: [Python-Dev] Playing with a new theme for the docs

On Mar 23, 2012 9:16 PM, "Greg Ewing" wrote: > > Glyph Lefkowitz wrote: > >> "do I have to resize my browser every time I visit a new site to get a decent width for reading". > > > If all sites left the width to the browser, then I would > be able to make my browser window a width that is comforta

Re: [Python-Dev] Playing with a new theme for the docs

On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing wrote: > PJ Eby wrote: > > Weird - I have the exact *opposite* problem, where I have to resize my >> window because somebody *didn't* set their text max-width sanely (to a >> reasonable value based on ems instead of pixel

Re: [Python-Dev] Playing with a new theme for the docs

On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull wrote: > But since he's arguing the > other end in the directory layout thread (where he says there are many > special ways to invoke Python so that having different layouts on > different platforms is easy to work around), I can't give much wei

Re: [Python-Dev] Playing with a new theme for the docs

On Sat, Mar 24, 2012 at 8:41 PM, Ben Finney wrote: > PJ Eby writes: > > > On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing >wrote: > > > > > If you don't want 1920-pixel-wide text, why make your browser window > > > that large? > > > > Not ev

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer wrote: > No disagreement here. I think virtualenv's sweet spot is as a convenient > tool for development environments (used in virtualenvwrapper fashion, > where the file structure of the virtualenv itself is hidden away and you > never see it at all).

Re: [Python-Dev] Playing with a new theme for the docs

On Mon, Mar 26, 2012 at 11:23 PM, Stephen J. Turnbull wrote: > On Tue, Mar 27, 2012 at 1:35 AM, PJ Eby wrote: > > On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull > > > wrote: > >> > >> But since he's arguing the > >> other end in the dir

Re: [Python-Dev] OT: single directory development [was Re: Playing with a new theme for the docs]

On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman wrote: > PJ Eby wrote: > >> Really? I've been doing "dump the app in a directory" since 1998 or so >> on various *nix platforms. And when distutils came along, I set up a >> user-specific cfg to instal

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote: > > More details why it's hard to define such function and why I dropped > it from the PEP. > > If someone wants to propose again such function ("monotonic or > fallback to system" clock), two issues should be solved: > > - name of the function > -

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson wrote: > On 04Apr2012 22:23, PJ Eby wrote: > | On Apr 4, 2012 7:28 PM, "Victor Stinner" > wrote: > | > More details why it's hard to define such function and why I dropped > | > it from the PEP. > | > &g

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner wrote: > 2012/4/5 PJ Eby : > >> More details why it's hard to define such function and why I dropped > >> it from the PEP. > >> > >> If someone wants to propose again such function ("monotonic or >

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum wrote: > Depending on the polling frequency sounds like a bad idea, since you > can't know that you're the only user of the clock. Also depending on > the use case, too short a timeout may be worse than too long a > timeout. Given a small enough

Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation

(Sorry I'm so late to this discussion.) I think that it's important to take into account the fact that PEP 3115 doesn't require namespaces to implement anything more than __setitem__ and __getitem__ (with the latter not even needing to do anything but raise KeyError). Among other things, this mea

Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation

On Sat, Apr 21, 2012 at 11:30 AM, Nick Coghlan wrote: > On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby wrote: > > Personally, I think __build_class__ should be explicitly exposed and > > supported, if for no other reason than that it allows one to re-implement > > old-style __met

Re: [Python-Dev] package imports, sys.path and os.chdir()

On Sat, Apr 28, 2012 at 12:16 PM, R. David Murray wrote: > That said, could this insertion of '' only happen when the interactive > prompt is actually posted, and otherwise use cwd? > That's already the case. Actually, sys.path[0] is *always* the absolute path of the script directory -- regardle

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum wrote: > Ah, I see. But I disagree that this is a reasonable constraint on > sys.path. The magic __path__ object of a toplevel namespace module > should know it is a toplevel module, and explicitly refetch sys.path > rather than just keeping aroun

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Mon, May 21, 2012 at 8:32 PM, Eric V. Smith wrote: > Any reason to make this the string "sys" or "foo", and not the module > itself? Can the module be replaced in sys.modules? Mostly I'm just curious. > Probably not, but it occurred to me that storing references to modules introduces a refere

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 12:31 PM, Eric V. Smith wrote: > On 05/22/2012 11:39 AM, Nick Coghlan wrote: > > Oops, I also meant to say that it's probably worth at least issuing > > ImportWarning if a new portion with an __init__.py gets added - it's > > going to block all future dynamic updates of th

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 8:40 PM, Eric V. Smith wrote: > On 5/22/2012 2:37 PM, Guido van Rossum wrote: > > Okay, I've been convinced that keeping the dynamic path feature is a > > good idea. I am really looking forward to seeing the rationale added > > to the PEP -- that's pretty much the last thi

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 9:58 PM, Nick Coghlan wrote: > If you wanted to do this without changing the sys.meta_path hook API, > you'd have to pass an object to find_module() that did the dynamic > lookup of the value in obj.__iter__. Something like: > >class _LazyPath: >def __init__(se

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On May 23, 2012 9:02 AM, "Nick Coghlan" wrote: > > On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith wrote: > > On 05/22/2012 09:49 PM, PJ Eby wrote: > >> It shouldn't - all you should need is to use > >> getattr(sys.modules[self.modname], self.at

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 3:02 PM, Brett Cannon wrote: > If I understand the proposal correctly, this would be a change in > NamespaceLoader in how it sets __path__ and in no way affect any other code > since __import__() just grabs the object on __path__ and passes as an > argument to the meta pat

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 8:24 PM, Eric V. Smith wrote: > I tried this approach and it works fine. The only caveat is that it > assumes that the parent path can always be computed as described above, > independent of what's passed in to PathFinder.load_module(). I think > that's reasonable, since l

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 9:02 PM, Eric V. Smith wrote: > On 5/23/2012 8:58 PM, PJ Eby wrote: > > On Wed, May 23, 2012 at 8:24 PM, Eric V. Smith > <mailto:e...@trueblade.com>> wrote: > > > > I tried this approach and it works fine. The only caveat is that i

Re: [Python-Dev] Language reference updated for metaclasses

On Sun, May 20, 2012 at 4:38 AM, Nick Coghlan wrote: > When writing the docs for types.new_class(), I discovered that the > description of the class creation process in the language reference > was not only hard to follow, it was actually *incorrect* when it came > to describing the algorithm for

Re: [Python-Dev] Language reference updated for metaclasses

On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan wrote: > It's actually the pre-decoration class, since the cell is initialised > before the class is passed to the first decorator. I agree it's a little > weird, but I did try to describe it accurately in the new docs. > I see that now; it might be he

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan wrote: > On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote: > > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan wrote: > >> > >> It's actually the pre-decoration class, since the cell is initialised > >> before the

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Mon, Jun 4, 2012 at 10:25 PM, Nick Coghlan wrote: > On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby wrote: > > On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan wrote: > >> > >> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote: > >> > On Mon, Jun 4,

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Mon, Jun 4, 2012 at 10:43 PM, Eric Snow wrote: > On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby wrote: > > I mean that class-level __metaclass__ is no longer supported as of PEP > 3115, > > so I can't use that as a way to non-invasively obtain the enclosing > class

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 3:53 AM, Nick Coghlan wrote: > Please don't try to coerce everyone else into supporting such an ugly > hack by abusing an implementation detail. Whoa, whoa there. Again with the FUD. Sorry if I gave the impression that I'm about to unleash the monkeypatching hordes tomo

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy wrote: > On 6/5/2012 8:09 AM, nick.coghlan wrote: > >Add PEP 422: Dynamic Class Decorators >> > > +Iterating over decorator entries in reverse order >> +-** >> + >> +This order was chosen to match th

Re: [Python-Dev] [Python-checkins] peps: Add PEP 422: Dynamic Class Decorators

On Tue, Jun 5, 2012 at 5:31 PM, Terry Reedy wrote: > On 6/5/2012 2:26 PM, PJ Eby wrote: > >> On Tue, Jun 5, 2012 at 12:42 PM, Terry Reedy > <mailto:tjre...@udel.edu>> wrote: >> > > I think you should just store the decorators in the correct order of

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan wrote: > On reflection, I'm actually inclined to agree. The next version of the > PEP will propose the addition of type.__decorate__(). This new method > will be invoked *after* the class is created and the __class__ cell is > populated, but *before* l

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

On Wed, Jun 6, 2012 at 5:31 AM, Nick Coghlan wrote: > On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan wrote: > > On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby wrote: > >> To be clear, what I specifically proposed (as I mentioned in an earlier > >> thread) was simply to patch

Re: [Python-Dev] [Python-checkins] peps: PEP 422 rewrite to present an idea that a) isn't crazy and b) it turns out

+1 on the PEP. FWIW, it may be useful to note that not only has the pattern of having a class-level init been proposed before, it's actually used: Zope has had __class_init__ and used it as a metaclass alternative since well before Thomas Heller's proposal. And in my case, about 80% of my non-dyn

Re: [Python-Dev] [Python-checkins] peps: PEP 422 rewrite to present an idea that a) isn't crazy and b) it turns out

On Wed, Jun 6, 2012 at 6:07 PM, Eric Snow wrote: > On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan > wrote: > > + > > +Alternatives > > + > > + > > Would it be worth also (briefly) rehashing why the class instance > couldn't be created before the class body is executed*? It might seem >

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

On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy wrote: > On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow > 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 how closely the various implementors

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

On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray wrote: > 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 somewhere

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

On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou > wrote: > > Agreed, especially if the "proven in the wild" criterion is required > > (people won't rush to another third-party distutils replacement, IMHO). > > The existence of setuptools mea

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

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

<    1   2