pydispatcher-devel

[Pydispatcher-devel] 'dispatch' naming clash

[Stephen W. <go...@co...>]

Mike,

You may be aware that Phillip Eby's PEAK package has a
sub-package called 'dispatch', which unfortunately (and,
IMO, rather arrogantly ;) PEAK installs into the
top-level site-packages namespace.  So, since I already
had PEAK installed when I installed PyDispatcher, I
did an 'import dispatch' and 'help(dispatch)' and was
completely astonished at the result until I realized
it was coming from PEAK's dispatch package.

Anyway, I realize that may or may not have practical
consequences, but it does make me uncomfortable.  I need
both PEAK and PyDispatch in my application, so I was
wondering if anyone had tried that and, if so, whether
they had experienced anything untoward.

If no one here has tried it, I'll contact Phillip Eby
and see if it would break anything in PEAK if I just
delete his dispatch package.  (Actually, all I'm using
from PEAK is his XMI stuff, so as long as it doesn't
break *that* I'm okay -- I couldn't care less about the
rest of PEAK! ;).

Cheers,
Steve

Re: [Pydispatcher-devel] 'dispatch' naming clash

[Mike C. F. <mcf...@ro...>]

Stephen Waterbury wrote:

> Mike,
>
> You may be aware that Phillip Eby's PEAK package has a
> sub-package called 'dispatch', which unfortunately (and,
> IMO, rather arrogantly ;) PEAK installs into the
> top-level site-packages namespace.  So, since I already
> had PEAK installed when I installed PyDispatcher, I
> did an 'import dispatch' and 'help(dispatch)' and was
> completely astonished at the result until I realized
> it was coming from PEAK's dispatch package.

Have never actually used or installed PEAK (though I did plumb through 
it's code looking for metaclass examples for a talk once), so no, wasn't 
aware of it.

> Anyway, I realize that may or may not have practical
> consequences, but it does make me uncomfortable.  I need
> both PEAK and PyDispatch in my application, so I was
> wondering if anyone had tried that and, if so, whether
> they had experienced anything untoward.

Given that no-one has complained to Phillip yet (to my knowledge, backed 
up by the fact that it's still there), probably not ;) .

That said, as long as PEAK's module doesn't overwrite any of the modules 
in the PyDispatcher package (and as long as importing it's __init__.py 
doesn't completely kark up the object model in some inventive and evil 
way (this being PEAK, after all)), you should be able to continue using 
PyDispatcher... in other words, our __init__ file doesn't do anything 
special.

> If no one here has tried it, I'll contact Phillip Eby
> and see if it would break anything in PEAK if I just
> delete his dispatch package.  (Actually, all I'm using
> from PEAK is his XMI stuff, so as long as it doesn't
> break *that* I'm okay -- I couldn't care less about the
> rest of PEAK! ;).

Please just go ahead and register your (infinite) disapproval, even if 
someone pipes up to say they've tried it ;) :) .  If it's a sub-package 
it really should be a sub-package, not a top-level package, if it's a 
competing global dispatch system, well, then, they'll just have to find 
a different top-level package name (or Phillip and I will have to rumble 
at PyCon (hope he's not a jujitsu master or something)).

Have fun,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com
                              PyCon is coming...

Re: [Pydispatcher-devel] 'dispatch' naming clash

[Matthew S. <gld...@us...>]

Stephen Waterbury wrote:
> Mike,
> 
> You may be aware that Phillip Eby's PEAK package has a
> sub-package called 'dispatch', which unfortunately (and,
> IMO, rather arrogantly ;) PEAK installs into the
> top-level site-packages namespace.  So, since I already
> had PEAK installed when I installed PyDispatcher, I
> did an 'import dispatch' and 'help(dispatch)' and was
> completely astonished at the result until I realized
> it was coming from PEAK's dispatch package.


I think it does this because PEAK collects a lot of other packages. 
PJE's predicate dispatch package seems to be a "sister" package to the 
'protocols' package in PyProtocols -- so this problem would exist for 
those using just PyProtocols and not just those using the entirety of PEAK.


> Anyway, I realize that may or may not have practical
> consequences, but it does make me uncomfortable.  I need
> both PEAK and PyDispatch in my application, so I was
> wondering if anyone had tried that and, if so, whether
> they had experienced anything untoward.

Pat O'Brien and I ran into this namespace clash in developing Schevo, 
because we too use both PyDispatcher and PyProtocols' predicate-dispatch 
generic functions.

We ended up solving the problem by a) including most Python dependencies 
within Schevo in a manner that doesn't clash with site-packages, and b) 
renaming the PyDispatch package from 'dispatch' to 'pydispatch' within 
those included dependencies.

This turns out to work pretty well for us even though there is some 
sleight of hand involved, since we depend on the CVS/SVN HEAD versions 
of both PEAK and the 'py' library -- it ensures that the correct 
versions are used, users working out of our Subversion repository don't 
have to get their hands dirty with a lot of dependencies, and anything 
installed in site-packages is left untouched.


-- 
Matthew R. Scott

Re: [Pydispatcher-devel] 'dispatch' naming clash

[Stephen W. <go...@co...>]

Mike C. Fletcher wrote:
> That said, as long as PEAK's module doesn't overwrite any of the modules 
> in the PyDispatcher package (and as long as importing it's __init__.py 
> doesn't completely kark up the object model in some inventive and evil 
> way (this being PEAK, after all)) ...

Heh ... very well have you articulated the source of my unease.
But from Matthew's and Pat's replies, I gather that it didn't
kark up this particular subspace of the object model ... I'm
almost disappointed ... something in me is always secretly
gleeful when deep voodoo goes awry.  ;)

Matthew Scott wrote:
> Stephen Waterbury wrote:
>> ... Phillip Eby's PEAK package has a
>> sub-package called 'dispatch', which unfortunately (and,
>> IMO, rather arrogantly ;) PEAK installs into the
>> top-level site-packages namespace.  ...
> 
> I think it does this because PEAK collects a lot of other packages.

Welll ... <grumble grumble> ... yes PEAK does that, but I don't
see the PEAK dispatch package being released separately, as (say)
PyProtocols (justifiably) was.  IMHO, unless a package is
maintained as a separate distribution, it should install
itself within the namespace of its parent package.  (I also use
ZODB, and it's needless pollution always bugs me, but they have
managed not to step on anybody's else's names yet, AFAICT.)
 
> PJE's predicate dispatch package seems to be a "sister" package to the 
> 'protocols' package in PyProtocols -- so this problem would exist for 
> those using just PyProtocols and not just those using the entirety of PEAK.

True ... all the more reason ...

> Pat O'Brien and I ran into this namespace clash in developing Schevo ....
> We ended up solving the problem by a) including most Python dependencies 
> within Schevo in a manner that doesn't clash with site-packages, and b) 
> renaming the PyDispatch package from 'dispatch' to 'pydispatch' within 
> those included dependencies.

I don't mind this solution, but it shouldn't be necessary if PEAK were
playing nice.

Patrick K. O'Brien wrote:
> ....  The problem with PEAK began
> before Philip was aware of this project ....  The
> PEAK dispatcher is a different beast altogether, iirc.  (And let's face
> it, dispatch is a pretty generic term.  I wasn't the first and only
> person to create something with that name.)

True enough, but AFAIK, Mike and you were the first to release
a Python package with a module by that name, so I think your
claim to it in the Python namespace is legitimate.

> For now, let's give Mr. Eby the benefit of the doubt and assume that we
> can work out an amicable solution.  If that fails, Mike can feed him to
> the lions at PyCon while I sit ringside cheering on the lions.  ;-)

