Package name with '.' in them: Python Bug ?

[Yannick Patois]

Hi,

Under some naming conditions of module files, it seems that python lost
class static variables values.
It seems only to append when importing a "badly" named module that
itself import a module with a static variable in it (looks complex, but
see the example below, pretty simple):

First a working example:
<<<< file: aTest.py
#! /usr/bin/env python
import imp
import A
name='B'
fp, pathname, description = imp.find_module(name)
B=imp.load_module(name, fp, pathname, description)
a=A.A(1)
b=B.B()

<<<< file: A.py
class A:
a=None
def __init__(self,a=None):
if (a):
A.a=a
def __str__(self):
return str(A.a)
<<<< file: B.py
import A
class B:
def __init__(self):
a=A.A()
print a

Execution:
$ ./aTest.py
1

The value 1 obtained as expected (A.a is a static value and keept as such).

If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:

$ ./aTest.py
None

Renaming B.py to B.1.py made A unable to keeps the value of it's static
variable.

Bug tested with:
Python 1.5.2
Python 2.2.2
Python 2.3.3

Any idea ? Is it well a bug ? Some feature I didnt understood ? I read
about submodule naminig using dots as separator, but I cant relate it
towhat I saw here.

Thanks.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Terry Reedy]

"Yannick Patois" <pa****@calvix.org> wrote in message
news:c3**********@sunnews.cern.ch...

Hi,

Under some naming conditions of module files, it seems that python lost
class static variables values.
Since 'static variable' is not a Python concept, I do not know what you
mean.
It seems only to append when importing a "badly" named module that
itself import a module with a static variable in it (looks complex, but
see the example below, pretty simple):

First a working example:
<<<< file: aTest.py
#! /usr/bin/env python
import imp
import A
name='B'
fp, pathname, description = imp.find_module(name)
B=imp.load_module(name, fp, pathname, description)
a=A.A(1)
b=B.B()

>>>>
<<<< file: A.py
class A:
a=None
def __init__(self,a=None):
if (a):
A.a=a
def __str__(self):
return str(A.a) >>>>
<<<< file: B.py
import A
class B:
def __init__(self):
a=A.A()
print a >>>>

Execution:
$ ./aTest.py
1

The value 1 obtained as expected (A.a is a static value and keept as

such).

Given that you rebound A.a to 1 from None, I especially do not know what
you mean.
If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:
As you seem to be aware, Python expects modules to have a 'nice' name
consisting of
legal_Python_indentifier.py. If you evade this, you are a bit on your own
and may run into untested corner cases.
$ ./aTest.py
None

Renaming B.py to B.1.py made A unable to keeps the value of it's static
variable.
It seems to me that it *kept* its original value. I would put more print
statements into both A.A and B.B and maybe even aTest.py to see where
execution first differs.
Bug tested with:
Python 1.5.2
Python 2.2.2
Python 2.3.3

Any idea ? Is it well a bug ? Some feature I didnt understood ? I read
about submodule naminig using dots as separator, but I cant relate it
towhat I saw here.

import b.b1 would normally mean import file (module) b1 in the b package
directory. But imp obviously did not find fine '1' in a 'B' directory.

Terry J. Reedy

[Yannick Patois]

Hi,
Terry Reedy wrote:

"Yannick Patois" <pa****@calvix.org> wrote in message

Under some naming conditions of module files, it seems that python lost
class static variables values. Since 'static variable' is not a Python concept, I do not know what you
mean.

As you're so smart and you read the following, how do you call 'a' in
class A ?
That's what I want to qualify.

The value 1 obtained as expected (A.a is a static value and keept as

such).
Given that you rebound A.a to 1 from None, I especially do not know what
you mean.

I dont understand.

If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:

As you seem to be aware, Python expects modules to have a 'nice' name
consisting of
legal_Python_indentifier.py.

Which are ? Where to find this info ?
If you evade this, you are a bit on your own
and may run into untested corner cases.
Untested area contains bugs, that's why it's interesting to test them.

$ ./aTest.py
None
Renaming B.py to B.1.py made A unable to keeps the value of it's static
variable.

