[py-dev] Re: Error with py.test and scipy ...

[holger krekel]

Hi Paul, 

On Fri, Apr 08, 2005 at 13:43 +0100, Paul Moore wrote:
> On Apr 8, 2005 1:28 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> 
> > I wonder if people are overloading the idea of "module" when really they
> > want to create entirely new kinds of objects-built-from-Python-files
> > that aren't modules at all.  Do we need a new metaphor?  Do we need one
> > Magic But Really Well Spec'ed import hook that will satisfy everyone's
> > needs?
> 
> PEP 302 was intended to unify the import hook landscape, and make it
> easier for hooks to work together. My impression is that it failed,
> but I'm not sure why. My name is on the PEP, but I really only did
> documentation, testing, and a little bit of design. Most of the good
> stuff was Just's.
> 
> I'd like to think that "tidying up" PEP 302 would solve the issues,
> but I don't really have a good use case - my interest was with regard
> to zip imports, and the sort of areas that eggs are addressing, but I
> was looking forward to a situation where PEP 302 hooks were
> established, and there would be no need to cater for custom
> approaches. Sadly, I no longer see that day approaching :-(

It's a really tough problem by now because the pile of import
hacks just keeps growing.  Probably we will need to lock  
the kinds of Tim Peters, Just van Rossum and Samuele Pedroni
into some cathedral and wait until white smoke comes out of
the chimney. 

> An immediate question springs to mind - what is the py magic doing,
> and how does PEP 302 fail to cater for its needs? (Repeat this
> question for any other package with nasty import magic).

The py lib aims at compatibility with 2.2 upwards, so 
PEP 302 cannot really help much, even less so modifications
to python-cvs at this point.  Armin and me always had
the feeling that PEP 302 could be used to cater for our needs, 
but never got around to thinking it through ... (for me, mainly 
the first issue kept me from having serious interest). 

FWIW, i think it is hampering Python development that
the "standard library" only advances with major python 
releases.  However, we begin to have the pieces in hand to head
towards a more distributed approach of "batteries development". 
For me, the deployment/distribution/packaging/importing aspects 
seem like the single most deficient concepts with Python right now. 
(Everything else requires PyPy, anyway :-). 

cheers, 

    holger