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?
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
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
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
-On [20090501 20:59], Martin v. Löwis (mar...@v.loewis.de) 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
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
-On [20090509 13:40], Martin v. Löwis (mar...@v.loewis.de) 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
.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
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
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) 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
Jeroen Ruigrok van der Werven wrote:
-On [20090509 13:40], Martin v. Löwis (mar...@v.loewis.de) wrote:
There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*, silva
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
Jeroen Ruigrok van der Werven wrote:
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) 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
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, but they
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
2009/5/9 Terry Reedy tjre...@udel.edu:
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
2009/5/9 Chris Withers ch...@simplistix.co.uk:
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
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
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 greg.ew...@canterbury.ac.nz:
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
22 matches
Mail list logo
