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]

Re: keyword in package name.

On Oct 19, 12:11 pm, Tino Wildenhain <t...@wildenhai n.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

[Marc 'BlackJack' Rintsch]

Re: keyword in package name.

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

[Terry Reedy]

Re: keyword in package name.

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

[Abhishek Mishra]

Re: keyword in package name.

On Oct 19, 2:06 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.net 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?
>
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]

Re: keyword in package name.

Abhishek Mishra schrieb:

On Oct 19, 2:06 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.net 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?
>>
>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

[MRAB]

Re: keyword in package name.

On Oct 19, 7:05 am, Abhishek Mishra <abhishekmish.. .@gmail.comwrot e:

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]

Re: keyword in package name.

Abhishek Mishra wrote:

On Oct 19, 12:11 pm, Tino Wildenhain <t...@wildenhai n.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/

[Steve Holden]

Re: keyword in package name.

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/

[Steve Holden]

Re: keyword in package name.

Abhishek Mishra wrote:

On Oct 19, 12:11 pm, Tino Wildenhain <t...@wildenhai n.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/

[Christian Heimes]

Re: keyword in package name.

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

[Lawrence D'Oliveiro]

Re: keyword in package name.

In message
<ecf20529-c99f-4a2d-95f0-289aeaa2c048@s9 g2000prm.google groups.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.

[Lawrence D'Oliveiro]

Re: keyword in package name.

In message <mailman.2670.1 224434886.3487. python-list@python.org >, 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.