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
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.
Regards
Tino
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
> 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
india = __import__('in')
will work
while you must alias in Python, you can have what you want on disk
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
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
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 +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
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
It's possible with name space packages but every vendor must define the
com package as a name space package w/o putting any code into the
__init__.py except the name space declaration.
Christian
> 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.
> 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.