keyword in package name.

[Abhishek Mishra]

Hello Everyone,

I have the habit of using domain names (of either the application or
company) in reverse in package names.

for e.g. com.spam.app1

I've recently started a project for an indian domain (tld = .in),
which leads to a package name like

in.spam.app1

This causes a syntax error, as "in" is a keyword.
I understand that this is an unfortunate "feature", but has anyone
faced this problem before,
and is there a possible workaround.

P.S. this would also be a problem for the iceland domains (tld = .is).
TLDs: http://data.iana.org/TLD/tlds-alpha-by-domain.txt
Python Keywords: http://www.python.org/doc/2.5.2/ref/keywords.html

Regards,
Abhishek Mishra

 

[Abhishek Mishra]

While this seemed a good idea for java, I don't think it makes
sense for python - the reason: in python you have an import
mechanism, where in java you just have namespaces.

Therefore you can always avoid namespace clashes at import time.

Hi,

Thanks for your reply on a Sunday!

Here's my 2 cents on why I prefer this mechanism -

I would like not to worry about namespace clashes at import time.
Using a toplevel package which isolates your namespace from all
others, is a good idea in my opinion.
This could be a product name (like MoinMoin in MoinMoin), company name
(like google in google app engine - which is just one short of
com.google btw), or your DNS.
Therefore I use a domain name lots of times. (I admit that I picked up
this habit from programming a lot in java).

Although it looks like in this case I would have to use just the
project name.

Thanks & Regards,
Abhishek Mishra

 

[Marc 'BlackJack' Rintsch]

I have the habit of using domain names (of either the application or
company) in reverse in package names.

for e.g. com.spam.app1

I've recently started a project for an indian domain (tld = .in), which
leads to a package name like

in.spam.app1

This causes a syntax error, as "in" is a keyword. I understand that this
is an unfortunate "feature", but has anyone faced this problem before,
and is there a possible workaround.

`com_spam.app1`!? I would even recommend this with domains that don't
clash with keywords because if several people start to use this package
name convention you will get name clashes at package level. Say there
are two vendors with a `com` TLD, how do you install their packages?
Into the same `com/` subdirectory? The `__init__.py` of which vendor
should live at the `com/` directory level? If you install them into two
different directories but want to import modules from both vendors -- how?

Ciao,
Marc 'BlackJack' Rintsch

 

[Terry Reedy]

Hello Everyone,

I have the habit of using domain names (of either the application or
company) in reverse in package names.

for e.g. com.spam.app1

I've recently started a project for an indian domain (tld = .in),
which leads to a package name like

in.spam.app1

This causes a syntax error, as "in" is a keyword.

india = __import__('in')
will work
while you must alias in Python, you can have what you want on disk

 

[Abhishek Mishra]

`com_spam.app1`!?  I would even recommend this with domains that don't
clash with keywords because if several people start to use this package
name convention you will get name clashes at package level.  Say there
are two vendors with a `com` TLD, how do you install their packages?  
Into the same `com/` subdirectory?  The `__init__.py` of which vendor
should live at the `com/` directory level?  If you install them into two
different directories but want to import modules from both vendors -- how?

Ciao,
        Marc 'BlackJack' Rintsch

Ah, you have opened my eyes.
I should have asked myself before why I did not face such a clash.
(because no-one uses this convention!)

I guess the way to go is not use the tld, but just a unique company/
product name.

Thanks,
Abhishek Mishra

 

[Diez B. Roggisch]

Ah, you have opened my eyes.
I should have asked myself before why I did not face such a clash.
(because no-one uses this convention!)

I guess the way to go is not use the tld, but just a unique company/
product name.

I personally tend to mix the approaches. Using setuptools, you can
declare so-called "namespace-packages".

I use one of these for all my projects at work. It is derived from the
companyname, and thus is unique. And all sub-packages for the various
projects can have names that describe them and sometimes would clash
with other projects (e.g. devtools, which also is a TurboGears-package)

Diez

 

[MRAB]

Hello Everyone,

I have the habit of using domain names (of either the application or
company) in reverse in package names.

for e.g. com.spam.app1

I've recently started a project for an indian domain (tld = .in),
which leads to a package name like

in.spam.app1

This causes a syntax error, as "in" is a keyword.
I understand that this is an unfortunate "feature", but has anyone
faced this problem before,
and is there a possible workaround.

P.S. this would also be a problem for the iceland domains (tld = .is).
TLDs:http://data.iana.org/TLD/tlds-alpha-by-domain.txt
Python Keywords:http://www.python.org/doc/2.5.2/ref/keywords.html

You could add a trailing underscore, ie "in_". This "fix" is done in
the poplib module where the POP3 class has a method called "pass_"
because "pass" is a reserved word.

 

[Steve Holden]

Hi,

Thanks for your reply on a Sunday!

Here's my 2 cents on why I prefer this mechanism -

I would like not to worry about namespace clashes at import time.
Using a toplevel package which isolates your namespace from all
others, is a good idea in my opinion.
This could be a product name (like MoinMoin in MoinMoin), company name
(like google in google app engine - which is just one short of
com.google btw), or your DNS.
Therefore I use a domain name lots of times. (I admit that I picked up
this habit from programming a lot in java).

Although it looks like in this case I would have to use just the
project name.

That will work fine until one of your top-level domains is also a
package or module on some other element of sys.path.

I can see why the convenience of a familiar naming convention might be
appealing, but you shouldn't try to stretch it beyond its natural
boundaries.

regards
Steve

 

[Steve Holden]

Hi,

Thanks for your reply on a Sunday!

Here's my 2 cents on why I prefer this mechanism -

I would like not to worry about namespace clashes at import time.
Using a toplevel package which isolates your namespace from all
others, is a good idea in my opinion.
This could be a product name (like MoinMoin in MoinMoin), company name
(like google in google app engine - which is just one short of
com.google btw), or your DNS.
Therefore I use a domain name lots of times. (I admit that I picked up
this habit from programming a lot in java).

Although it looks like in this case I would have to use just the
project name.

That will work fine until one of your top-level domains is also a
package or module on some other element of sys.path.

I can see why the convenience of a familiar naming convention might be
appealing, but you shouldn't try to stretch it beyond its natural
boundaries.

regards
Steve

 

[Steve Holden]

I have the habit of using domain names (of either the application or
company) in reverse in package names.

[...]
The `__init__.py` of which vendor
should live at the `com/` directory level? If you install them into two
different directories but want to import modules from both vendors -- how?

Obviously the "com" namespace wouldn't belong to any vendor, and the
__init__.py should be empty. Though I do think it's an inappropriate
choice for Python.

regards
Steve

 

[Lawrence D'Oliveiro]

In message

I have the habit of using domain names (of either the application or
company) in reverse in package names.

for e.g. com.spam.app1

I've recently started a project for an indian domain (tld = .in),
which leads to a package name like

in.spam.app1

This causes a syntax error, as "in" is a keyword.

The problem is that domain names aren't obliged to conform to any
programming language syntax. So using them directly in identifiers is
asking for trouble anyway. Best to avoid it.

 

[Lawrence D'Oliveiro]

Though I do think it's an inappropriate choice for Python.

I'd characterize it as a Javaism. It exemplifies the difference between the
corporate, management-driven Java development model, versus the more
freewheeling, informal Python one. Like the difference between strict
subclassing and duck-typing.