It seems to me that it *kept* its original value.

However you called it, it doesnt behave the same (and doesnt behave the
way python should work). The change is only a file name, no more.
I would put more print
statements into both A.A and B.B and maybe even aTest.py to see where
execution first differs.
It breaks in B, if I remember well.

Any idea ? Is it well a bug ? Some feature I didnt understood ? I read
about submodule naminig using dots as separator, but I cant relate it
towhat I saw here.

import b.b1 would normally mean import file (module) b1 in the b package
directory.

It's not the case here: would have it be that the import statement would
have broke with "cant find that module".
But imp obviously did not find fine '1' in a 'B' directory.

It didnt seek for it, it just loaded 'B.1' as asked. Everything seems to
work, except that some internal python dictionnary has likely been
corrupted.

Correct behavior would either be "break on 'cant import module 1 from
B'" or "correctly import B.1 without corrupting anything."

To me, that's look to be a bug.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Stephen Robert Norris]

On Fri, 19 Mar 2004 19:12:03 +0100, Yannick Patois wrote:

Hi,
Terry Reedy wrote:

"Yannick Patois" <pa****@calvix.org> wrote in message

Under some naming conditions of module files, it seems that python lost
class static variables values. Since 'static variable' is not a Python concept, I do not know what you
mean.

As you're so smart and you read the following, how do you call 'a' in
class A ?
That's what I want to qualify.

There's no need to be hostile. I'd call it a class variable. It's
certainly not static in any sense of the word I'd use.

The value 1 obtained as expected (A.a is a static value and keept as

such).
Given that you rebound A.a to 1 from None, I especially do not know
what you mean.

I dont understand.

You explicitly construct the A instance with 1, so what do you expect to
happen? A.a is set to None as a class variable, then changed to 1 by the
constructor.

If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:
As you seem to be aware, Python expects modules to have a 'nice' name
consisting of
legal_Python_indentifier.py.

Which are ? Where to find this info ?

Check the Python Reference Manual.

If you evade this, you are a bit on your own
and may run into untested corner cases.
Untested area contains bugs, that's why it's interesting to test them.

The only potential bug here is that perhaps python should have raised an
error when the import happened.
To me, that's look to be a bug.

Yannick

I think the bug is in how you understand Python, not in python.

Stephen

[John Roth]

"Yannick Patois" <pa****@calvix.org> wrote in message
news:c3**********@sunnews.cern.ch...

Hi,

Under some naming conditions of module files, it seems that python lost
class static variables values.
There is no such thing as a static variable in Python.
It seems only to append when importing a "badly" named module that
itself import a module with a static variable in it (looks complex, but
see the example below, pretty simple):
There is no such thing as a static variable in Python.

First a working example:
<<<< file: aTest.py
#! /usr/bin/env python
import imp
import A
name='B'
fp, pathname, description = imp.find_module(name)
B=imp.load_module(name, fp, pathname, description)
a=A.A(1)
b=B.B()

>>>>
<<<< file: A.py
class A:
a=None
def __init__(self,a=None):
if (a):
A.a=a
def __str__(self):
return str(A.a) >>>>
<<<< file: B.py
import A
class B:
def __init__(self):
a=A.A()
print a >>>>

Execution:
$ ./aTest.py
1

The value 1 obtained as expected (A.a is a static value and keept as

such).
If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:
[...]

"B.1" is not a legal file name from an import perspective. The manual
description for find_module says: "The function does not handle hierarchical
module names (names containing dots)."

John Roth


Thanks.

Yannick

[Terry Reedy]

"Yannick Patois" <pa****@calvix.org> wrote in message
news:c3**********@sunnews.cern.ch...

Terry Reedy wrote:

Since 'static variable' is not a Python concept, I do not know what you
mean.

how do you call 'a' in class A ?
(non-method) attribute, possibly 'member' (of class A).

Given that you rebound A.a to 1 from None, I especially do not know what you mean.

I dont understand.

