469,599 Members | 2,617 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,599 developers. It's quick & easy.

keyword in package name.

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
Oct 19 '08 #1
12 1339
On Oct 19, 12:11*pm, Tino Wildenhain <t...@wildenhain.dewrote:
Abhishek Mishra wrote:
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

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


Oct 19 '08 #2
On Sat, 18 Oct 2008 23:05:38 -0700, Abhishek Mishra wrote:
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
Oct 19 '08 #3
Abhishek Mishra wrote:
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

Oct 19 '08 #4
On Oct 19, 2:06*pm, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>
`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
Oct 19 '08 #5
Abhishek Mishra schrieb:
On Oct 19, 2:06 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>`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.
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
Oct 19 '08 #6
On Oct 19, 7:05*am, Abhishek Mishra <abhishekmish...@gmail.comwrote:
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.
Oct 19 '08 #7
Abhishek Mishra wrote:
On Oct 19, 12:11 pm, Tino Wildenhain <t...@wildenhain.dewrote:
>Abhishek Mishra wrote:
>>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
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.
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 +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Oct 19 '08 #8
Marc 'BlackJack' Rintsch wrote:
On Sat, 18 Oct 2008 23:05:38 -0700, Abhishek Mishra wrote:
>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
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Oct 19 '08 #9
Abhishek Mishra wrote:
On Oct 19, 12:11 pm, Tino Wildenhain <t...@wildenhain.dewrote:
>Abhishek Mishra wrote:
>>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
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.
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 +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Oct 19 '08 #10
Marc 'BlackJack' Rintsch wrote:
`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?
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

Oct 19 '08 #11
In message
<ec**********************************@s9g2000prm.g ooglegroups.com>,
Abhishek Mishra wrote:
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.
Oct 19 '08 #12
In message <ma**************************************@python.o rg>, Steve
Holden wrote:
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.
Oct 19 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Bryan Parkoff | last post: by
3 posts views Thread by Petterson Mikael | last post: by
3 posts views Thread by shorti | last post: by
2 posts views Thread by patrimith | last post: by
reply views Thread by Steven Samuel Cole | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.