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
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 t
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
simpl
>> 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
-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 o
>> 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.
-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.*,
.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
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.
-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, o
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 Wor
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.*, buildo
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
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 under
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
>> 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,
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.
>
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)?
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 starti
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 c
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.
-
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 r
22 matches
Mail list logo