When you call this class
<<<< file: A.py
class A:
a=None
def __init__(self,a=None):
if (a):
A.a=a
with the statement a=A.A(1), you enter __init__ with a==1, trigger the
if(a) [if(1)]conditional and execute A.a=a [A.a=1], thereby rebinding class
attribute a from None, as originally set, to 1. Leaving aside the misuse
of 'static' in C, 'static' usually means 'unchanging', whereas you change
A.a.

As you seem to be aware, Python expects modules to have a 'nice' name
consisting of
legal_Python_indentifier.py.

Which are ? Where to find this info ?

Tutorial I presume, definitely Reference Manual under 'names' and/or
'identifiers'.

If you evade this, you are a bit on your own
and may run into untested corner cases.

Untested area contains bugs, that's why it's interesting to test them.

Yes, I have done similar things.

I would put more print statements into both A.A and B.B
and maybe even aTest.py to see where execution first differs.

To restate: if I were to investigate further, I would add prints
statements, since that has so far worked well for me with Python. What you
do is up to you.
It breaks in B, if I remember well.

In what way? Since the line 'a=A.A(1)', should still rebind A.a, it is
puzzling that the following line 'b=B.B()' should act any differently. The
only thing I can think of is that the name change caused the line 'import
A' to import A under a different internal name so that module A in B is no
longer that same as module A in aTest. I would test this by putting 'print
id(A)' in both files after the imports. I would also add

import sys
print sys.modules

to the end of aTest. I suspect that this will clear up the mystery.

Terry J. Reedy

[Stewart Midwinter]

Yannick Patois <pa****@calvix.org> wrote in message news:<c3**********@sunnews.cern.ch>...

If now I just *rename* file B to B.1, without any change in the code
(except name='B' become name='B.1' in aTest.py), content of B.1.py file
being exacty the same as content of B.py, I get:
.....
Any idea ? Is it well a bug ? Some feature I didnt understood ? I read
about submodule naminig using dots as separator, but I cant relate it
towhat I saw here.

Salut Yannick:

J'ose offrir une réponse....

I work with submodules. They're in some folder, which has subfolders
(call them fbm, uti, and a few others). If I place an empty file in
my root folder called __init__.py, I can refer to modules in the
subfolders by a dot notation. For example, if I have a file
process.py in subfolder fbm, I can say:
import fbm.process

I speculate that when you renamed B to B.1, Python interpreted your
intent to import a module called 1 in subfolder B.

J'espère que cela aide un peu!

Stewart

[Yannick Patois]

Stephen Robert Norris wrote:

On Fri, 19 Mar 2004 19:12:03 +0100, Yannick Patois wrote:
The only potential bug here is that perhaps python should have raised an
error when the import happened.

The doc explicitly says:
"his function does not handle hierarchical module names (names
containing dots)."

So you may say that it's up to the programmer to comply with the doc,
and shouldnt expect things to work well if not.

But, I dont want to handle a hierarchical module: just a non
hierarchical one that appends to have a dot in it's name, and it's not
so explicit that this would break.

The fact that it "almost" work is even more strange, and error prone.

But I dont know, I wont say that this has to be fixed in any way outside
of the programmer's code.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Yannick Patois]

Terry Reedy wrote:

"Yannick Patois" <pa****@calvix.org> wrote in message To restate: if I were to investigate further, I would add prints
statements, since that has so far worked well for me with Python. What you
do is up to you.

Since it seems to be definitly illegal, it would only worth further work
if I would somehow 'fix' python to work with this kind of names, which
is both above my skills and likely unwanted. Having a clear error
message at import time would be nice anyway.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Josiah Carlson]

> But I dont know, I wont say that this has to be fixed in any way outside

of the programmer's code.

I've never seen python modules named like: valid_name.1.py

Considering that you have shown that it does not work, and that there is
documentation stating that it is not /meant/ to work, then the error is
in the way /you/ name /your/ modules, not the way Python handles
/incorrectly/ named modules.

- Josiah

[Josiah Carlson]

> Since it seems to be definitly illegal, it would only worth further work