Rawr!  We should advertise the event -- heck, it might double
the PyCon registrations!   (Headline:  "Python Community
Metes Out Severe Penalties For Namespace Pollution!" ...
gimme that ol' time religion.  :)

> In all seriousness, perhaps a nice, polite message to PJE would be a
> good way to start.  I'd do it myself except I'm dog-tired right now.

Agreed.  My next step was going to be politely pointing out the
situation in a message to the PEAK list and seeing what response
came forth.  If you beat me to it, I'll chime in to register my vote
in favor of a more ecological approach to the Python contributed
package namespace, anyway.

Thanks for all the input, everyone.

Cheers,
Steve

Re: [Pydispatcher-devel] 'dispatch' naming clash

[Stephen W. <go...@co...>]

Stephen Waterbury wrote:
> almost disappointed ... something in me is always secretly
> gleeful when deep voodoo goes awry.  ;)

Of course, I meant "when deep voodoo that my stuff doesn't
depend on goes awry"!  Or, as Mel Brooks once pointed out,
"Tragedy is when I get a hangnail; comedy is when someone
else falls down a manhole."  ;)

Steve

Re: [Pydispatcher-devel] 'dispatch' naming clash

[Matthew S. <gld...@us...>]

Stephen Waterbury wrote:
> IMHO, unless a package is
> maintained as a separate distribution, it should install
> itself within the namespace of its parent package.

This is why it totally, absolutely, positively, posilutely, absitively,
sucks that relative imports weren't implemented by Python 2.4
(...wishing I had more time, and more mad C skills...)

We were going to do precisely what you suggested to include dependencies
within Schevo, but then realized that said dependencies would be doing
quite a bit of absolute importing of themselves.

That's when we decided to hack around it, because we didn't want to
patch a bunch of import statements in the several large moving targets
that are Schevo's dependencies ;)

-- 
Matthew R. Scott