Re: [Python-Dev] PEP 382: Namespace Packages
P.J. Eby wrote: I didn't say there's *no* desire, however IIRC the only person who *ever* asked on distutils-sig how to do a base package with setuptools was the author of the ll.* packages. I've asked before ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
Martin v. Löwis wrote: I, for one, have been trying to figure out how to do "base namespace" packages for years... You mean, without PEP 382? That won't be possible, unless you can coordinate all addon packages. Base packages are a feature solely of PEP 382. Marc-Andre has achieved this, I think, without the PEP, but I never really understood how :-S Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: little help for stupid people?
Martin v. Löwis wrote: Ok, so create three tar files: 1. base.tar, containing simplistix/ simplistix/__init__.py So this __init__.py can have code in it? And base.tar can have other modules and subpackages in it? What happens if the base and an addon both define a package called simplistix.somepackage? 2. addon1.tar, containing simplistix/addon1.pth (containing a single "*") What does that * mean? I thought .pth files just had python in them? Unpack each of them anywhere on sys.path, in any order. How would this work if base, addon1 and addon2 were eggs managed by buildout or setuptools? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: little help for stupid people?
>> Ok, so create three tar files: >> >> 1. base.tar, containing >> >>simplistix/ >>simplistix/__init__.py > > So this __init__.py can have code in it? That's the point, yes. > And base.tar can have other modules and subpackages in it? Certainly, yes. > What happens if the base and an addon both define a package called > simplistix.somepackage? Depends on whether simplistix.somepackage is a namespace package (it should). If so, they get merged just as any other namespace package. >> 2. addon1.tar, containing >> >>simplistix/addon1.pth (containing a single "*") > > What does that * mean? See PEP 382 (search for "*"). > I thought .pth files just had python in them? Not at all - they never did. They have paths in them. >> Unpack each of them anywhere on sys.path, in any order. > > How would this work if base, addon1 and addon2 were eggs managed by > buildout or setuptools? What is a managed egg (i.e. what kind of management does buildout or setuptools apply to it)? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
-On [20090501 20:59], "Martin v. Löwis" ([email protected]) wrote: >Right: if all portions install into the same directory, you can have >base packages already. Speaking as a user of packages, this use case is one I hardly ever encounter with the Python software/modules/packages I use. The only ones that spring to mind are the mx.* and ll.* packages. The rest simply create their own namespace as .*, but there's nothing that uses that same namespace and installs separately from the base package that I know of. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Knowledge was inherent in all things. The world was a library... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
>> Right: if all portions install into the same directory, you can have >> base packages already. > > Speaking as a user of packages, this use case is one I hardly ever encounter > with the Python software/modules/packages I use. The only ones that spring > to mind are the mx.* and ll.* packages. The rest simply create their own > namespace as .*, but there's nothing that uses that same namespace > and installs separately from the base package that I know of. There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*, plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*, xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*, themerubber.*, themetweaker.*, zc.*, z3c.*, zgeo.*, z3ext.*, etc. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
-On [20090509 13:40], "Martin v. Löwis" ([email protected]) wrote: >There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*, >plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*, >xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*, >themerubber.*, themetweaker.*, zc.*, z3c.*, zgeo.*, z3ext.*, etc. Can be fairly said, though, that the majority of those you just named are related to Zope? That would explain why I won't know of them as I avoid Zope like the plague. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Hope is a letter that never arrives, delivered by the postman of my fear... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pth files are evil
.pth files are why I can't easily use GNU stow with easy_install. If installing a Python package involved writing new files into the filesystem, but did not require reading, updating, and re-writing any extant files such as .pth files, then GNU stow would Just Work with easy_install the way it Just Works with most things. Regards, Zooko ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: little help for stupid people?
Martin v. Löwis wrote: So this __init__.py can have code in it? That's the point, yes. And base.tar can have other modules and subpackages in it? Certainly, yes. Great, when is the PEP due to land in 2.x? ;-) What happens if the base and an addon both define a package called simplistix.somepackage? Depends on whether simplistix.somepackage is a namespace package (it should). If so, they get merged just as any other namespace package. Sorry, I was looking at potential bug cases here. What happens if it's not a namespace package? See PEP 382 (search for "*"). I thought .pth files just had python in them? Not at all - they never did. They have paths in them. I've certainly seen them with python in, and that's what I hate about them... Unpack each of them anywhere on sys.path, in any order. How would this work if base, addon1 and addon2 were eggs managed by buildout or setuptools? What is a managed egg (i.e. what kind of management does buildout or setuptools apply to it)? Sorry, bad wording on my part... I guess I meant more how would buildout/setuptools go about installing/uninstalling/etc packages thatconform to PEP 382? Would setuptools/buildout need modification or would the changes take effect lower down in the stack? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
-On [20090509 16:07], Chris Withers ([email protected]) wrote: >They're also all pure namespace packages rather than base + addons, >which is what we've been discussing... But from Martin's email I understood it more as being base packages. Unless I misunderstood, of course. If correct, which is it? >More fool you... Maybe, used/worked with it and don't care for it one iota. But that's a whole different discussion. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Naritai jibun wo surikaetemo egao wa itsudemo suteki desuka... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pth files are evil
Zooko O'Whielacronx wrote: > .pth files are why I can't easily use GNU stow with easy_install. > If installing a Python package involved writing new files into the > filesystem, but did not require reading, updating, and re-writing any > extant files such as .pth files, then GNU stow would Just Work with > easy_install the way it Just Works with most things. Please understand that this is the fault of easy_install, not of .pth files. There is no technical need for easy_install to rewrite .pth files on installation. It could just as well have created new .pth files, rather than modifying existing ones. If you always use --single-version-externally-managed with easy_install, it will stop editing .pth files on installation. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
Jeroen Ruigrok van der Werven wrote: -On [20090509 13:40], "Martin v. Löwis" ([email protected]) wrote: There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*, plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*, xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*, themerubber.*, themetweaker.*, zc.*, z3c.*, zgeo.*, z3ext.*, etc. Can be fairly said, though, that the majority of those you just named are related to Zope? They're also all pure namespace packages rather than base + addons, which is what we've been discussing... That would explain why I won't know of them as I avoid Zope like the plague. More fool you... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: little help for stupid people?
Chris Withers wrote: > Martin v. Löwis wrote: >>> So this __init__.py can have code in it? >> >> That's the point, yes. >> >>> And base.tar can have other modules and subpackages in it? >> >> Certainly, yes. > > Great, when is the PEP due to land in 2.x? ;-) Most likely, never - it probably will be implemented only after the last feature release of 2.x was made. >>> What happens if the base and an addon both define a package called >>> simplistix.somepackage? >> >> Depends on whether simplistix.somepackage is a namespace package >> (it should). If so, they get merged just as any other namespace >> package. > > Sorry, I was looking at potential bug cases here. What happens if it's > not a namespace package? Then it will be imported as a regular child package. Unpack each of them anywhere on sys.path, in any order. >>> How would this work if base, addon1 and addon2 were eggs managed by >>> buildout or setuptools? >> >> What is a managed egg (i.e. what kind of management does buildout >> or setuptools apply to it)? > > Sorry, bad wording on my part... I guess I meant more how would > buildout/setuptools go about installing/uninstalling/etc packages > thatconform to PEP 382? Would setuptools/buildout need modification or > would the changes take effect lower down in the stack? Unfortunately, I don't know precisely what they do, so I don't know whether any of it needs modification. All I can say is that if they want to install namespace packages using the mechanism of PEP 382, they will have to produce the file layout specified in the PEP. For distutils (which is the only library in that area that I do know), I think just installing any .pth files inside a package would be sufficient. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
Jeroen Ruigrok van der Werven wrote: > -On [20090509 16:07], Chris Withers ([email protected]) wrote: >> They're also all pure namespace packages rather than base + addons, >> which is what we've been discussing... > > But from Martin's email I understood it more as being base packages. Unless > I misunderstood, of course. > > If correct, which is it? The list I gave you was a list of distributions that include namespace packages (using the setuptools mechanism). I don't think that any of them has the notion of a base package, as the setuptools mechanism doesn't support base packages. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pth files are evil
At 04:18 PM 5/9/2009 +0200, Martin v. Löwis wrote: Zooko O'Whielacronx wrote: > .pth files are why I can't easily use GNU stow with easy_install. > If installing a Python package involved writing new files into the > filesystem, but did not require reading, updating, and re-writing any > extant files such as .pth files, then GNU stow would Just Work with > easy_install the way it Just Works with most things. Please understand that this is the fault of easy_install, not of .pth files. There is no technical need for easy_install to rewrite .pth files on installation. It could just as well have created new .pth files, rather than modifying existing ones. If you always use --single-version-externally-managed with easy_install, it will stop editing .pth files on installation. It's --multi-version (-m) that does that. --single-version-externally-managed is a "setup.py install" option. Both have the effect of not editing .pth files, but they do so in different ways. The "setup.py install" option causes it to install in a distutils-compatible layout, whereas --multi-version simply drops .egg files or directories in the target location and leaves it to the user (or the generated script wrappers) to add them to sys.path. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pth files are evil
>> If you always use --single-version-externally-managed with easy_install, >> it will stop editing .pth files on installation. > > It's --multi-version (-m) that does that. > --single-version-externally-managed is a "setup.py install" option. > > Both have the effect of not editing .pth files, but they do so in > different ways. The "setup.py install" option causes it to install in a > distutils-compatible layout, whereas --multi-version simply drops .egg > files or directories in the target location and leaves it to the user > (or the generated script wrappers) to add them to sys.path. Ah, ok. Is there also an easy_install invocation that unpacks the zip file into some location of sys.path (which then wouldn't require editing sys.path)? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pth files are evil
At 04:42 PM 5/9/2009 +0200, Martin v. Löwis wrote: >> If you always use --single-version-externally-managed with easy_install, >> it will stop editing .pth files on installation. > > It's --multi-version (-m) that does that. > --single-version-externally-managed is a "setup.py install" option. > > Both have the effect of not editing .pth files, but they do so in > different ways. The "setup.py install" option causes it to install in a > distutils-compatible layout, whereas --multi-version simply drops .egg > files or directories in the target location and leaves it to the user > (or the generated script wrappers) to add them to sys.path. Ah, ok. Is there also an easy_install invocation that unpacks the zip file into some location of sys.path (which then wouldn't require editing sys.path)? Not as yet. I'm sort of waiting to see what comes out of PEP 376 discussions re: an installation manifest... but then, if I actually had time to work on it right now, I'd probably just implement something. Currently, you can use pip to do that, though, as long as the packages you want are in source form. pip doesn't unzip eggs as yet. It would be really straightforward, though, for someone to implement an easy_install variant that does this. Just invoke "easy_install -Zmaxd /some/tmpdir packagelist" to get a full set of unpacked .egg directories in /some/tmpdir, and then move the contents of the resulting .egg subdirs to the target location, renaming EGG-INFO subdirs to projectname-version.egg-info subdirs. (Of course, this ignores the issue of uninstalling previous versions, or overwriting of conflicting files in the target -- does pip handle these?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] special method lookup: how much do we care?
2009/5/9 Terry Reedy : > Benjamin Peterson wrote: > > __reduce__ > __setstate__ > __reversed__ > __length_hint__ > __sizeof__ > >> No, it's easier to just use _PyObject_LookupSpecial there. > > Does that mean that the above 5 'work correctly' (or can easily be made to > do so)? Leaving just __entry__ and __exit__ as problems? Yes, __enter__ and __exit__ are the tricky ones. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: little help for stupid people?
2009/5/9 Chris Withers : > Martin v. Löwis wrote: >>> I thought .pth files just had python in them? >> >> Not at all - they never did. They have paths in them. > > I've certainly seen them with python in, and that's what I hate about > them... AIUI, there was a small special case that lines starting with "import" are executed (see the source of site.py for details). This exception has been exploited (some would say "abused", but I'm trying to be unbiased here) by setuptools, at least, to do path manipulations and such. PEP 382 does not provide the import exception: "Unlike .pth files on the top level, lines starting with "import" are not supported in per-package .pth files". It's not clear to me what impact this would have on setuptools (probably none, as top-level .pth files aren't changed). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] special method lookup: how much do we care?
Benjamin Peterson schrieb: > A while ago, Guido declared that all special method lookups on > new-style classes bypass __getattr__ and __getattribute__. This almost > completely consistent now, and I've been working on patching up a few > incorrect cases. I've know hit __enter__ and __exit__. The compiler > generates LOAD_ATTR instructions for these, so it uses the normal > lookup. The only way I can see to fix this is add a new opcode which > uses _PyObject_LookupSpecial, but I don't think we really care this > much. Opinions? It's easier to introduce a separate opcode like SETUP_WITH; the compilation of a with statement produces quite a lot of bytecode which could be made more efficient that way. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] special method lookup: how much do we care?
Are we solving an actual problem by changing the behaviour here, or is it just a case of foolish consistency? Seems to me that trying to pin down exactly what constitutes a "special method" is a fool's errand, especially if you want it to include __enter__ and __exit__ but not __reduce__, etc. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] special method lookup: how much do we care?
2009/5/9 Greg Ewing : > Are we solving an actual problem by changing the > behaviour here, or is it just a case of foolish > consistency? "No implementation detail is obscure enough." For example, Maciek Fijalkowski of PyPy told me that he cares about this because someone is bound to eventually rely on it, and PyPy will have to follow CPython. > > Seems to me that trying to pin down exactly what > constitutes a "special method" is a fool's errand, > especially if you want it to include __enter__ and > __exit__ but not __reduce__, etc. IMO, if it's a callable that begins with __ and ends with __, it's a special method. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