if I would somehow 'fix' python to work with this kind of names, which
is both above my skills and likely unwanted. Having a clear error
message at import time would be nice anyway.

I've only ever heard of you wanting such behavior. I honestly doubt
that anyone is going to try to fix something that is not considered broken.

You should consider renaming your files. Are names like "name_1.py"
good enough for your use?

- Josiah

[Hung Jung Lu]

> "Yannick Patois" <pa****@calvix.org> wrote in message

Under some naming conditions of module files, it seems that python lost
class static variables values.

---------------------------------
"John Roth" <ne********@jhrothjr.com> wrote in message news:<10*************@news.supernews.com>... There is no such thing as a static variable in Python. ---------------------------------
"Terry Reedy" <tj*****@udel.edu> wrote in message news:<ma************************************@pytho n.org>... Since 'static variable' is not a Python concept, I do not know what you
mean.

---------------------------------

A little hyphen would have made a whole world of difference. The
original poster was referring to "class-static variable", and he did
mention it explicitly. That's the standard jargon in languages like
C++ or Java. "Static" here does not mean "function-static", which in
C++ applies to a variable that belongs to the function's static scope
instead of the dynamic scope (I.e., function-static variables are not
destroyed: they keep their value upon exit of the function scope, and
the next time you enter the function, you get the previous value.)
"Class-static" means something else: it marks the ownership by a
class, not by a particular instance.

To be fair, the same jargon persists in Python when it comes to
staticmethod(): staticmethod in Python 2.3 has nothing to do with
"function staticity", but rather it refers to "class statiticity": a
staticmethod belongs to the class. Given this terminology in Python, I
think it is perfect natural to refer to class-level variables as
"class-static" variables.

"Static" is an meaning-overloaded word. The original poster did NOT
make a mistake. I think the two people that replied simply skipped the
word "class" in "class static variable".

Hung Jung

[Terry Reedy]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

"Yannick Patois" <pa****@calvix.org> wrote in message

Under some naming conditions of module files, it seems that python lost class static variables values. ---------------------------------
"John Roth" <ne********@jhrothjr.com> wrote in message news:<10*************@news.supernews.com>... There is no such thing as a static variable in Python.

---------------------------------
"Terry Reedy" <tj*****@udel.edu> wrote in message

news:<ma************************************@pytho n.org>...

Since 'static variable' is not a Python concept, I do not know what you
mean.

---------------------------------

A little hyphen would have made a whole world of difference. The
original poster was referring to "class-static variable",

In Python, that is a meaningless term to me.
That's the standard jargon in languages like C++ or Java.
Python is neither C++ nor Java. It's data model is quite different.
Imported jargon is meaningless to those not familiear with is. Adding the
word 'static' to 'class attribute' or 'class variable' adds nothing since
there is no differentiation from a hypothetical 'non-static' class
attribute.
To be fair, the same jargon persists in Python when it comes to
staticmethod(): staticmethod in Python 2.3 has nothing to do with
"function staticity", but rather it refers to "class statiticity".

'class statiticity'? is meaningless to me. Actually, 'staticmethod' is
something of a misnomer since the effect of staticmethod(function) is to
mark the function as one to *not* be wrapped as a method but to be left
alone as a function, just like function attributes of instances.
'unwrapped' might have been better. I think there was an overstriving for
parallelism with 'classmethod', which is an accurate and meaningful term
(the contrast being with 'instance method').

Terry J. Reedy

[Yannick Patois]

Josiah Carlson wrote:

But I dont know, I wont say that this has to be fixed in any way
outside of the programmer's code. I've never seen python modules named like: valid_name.1.py

Well, I wrote one (it's generated names, that's why it happenned) ;)
Considering that you have shown that it does not work, and that there is
documentation stating that it is not /meant/ to work
The doc is not so explicit. It says that hierarchical modules are not
handled by load_module(), fine, i dont want to handle hierarchicals one,
just a simple one that has a don in its name.
then the error is
in the way /you/ name /your/ modules, not the way Python handles
/incorrectly/ named modules.

That's exactly what I said, and I tend to believe it.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Josiah Carlson]

