namespace for released packages?

[Alex Hunsley]

What is the python convention for namespaces of released packages? In
Java you'd write your domain name (if you have one) backwards, this:

uk.org.ohmslaw.myPackage

.... thus ensuring uniqueness. Is it the same for Python?

thanks
alex

 

[Alex Hunsley]

What is the python convention for namespaces of released packages? In
Java you'd write your domain name (if you have one) backwards, this:

uk.org.ohmslaw.myPackage

... thus ensuring uniqueness. Is it the same for Python?

thanks
alex

I presume the lack of replies and what I've seen on code on the net
means that the modus operandi is to just have your python at the top
level, and not in a package that makes it unique... I find this quite
strange! Do problems not arise due to module name clashes?

alex

 

[Terry Reedy]

I presume the lack of replies and what I've seen on code on the net
means that the modus operandi is to just have your python at the top
level, and not in a package that makes it unique... I find this quite
strange! Do problems not arise due to module name clashes?

Third party packages are generally put in the site-packages directory. So
far, there has not be much problem with name clashes.

tjr

 

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I presume the lack of replies and what I've seen on code on the net
means that the modus operandi is to just have your python at the top
level, and not in a package that makes it unique... I find this quite
strange! Do problems not arise due to module name clashes?

It is pretty rare to get clashes - module authors are generally
nice enough to make sure nobody else is using their package name
before releasing things and generally package everything into
a single top-level module.

- --
Stuart Bishop <[email protected]>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFA+tXEAfqZj7rGN0oRAgSOAJ96UwUBXtJ8WMUd2hAUt+jqX7l90QCePqKr
TQ6ISW/8pMvvHZoY2PH4nEo=
=Fo/D
-----END PGP SIGNATURE-----

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

What is the python convention for namespaces of released packages? In
Java you'd write your domain name (if you have one) backwards, this:

uk.org.ohmslaw.myPackage

... thus ensuring uniqueness. Is it the same for Python?

No. If a Python library is released as a package, the author choses
a package name that is unlikely to collide. Typically, such a name
is readily available, as the project team developing the package has
found a "product name" already. That product name stays with the package
even if the affiliation of the authors changes.

I find the Java convention evil - it brings into source code affiliation
information which really doesn't belong there. Instead, package authors
should come up with names that uniquely identify their software in the
first place.

Regards,
Martin

 

[Irmen de Jong]

Third party packages are generally put in the site-packages directory. So
far, there has not be much problem with name clashes.

I experienced only one problem so far:
you probably know Pyro (Python Remote Objects), which I wrote.
Much later there was somebody else who did some stuff with
Python and Robotics, and also called his project "pyro"...
http://pyro.sourceforge.net
http://pyrorobotics.org

Now, if you only use one or the other, you're safe, but
there was this person that needed to use *both* at the same
time. What would be the best solution in this case?

I was (and still am) not prepared to change my project's name
or package name because it has been around much longer and is by now
commonly recognised...


--Irmen de Jong.

 

[Alex Hunsley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1





It is pretty rare to get clashes - module authors are generally
nice enough to make sure nobody else is using their package name
before releasing things and generally package everything into
a single top-level module.

Doesn't a single top level module translate into all the source being in
one file? (please correct if I'm wrong about this!)

alex

 

[Alex Hunsley]

No. If a Python library is released as a package, the author choses
a package name that is unlikely to collide. Typically, such a name
is readily available, as the project team developing the package has
found a "product name" already. That product name stays with the package
even if the affiliation of the authors changes.

So in my case, it would be sufficient to place all my code in a package
named after the product? (in my case, 'Pypreweb', which hasn't been
taken, I've checked.)

I find the Java convention evil - it brings into source code affiliation
information which really doesn't belong there. Instead, package authors
should come up with names that uniquely identify their software in the
first place.

Regards,
Martin

I suppose the affiliation information could be a tripping point - e.g.
if someone else takes ownership of the product, the package name (if
derived from a doman name etc) would no longer be appropriate!

alex

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

So in my case, it would be sufficient to place all my code in a package
named after the product? (in my case, 'Pypreweb', which hasn't been
taken, I've checked.)

Yes, although "preweb" might be a better alternative, given that it is
clear you are talking about Python.

I suppose the affiliation information could be a tripping point - e.g.
if someone else takes ownership of the product, the package name (if
derived from a doman name etc) would no longer be appropriate!

Indeed. Then, all applications using the package need to be changed.

Regards,
Martin

 

[Alex Hunsley]

Yes, although "preweb" might be a better alternative, given that it is
clear you are talking about Python.

I quite like 'pypreweb', pronounced 'piper-web'. Sounds a bit more
interesting sounding than 'preweb' IMHO. The other idea was papyrus, which I
quite like (and is also not taken).

And it seems quite common to prepend py to the start of python projects.... not
unusual, anyway.

Indeed. Then, all applications using the package need to be changed.

Regards,
Martin

I hadn't thought of it that way before, but it's a good point.

alex

 

[Peter Otten]

Doesn't a single top level module translate into all the source being in
one file? (please correct if I'm wrong about this!)

Yes, but when the module grows you can transparently turn it into a package,
as package.py and package/__init__.py are freely interchangeable.

Peter

 

[Alex Hunsley]

Alex Hunsley wrote:




Yes, but when the module grows you can transparently turn it into a package,
as package.py and package/__init__.py are freely interchangeable.

Peter

ah gotcha, I know what you mean...

alex

 

[Dennis Lee Bieber]

And it seems quite common to prepend py to the start of python projects.... not
unusual, anyway.

Without making a detailed study, most of the packages with "py*"
names I've seen seem to be those that 1) are Python rewrites of stuff
from other languages, or 2) Python interface modules for use with some
other well-known application.
--

 

[Stuart Bishop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doesn't a single top level module translate into all the source being
in one file? (please correct if I'm wrong about this!)

My bad - I should have said single top-level package (containing
as many modules and subpackages as you like).

- --
Stuart Bishop <[email protected]>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFA/Aq2AfqZj7rGN0oRAuhmAJ99d2uLrfyGwAxqB3wt7dlf6V9DPACbBtJ+
r9Ya1WK7jDbSOoBjQjYui1s=
=LuRr
-----END PGP SIGNATURE-----

 

[Alex Hunsley]

Without making a detailed study, most of the packages with "py*"
names I've seen seem to be those that 1) are Python rewrites of stuff
from other languages, or 2) Python interface modules for use with some
other well-known application.
--

I think you're right on this one!
I'm going to go with the name papyrus.

alex

 

[Peter Hansen]

I experienced only one problem so far:
you probably know Pyro (Python Remote Objects), which I wrote.
Much later there was somebody else who did some stuff with
Python and Robotics, and also called his project "pyro"...
http://pyro.sourceforge.net
http://pyrorobotics.org

Now, if you only use one or the other, you're safe, but
there was this person that needed to use *both* at the same
time. What would be the best solution in this case?

I was (and still am) not prepared to change my project's name
or package name because it has been around much longer and is by now
commonly recognised...

Would one or the other of those two packages fail completely
if one simply changed the name of its main directory? Presumably
no one would have a serious complaint in such an application
with importing one or the other as "robopyro" or "remotepyro"
or some such, to avoid a conflict in the namespace of the
importing module...

-Peter