> Well, I wrote one (it's generated names, that's why it happenned) ;)

That doesn't make it a good idea. If it wasn't clear, I meant that of
the thousands of Python source files I've seen, I've never seen any
named with a dot. Probably because they don't work correctly, as you
have found.

You didn't answer my question as to whether module_5.py is reasonable
replacement for the module.5.py naming scheme you are currently using.

Considering that you have shown that it does not work, and that there
is documentation stating that it is not /meant/ to work

The doc is not so explicit. It says that hierarchical modules are not
handled by load_module(), fine, i dont want to handle hierarchicals one,
just a simple one that has a don in its name.

The documentation is specific, you quoted it yourself:
"This function does not handle hierarchical module names (names
containing dots)."

Any file name with a dot that is not the extension of the file, is
considered hierarchical, and is "not handled".

then the error is in the way /you/ name /your/ modules, not the way
Python handles /incorrectly/ named modules.

That's exactly what I said, and I tend to believe it.

Then you agree that your naming scheme is flawed. Stop doing it.

- Josiah

[John Roth]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

"Yannick Patois" <pa****@calvix.org> wrote in message

Under some naming conditions of module files, it seems that python lost class static variables values. ---------------------------------
"John Roth" <ne********@jhrothjr.com> wrote in message news:<10*************@news.supernews.com>... There is no such thing as a static variable in Python.

---------------------------------
"Terry Reedy" <tj*****@udel.edu> wrote in message

news:<ma************************************@pytho n.org>...

Since 'static variable' is not a Python concept, I do not know what you
mean.

---------------------------------

A little hyphen would have made a whole world of difference. The
original poster was referring to "class-static variable", and he did
mention it explicitly.

Yes, he did.
That's the standard jargon in languages like C++ or Java.
So what? This is Python, not C++, Java or any other language.
"Static" here does not mean "function-static", which in
C++ applies to a variable that belongs to the function's static scope
instead of the dynamic scope (I.e., function-static variables are not
destroyed: they keep their value upon exit of the function scope, and
the next time you enter the function, you get the previous value.)
"Class-static" means something else: it marks the ownership by a
class, not by a particular instance.

To be fair, the same jargon persists in Python when it comes to
staticmethod(): staticmethod in Python 2.3 has nothing to do with
"function staticity", but rather it refers to "class statiticity": a
staticmethod belongs to the class. Given this terminology in Python, I
think it is perfect natural to refer to class-level variables as
"class-static" variables.

"Static" is an meaning-overloaded word. The original poster did NOT
make a mistake. I think the two people that replied simply skipped the
word "class" in "class static variable".
Static generally means "something that does not change." The fact
that C++ in particular abuses the word has no relevance.

For the record, I knew exactly what he wrote, and I did not
ignore the fact that he wrote "class-static." An object bound to
an identifier in a class is **not** static; it can be changed and
it frequently is. There is no way in the language of making it
static.

The reason he's getting the flack he's getting is because of
attitude. The documentation (which I quoted) clearly states
that what he's trying to do isn't supported. His response to Terry's
original attempt to help him see what was going on was
both rude and sarcastic; that kind of behavior simply isn't
acceptable on this newsgroup.

John Roth
Hung Jung

[John Roth]

"Yannick Patois" <pa****@calvix.org> wrote in message
news:c3***********@biggoron.nerim.net...

Stephen Robert Norris wrote:

On Fri, 19 Mar 2004 19:12:03 +0100, Yannick Patois wrote:
The only potential bug here is that perhaps python should have raised an
error when the import happened.

Actually, I tend to agree this would be a nice thing. This
part of import isn't executed so frequently that it would
pose a performace issue.

John Roth

[Yannick Patois]

Hi,

It's always very funny to read commented on onself at the third person;)

I'm sorry to lost reader's time on this message, which is off-topic,
but, I couldnt resist to respond, being directly involved in this post.

John Roth wrote:

The reason he's getting the flack he's getting His response to Terry's
original attempt to help him see what was going on was
both rude and sarcastic; that kind of behavior simply isn't
acceptable on this newsgroup.

Then, the behavior of Terry should also have been quoted as rude and
sarcastic. Most readers understood what I meant with my (incorrect)
qualification of "static". I hope persons should be able to post here
even if they dont master python vocabulary from a to z.
If qualifiying someone as smart enough to correct my own lack of
vocabulary is "both rude and sarcastic", then I feel that heavily
underlining the lack of vocabulary of a contributor could be qualified
the same. And my answer was so because of this attitude.

Of course, it's not an excuse: replying to rudness by rudness is simply
stupid, I do agree.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |

[Hung Jung Lu]

"Terry Reedy" <tj*****@udel.edu> wrote in message news:<ma************************************@pytho n.org>...

Python is neither C++ nor Java. It's data model is quite different.
Imported jargon is meaningless to those not familiear with is. Adding the
word 'static' to 'class attribute' or 'class variable' adds nothing since
there is no differentiation from a hypothetical 'non-static' class
attribute.
...
'class statiticity'? is meaningless to me. Actually, 'staticmethod' is
something of a misnomer since the effect of staticmethod(function) is to
mark the function as one to *not* be wrapped as a method but to be left
alone as a function, just like function attributes of instances.
'unwrapped' might have been better. I think there was an overstriving for
parallelism with 'classmethod', which is an accurate and meaningful term
(the contrast being with 'instance method').

Take a look at Erik Max Francis: (any surprise?)

http://groups.google.com/groups?hl=e...%40alcyone.com

And also search in Python mail list for "class-static" and you will
find many people in Python using the same terminology, even in PEP. It
may be meaningless to you, but that does not mean it is meaningless to
other more meaningful people. :)

As I said, the original poster made no mistake there.

Hung Jung

[Christian Tismer]

Terry Reedy wrote:

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

....

A little hyphen would have made a whole world of difference. The
original poster was referring to "class-static variable",

In Python, that is a meaningless term to me.

Sure, but you knew that the OP was a fresh Python user,
and using terminology of other languages was obvious.
If he knew better, he wouldn't have used this phrasing.
So why not simply explaining the difference in the first place?

ciao - chris

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Christian Tismer]

Yannick Patois wrote:

Hi,

It's always very funny to read commented on onself at the third person;)

I'm sorry to lost reader's time on this message, which is off-topic,
but, I couldnt resist to respond, being directly involved in this post.

John Roth wrote:

The reason he's getting the flack he's getting

His response to Terry's
original attempt to help him see what was going on was
both rude and sarcastic; that kind of behavior simply isn't
acceptable on this newsgroup.

Then, the behavior of Terry should also have been quoted as rude and
sarcastic. Most readers understood what I meant with my (incorrect)
qualification of "static".

Sure, I had no problem to understand, and my first reaction on
Terry's reply was like "why is this needed".

Maybe this is perceived differently by different people,
as I can understand John's POV well as well.
And it happens quite often if you are answering many questions,
that you get bored since you see the same stuff again and again.
At least for my part, I sometimes react less friendly to newbie
questions than I should. When I'm lucky, I read it again
before sending and start over :-)
I hope persons should be able to post here
even if they dont master python vocabulary from a to z.

This should be no problem, and I think this was misreadings/
misunderstandings, and I hope that you all bury the hatchet
and be constructive, again.

a nice weekend to all -- chris

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Hung Jung Lu]

"Terry Reedy" <tj*****@udel.edu> wrote in message news:<ma************************************@pytho n.org>...

In Python, that is a meaningless term to me.
...
Python is neither C++ nor Java. It's data model is quite different.
Imported jargon is meaningless to those not familiear with is. Adding the
word 'static' to 'class attribute' or 'class variable' adds nothing since
there is no differentiation from a hypothetical 'non-static' class
attribute.
---------------
"John Roth" <ne********@jhrothjr.com> wrote in message news:<10*************@news.supernews.com>...
So what? This is Python, not C++, Java or any other language.
...
Static generally means "something that does not change." The fact
that C++ in particular abuses the word has no relevance.

---------------

No relevance, huh?

(a) What is in the Python Programming FAQ, then?

http://www.python.org/doc/faq/progra...-class-methods

Are you saying that this is a C++ Programming FAQ?

(b) Search in Python mailing list for keywords "static variable"
(quoted as single keyword) and "meaningless". There are exactly two
entries, by authors John Roth and Terry Reedy. The fact is,
historically speaking, so far there have been only two person in the
Python community that have claimed "static variables" are meaningless
in Python. Search again with "class static" as single (quoted)
keyword, and you see plenty of people in the Python community talking
about class-static issues, and none of them ever said that it is
meaningless.

So, how come all other people can discuss about class-static issues
without problem, and only you two have to jump out with semantic
issues and say it is meaningless?

I don't understand. What is so special about you two? Are you guys the
Real Academia de la Lengua Pythonica or something like that? :)

Hung Jung

[John Roth]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

"Terry Reedy" <tj*****@udel.edu> wrote in message news:<ma************************************@pytho n.org>...

In Python, that is a meaningless term to me.
...
Python is neither C++ nor Java. It's data model is quite different.
Imported jargon is meaningless to those not familiear with is. Adding the word 'static' to 'class attribute' or 'class variable' adds nothing since there is no differentiation from a hypothetical 'non-static' class
attribute.

---------------
"John Roth" <ne********@jhrothjr.com> wrote in message

news:<10*************@news.supernews.com>...

So what? This is Python, not C++, Java or any other language.
...
Static generally means "something that does not change." The fact
that C++ in particular abuses the word has no relevance.

---------------

No relevance, huh?

(a) What is in the Python Programming FAQ, then?

http://www.python.org/doc/faq/progra...-class-methods
Are you saying that this is a C++ Programming FAQ?

(b) Search in Python mailing list for keywords "static variable"
(quoted as single keyword) and "meaningless". There are exactly two
entries, by authors John Roth and Terry Reedy. The fact is,
historically speaking, so far there have been only two person in the
Python community that have claimed "static variables" are meaningless
in Python. Search again with "class static" as single (quoted)
keyword, and you see plenty of people in the Python community talking
about class-static issues, and none of them ever said that it is
meaningless.

So, how come all other people can discuss about class-static issues
without problem, and only you two have to jump out with semantic
issues and say it is meaningless?

I don't understand. What is so special about you two? Are you guys the
Real Academia de la Lengua Pythonica or something like that? :)
Rudeness objection.

According to the dictionary, which I looked up on dictionary.com,
the word static means unchanging. There is no such thing in
Python as something that cannot change.

You too can look up the actual dictionary definition of a word.

John Roth

Hung Jung

[Yannick Patois]

Josiah Carlson wrote:

You didn't answer my question as to whether module_5.py is reasonable
replacement for the module.5.py naming scheme you are currently using.
That's what I'm doing now, of course, even if it cause some problems I
have to solve another way.

The doc is not so explicit. It says that hierarchical modules are not
handled by load_module(), fine, i dont want to handle hierarchicals
one, just a simple one that has a don in its name.

The documentation is specific, you quoted it yourself:
"This function does not handle hierarchical module names (names
containing dots)."

Any file name with a dot that is not the extension of the file, is
considered hierarchical

This point wasnt clear to me when I read the doc. I well understood
"hierarchical files uses dots" but not "any dots means hierarchy", and
in fact it does work that way, as the import of "B.1" didnt imported
submodule 1 from B but really "B.1".
and is "not handled".

Well, in fact it is, it only cause very subtle bugs afterwards.

then the error is in the way /you/ name /your/ modules, not the way
Python handles /incorrectly/ named modules.

That's exactly what I said, and I tend to believe it.

Then you agree that your naming scheme is flawed. Stop doing it.

I stopped using it as soon as I understood that the problem was there.
I think that such a thing should not work at all and not "partially
work", but I'm not a python master, and maybe it doesnt worth to be
done. I'm just rising the issue here.

Yannick

--
_/ Yannick Patois \_________________________________________________ __
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: pa****@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |