Re: List sequential initialization

[René Fleschenberg]

HMS Surprise schrieb:
> I thought if I could do this:
> >>> a = b = ''

Bind both the names a and b to the same string object.

> >>> a = 'a'

Bind the name a to a *new* string object with the value 'a'. This
replaces the previous binding of the name a.

> >>> la = lb = []

Bind both the names la and lb to the same list object.

> >>> la.append('a')

Append the string 'a' to the *existing* list object referenced by the
name la. This modifies the object that is referenced by the name la (and
also by the name lb), it does not create a new object. The equivalent to
what you did with the strings above would have been:

la = ['a']

This would have created a new list object and bound the name la to it,
while the name lb would still reference the other list object you
created earlier.

If you want to modify the list referenced by la but not the one
referenced by lb, you need to actually *copy* the list with one of these
methods:

lb = list(la)

or

lb = la[:]

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Forgetting an import

[René Fleschenberg]

HMS Surprise schrieb:
> I imported a set of functions from a file I wrote to interpreter
> shell:
> 
> from myFile import *
> 
> Now if I change functions in this file how can I make python forget it
> so I can force a fresh import?

I think you are looking for reload(). But don't forget to check its
documentation, there may be some caveats.


-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to get inputs for a python program that run from another python program

[René Fleschenberg]

Hi

pradeep nair schrieb:
> now wen i run hello1.py,i want the  some function or utility in
> hello1.py that can pass the keyboard i/p  to hello.py .

Have a look at subprocess.Popen

http://docs.python.org/lib/module-subprocess.html

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Martin v. Löwis schrieb:
>>> Then get tools that match your working environment.
>> Integration with existing tools *is* something that a PEP should
>> consider. This one does not do that sufficiently, IMO.
> 
> What specific tools should be discussed, and what specific problems
> do you expect?

Systems that cannot display code parts correctly. I expect problems with
unreadable tracebacks, for example.

Also: Are existing tools that somehow process Python source code e.g. to
test wether it meets certain criteria (pylint & co) or to aid in
creating documentation (epydoc & co) fully unicode-ready?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Martin v. Löwis schrieb:
> I've reported this before, but happily do it again: I have lived many
> years without knowing what a "hub" is, and what "to pass" means if
> it's not the opposite of "to fail". Yet, I have used their technical
> meanings correctly all these years.

I was not speaking of the more general (non-technical) meanings, but of
the technical ones. The claim which I challenged was that people learn
just the "use" (syntax) but not the "meaning" (semantics) of these
terms. I think you are actually supporting my argument ;)

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

You have misread my statements.

Carsten Haese schrieb:
> There is evidence against your assertions that knowing some English is a
> prerequisite for programming 

I think it is a prerequesite for "real" programming. Yes, I can imagine
that if you use Python as a teaching tool for Chinese 12 year-olds, then
it might be nice to be able to spell identifiers with Chinese
characters. However, IMO this is such a special use-case that it is
justified to require the people who need this to explicitly enable it,
by using a patched interpreter or by enabling an interpreter option for
example.

> in Python and that people won't use non-ASCII
> identifiers if they could. 

I did not assert that at all, where did you get the impression that I
do? If I were convinced that noone would use it, I would have not such a
big problem with it. I fear that it *will* be used "in the wild" if the
PEP in its current form is accepted and that I personally *will* have to
deal with such code.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Christophe schrieb:
> René Fleschenberg a écrit :
>> Christophe schrieb:
>>> You should know that displaying and editing UTF-8 text as if it was
>>> latin-1 works very very well.s
>>
>> No, this only works for those characters that are in the ASCII range.
>> For all the other characters it does not work well at all.
> 
> This alone shows you don't know enouth about UTF-8 to talk about it.
> UTF-8 will NEVER use < 128 chars to describe multibyte chars. When you
> parse a UTF-8 file, each space is a space, each \n is an end of line and
> each 'Z' is a 'Z'.

So? Does that mean that you can just display UTF-8 "as if it was
Latin-1"? No, it does not. It means you can do that for exactly those
characters that are in the ASCII range. For all the others, you can not.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Christophe schrieb:

> Who displays stack frames? Your code. 

Wrong.

> Whose code includes unicode
> identifiers? Your code. 

Wrong.

> Whose fault is it to create a stack trace
> display procedure that cannot handle unicode? You. 

Wrong. If you never have to deal with other people's code,
congratulations to you. Many other people have to. And no, I can usualy
not just tell the person to fix his code. I need to deal with it.

> Even if you don't
> make use of them, you still have to fix the stack trace display
> procedure because the exception error message can include unicode text
> *today*

The error message can, but at least the function names and other
identifiers can not.

> You should know that displaying and editing UTF-8 text as if it was
> latin-1 works very very well.s

No, this only works for those characters that are in the ASCII range.
For all the other characters it does not work well at all.

> Also, Terminals have support for UTF-8 encodings already. 

Some have, some have not. And you not only need a terminal that can
handle UTF-8 data, you also need a font that has a glyph for all the
characters you need to handle, and you may also need a way to actualy
enter those characters with your keyboard.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>> Now, very special environments (what I called "rare and isolated"
>> earlier) like special learning environments for children are a different
>> matter. It should be ok if you have to use a specially patched Python
>> branch there, or have to use an interpreter option that enables the
>> suggested behaviour. For general programming, it IMO is a bad idea.
> 
> Ok, let me put it differently.
> 
> You *do not* design Python's keywords. You *do not* design the stdlib. You *do
> not* design the concepts behind all that. You *use* them as they are. So you
> can simply take the identifiers they define and use them the way the docs say.
> You do not have to understand these names, they don't have to be words, they
> don't have to mean anything to you. They are just tools. Even if you do not
> understand English, they will not get in your way. You just learn them.

I claim that this is *completely unrealistic*. When learning Python, you
*do* learn the actual meanings of English terms like "open",
"exception", "if" and so on if you did not know them before. It would be
extremely foolish not to do so. You do care about these names and you do
want to know their meaning if you want to write anything more in your
life than a 10-line throw-away script.

> But you *do* design your own software. You *do* design its concepts. You *do*
> design its APIs. You *do* choose its identifiers. And you want them to be
> clear and telling. You want them to match your (or your clients) view of the
> application. You do not care about the naming of the tools you use inside. But
> you do care about clarity and readability in *your own software*.

I do care about the naming of my tools. I care alot. Part of why I like
Python is that it resisted the temptation to clutter the syntax up with
strange symbols like Perl. And I do dislike the decorator syntax, for
example.

Also, your distinction between "inside" and "your own" is nonsense,
because the "inside" does heavily leak into the "own". It is impossible
to write "your own software" with clarity and readability by your
definition (i.e. in your native language). Any real Python program is a
mix of identifiers you designed yourself and identifiers you did not
design yourself. And I think the ones chosen by yourself are even often
in the minority. It is not feasible in practice to just learn what the
"other" identifiers do without understanding their names. Not for
general programming. The standard library is already too big for that,
and most real programs use not only the standard library, but also third
party libraries that have English APIs.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
>> *That* logic can be used to justify the introduction of *any* feature.
>>
> 
> No. That logic can only be used to justify the introduction of a feature
> that brings freedom.

That is any feature that you are not forced to use. So let's get gotos
and the like. Every programming language dictates some things. This is
not a bad thing.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
>> Unless you are 150% sure that there will *never* be the need for a
>> person who does not know your language of choice to be able to read or
>> modify your code, the language that "fits the environment best" is
>> English.
> 
> Just a touch of hyperbole perhaps?
> 
> You know, it may come to a surprise to some people that English is not 
> the only common language. In fact, it only ranks third, behind Mandarin 
> and Spanish, and just above Arabic. Although the exact number of speakers 
> vary according to the source you consult, the rankings are quite stable: 
> Mandarin, Spanish, then English. Any of those languages could equally 
> have claim to be the world's lingua franca.

For a language to be a (or the) lingua franca, the sheer number of
people who speak it is actually not as important as you seem to think.
Its use as an international exchange language is the decisive criterion
-- definitely not true for Mandarin, and for Spanish not nearly as much
as for English.

Also, there can be different "linguae francae" for different fields.
English definitely is the lingua franca of programming. But that is
actually off topic. Programming languages are not the same as natural
languages. I was talking about program code, not about works of literature.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> *Your* logic can be used to justify dropping *any* feature.

No. I am considering both the benefits and the problems. You just happen
to not like the outcome of my considerations [again, please don't reply
by E-Mail, I read the NG].

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Marc 'BlackJack' Rintsch schrieb:
> There are potential users of Python who don't know much english or no
> english at all.  This includes kids, old people, people from countries
> that have "letters" that are not that easy to transliterate like european
> languages, people who just want to learn Python for fun or to customize
> their applications like office suites or GIS software with a Python
> scripting option.

Make it an interpreter option that can be turned on for those cases.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>>> - Non-english speakers can not create or understand
>>>   english identifiers hence can't create good code nor
>>>   easily grok existing code.
>> I agree that this is a problem, but please understand that is problem is
>> _not_ solved by allowing non-ASCII identifiers!
> 
> Well, as I said before, there are three major differences between the stdlib
> and keywords on one hand and identifiers on the other hand. Ignoring arguments
> does not make them any less true.

BTW: Please stop replying to my postings by E-Mail (in Thunderbird, use
"Reply" in stead of "Reply to all").

I agree that keywords are a different matter in many respects, but the
only difference between stdlib interfaces and other intefaces is that
the stdlib interfaces are part of the stdlib. That's it. You are still
ignoring the fact that, contrary to what has been suggested in this
thread, it is _not_ possible to write "German" or "Chinese" Python
without cluttering it up with many many English terms. It's not only the
stdlib, but also many many third party libraries. Show me one real
Python program that is feasibly written without throwing in tons of
English terms.

Now, very special environments (what I called "rare and isolated"
earlier) like special learning environments for children are a different
matter. It should be ok if you have to use a specially patched Python
branch there, or have to use an interpreter option that enables the
suggested behaviour. For general programming, it IMO is a bad idea.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> Then get tools that match your working environment.

Integration with existing tools *is* something that a PEP should
consider. This one does not do that sufficiently, IMO.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
> René Fleschenberg schrieb:
> 
>> today, to the best of my knowledge. And "in some form or another"
>> basically means that the PEP would create more possibilities for things
>> to go wrong. That things can already go wrong today does not mean that
>> it does not matter if we create more occasions were things can go wrong
>> even worse.
> 
> Following this logic we should not add any new features at all, because
> all of them can go wrong and can be used the wrong way.

No, that does not follow from my logic. What I say is: When thinking
about wether to add a new feature, the potential benefits should be
weighed against the potential problems. I see some potential problems
with this PEP and very little potential benefits.

> I love Python because it does not dictate how to do things.
> I do not need a ASCII-Dictator, I can judge myself when to use this
> feature and when to avoid it, like any other feature.

*That* logic can be used to justify the introduction of *any* feature.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

[EMAIL PROTECTED] schrieb:
> I'm not sure how you conclude that no problem exists.
> - Meaningful identifiers are critical in creating good code.

I agree.

> - Non-english speakers can not create or understand
>   english identifiers hence can't create good code nor
>   easily grok existing code.

I agree that this is a problem, but please understand that is problem is
_not_ solved by allowing non-ASCII identifiers!

> Considering the vastly greater number of non-English
> spreakers in the world, who are not thus unable to use
> Python effectively, seems like a problem to me.

Yes, but this problem is not really addressed by the PEP. If you want to
do something about this:
1) Translate documentation.
2) Create a way to internationalize the standard library (and possibly
the language keywords, too). Ideally, create a general standardized way
to internationalize code, possibly similiar to how people
internationalize strings today.

When that is done, non-ASCII identifiers could become useful. But of
course, doing that might create a hog of other problems.

> That all programers know enough english to create and
> understand english identifiers is currently speculation or
> based on tiny personaly observed samples.

It is based on a look at the current Python environment. You do *at
least* have the problem that the standard library uses English names.
This assumes that there is documentation in the native language that is
good enough (i.e. almost as good as the official one), which I can tell
is not the case for German.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Gregor Horvath schrieb:
> If comments are allowed to be none English, then why are identifier not?

I don't need to be able to type in the exact characters of a comment in
order to properly change the code, and if a comment does not display on
my screen correctly, I am not as fscked as badly as when an identifier
does not display (e.g. in a traceback).

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
>> Any program that uses non-English identifiers in Python is bound to
>> become gibberish, since it *will* be cluttered with English identifiers
>> all over the place anyway, wether you like it or not.
> 
> It won't be gibberish to the people who speak the language.

Hmmm, did you read my posting? By my experience, it will. I wonder: is
English an acquired language for you?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
> But they aren't new risks and problems, that's the point. So far, every 
> single objection raised ALREADY EXISTS in some form or another. 

No. The problem "The traceback shows function names having characters
that do not display on most systems' screens" for example does not exist
today, to the best of my knowledge. And "in some form or another"
basically means that the PEP would create more possibilities for things
to go wrong. That things can already go wrong today does not mean that
it does not matter if we create more occasions were things can go wrong
even worse.

> There's 
> all this hysteria about the problems the proposed change will cause, but 
> those problems already exist. When was the last time a Black Hat tried to 
> smuggle in bad code by changing an identifier from xyz0 to xyzO?

Agreed, I don't think intended malicious use of the proposed feature
would be a big problem.

>> I think it is not. I think that the problem only really applies to very
>> isolated use-cases. 
> 
> Like the 5.5 billion people who speak no English.

No. The X people who speak "no English" and program in Python. I think X
actually is very low (close to zero), because programming in Python
virtually does require you to know some English, wether you can use
non-ASCII characters in identifiers or not. It is naive to believe that
you can program in Python without understanding any English once you can
use your native characters in identifiers. That will not happen. Please
understand that: You basically *must* know some English to program in
Python, and the reason for that is not that you cannot use non-ASCII
identifiers.

I admit that there may be occasions where you have domain-specific terms
that are hard to translate into English for a programmer. But is it
really not feasible to use an ASCII transliteration in these cases? This
does not seem to have been such a big problem so far, or else we would
have seen more discussions about it, I think.

>> So isolated that they do not justify a change to
>> mainline Python. If someone thinks that non-ASCII identifiers are really
>> needed, he could maintain a special Python branch that supports them. I
>> doubt that there would be alot of demand for it.
> 
> Maybe so. But I guarantee with a shadow of a doubt that if the change 
> were introduced, people would use it -- even if right now they say they 
> don't want it.

Well, that is exactly what I would like to avoid ;-)

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Javier Bezos schrieb:
>> But having, for example, things like open() from the stdlib in your code
>> and then öffnen() as a name for functions/methods written by yourself is
>> just plain silly. It makes the code inconsistent and ugly without
>> significantly improving the readability for someone who speaks German
>> but not English.
> 
> Agreed. I always use English names (more or
> less :-)), but this is not the PEP is about.

We all know what the PEP is about (we can read). The point is: If we do
not *need* non-English/ASCII identifiers, we do not need the PEP. If the
PEP does not solve an actual *problem* and still introduces some
potential for *new* problems, it should be rejected. So far, the
"problem" seems to just not exist. The burden of proof is on those who
support the PEP.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Carsten Haese schrieb:
> Allowing people to use identifiers in their native language would
> definitely be an advantage for people from such cultures. That's the use
> case for this PEP. It's easy for Euro-centric people to say "just suck
> it up and use ASCII", but the same people would probably starve to death
> if they were suddenly teleported from Somewhere In Europe to rural China
> which is so unimaginably different from what they know that it might
> just as well be a different planet. "Learn English and use ASCII" is not
> generally feasible advice in such cultures.

This is a very weak argument, IMHO. How do you want to use Python
without learning at least enough English to grasp a somewhat decent
understanding of the standard library? Let's face it: To do any "real"
programming, you need to know at least some English today, and I don't
see that changing anytime soon. And it is definitely not going to be
changed by allowing non-ASCII identifiers.

I must say that the argument about domain-specific terms that
programmers don't know how to translate into English does hold some
merit (although it does not really convince me, either -- are these
cases really so common that you cannot feasibly use a transliteration?).
But having, for example, things like open() from the stdlib in your code
and then öffnen() as a name for functions/methods written by yourself is
just plain silly. It makes the code inconsistent and ugly without
significantly improving the readability for someone who speaks German
but not English.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> You could actually try by giving some arguments for your opinion. Your 
> rationale was "English only, please" because of "code sharing".

I thought this was pretty clear. The more people can easily read code,
the higher the probability that it will be useful for them and that they
can make it more useful for others.

>> That completely depends on how you look at code-sharing. My impression
>> always was that the Python community in general does regard code-sharing
>> as A Good Thing.
> 
> I don't think the "Python community" does that because for something 
> to be considered good it should actually be clear what it means. So 
> what actually is "Code sharing"?! Wikipedia seems to know this term 
> but in a slightly different meaning:
> 
> http://en.wikipedia.org/wiki/Code_sharing

I think we all know what "code" in the context of Python means. As for
"to share", I think that is pretty clear, also. It means that people
other than the original authors use, study and modify the code. FWIW, a
Google search for 'Python code-sharing' yields almost 30k results.

> If the "Python community" would think that "code sharing" (whatever 
> that means) is per se a good thing it would switch to spaces only 
> allowed (instead of tabs and spaces allowed). 

There is PEP 8 that encourages the use of spaces only. Personally, I
would not have much of a problem with tabs being banned for indentation.
Maybe the main reason why that is not actually done is compatibility
with legacy code -- I don't know.

> Actually it would 
> refrain from giving indentation and white space a syntactical meaning 
> because this undoubtedly makes "code sharing" (on web pages or through 
> news readers for instance) /a lot/ more difficult.

Where did anyone say that code-sharing is the only concern? I just think
that it is undoubtedly one among others. So for something that harms
this concern to be done, there should be substantial benefits in it. I
fail to see them with non-ASCII identifiers so far.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> You are right, except that using the correct characters for words is 
> not a "funny thing". Using Polish diacritics (for example) for 
> identifier names just makes sense for a project that already uses 
> polish comments and polish names for their code. You will never get in 
> touch with that. Using the right charset for these polish words 
> doesn't change a bit in your ability to debug or understand this code.

I will get in touch with it. I currently have applications installed on
my computer that come with my Linux distribution and that use code with
identifiers and comments written in a non-English language which I would
like to understand. This is tough enough as it is, the same code with
non-ASCII characters that maybe do not even display on my screen would
be even tougher to understand, let alone modify. It does make a
difference wether I can at least recognize and type in the characters or
not. The expectation that such code will only be used for "very closed"
projects that noone else will ever want to get in touch with is unrealistic.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> No, if you claim that something by itself is good and has to be 
> encouraged then you are obliged to prove or give arguments for that.

That would be well outside the scope of this newsgroup, and if you
cannot see the reaons for this yourself, I am afraid that I won't be
able to convince you anyway.

> Exactly. So whether this PEP encourages or discourages code sharing 
> (and I don't think it does either) has nothing to do with the value of 
> this PEP.

That completely depends on how you look at code-sharing. My impression
always was that the Python community in general does regard code-sharing
as A Good Thing. It is not as if we were talking about forcing people to
share code. Just about creating/keeping an environment that makes this
easily possible and encourages it. That *is* something I regard as good
and which therefore, for me, forms an argument against this PEP --
wether you share that opinion or not.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> It has nothing to do with that. It simply allows people to write their 
> own identifier names with their native character set without using 
> dodgy transcriptions (that might not even exist). There is no sense in 
> making people write "ueber" instead of "über". That's 20th century 
> thinking and archaic.

"ueber" at least displays correctly on virtually any computer system in
use today, which for example makes it possible to read and process
tracebacks, something that might actually not only concern developers,
but also end-users.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Marc 'BlackJack' Rintsch schrieb:
 2) The with-statement does have proven substantial benefits, IMO.
>>> Not to me. I don't use it, so no-one should. 
>> Now you are starting to troll?
> 
> I thought he starts to argument like you.  ;-)

I did not argue that way. I doubted that non-ASCII identifiers have
proven substantial benefits for *anyone* (except very rare and special
cases). That is quite different from the with-statement.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> GOTOs are not understable. Identifiers in foreign languages are 
> perfectly understable. Just not to you.
> For coding problems better solutions (approaches) exist than using 
> GOTOs (procedural programming, modules). For identifier naming 
> problems it's not a better approach to stick to English or ASCII. It's 
> just a different approach.

Just by stating your personal opinion that it is not a better but just
different approach, you won't convince anyone. There are important
arguments for why it actually *is* a better approach -- these have been
brought up in this thread many times now.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> That's easy to prevent: just keep your fingers from projects that work with
> them and make sure that projects you start do not use them.

You keep bringing up that argument that completely neglects reality. The
same argument can be used to justify anything else (including the
opposite of your position: Don't like the fact that Python does not
support non-ASCII identifiers? Pick another language!). Let's introduce
gotos and all other kinds of funny stuff -- after all, noone is forced
to work on a project that uses it!

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> * René Fleschenberg (Tue, 15 May 2007 14:04:07 +0200)
>> Thorsten Kampe schrieb:
>>> Because keywords are not meant meant to extended or manipulated or 
>>> something   similar by the programmers. Keywords are well known and only 
>>> a limited set of words. That's why you can't use keywords as 
>>> identifiers.
>> This is true for keywords, but not for the stdlib. Are you suggesting
>> that the stdlib should be "internationalized"?
> 
> No, because it's the /Standard/ Library to be used by everyone. And 
> the lowest common denominator is ASCII and English.

This makes the argument that this PEP would allow people to write
"Chinese only" Python code invalid (unless they do not use the stdlib).

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> You're not trying to suggest that writing code in a closed area project is a
> bad habit, are you?

I think that the idea that you know today, with 100% certainty, that all
parts of your closed area project will stay closed forever is an
illusion and thus a bad idea, yes.

> What would be bad about allowing a project to decide about the best and
> clearest way to name identifiers? 

That very same argument could be used to allow all sorts of "strange
stuff" in Python like gotos and worse. What would be bad about allowing
a project to decide about how to do flow control, especially if you
never get in touch with it?

> And: if it's not a project you will ever getin touch with - what do
you care?

I just fear that I *will* get in touch with identifiers using non-ASCII
symbols if this PEP is implemented.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> Just by repeating yourself you don't make your point more valid. 

You are doing just the same. Your argument that encouraging code-sharing
is not a worthwhile goal is an ideologic one, just as the opposite
argument is, too (I do think that code sharing is very different from
sharing of material goods). That is why I do not think it makes alot of
sense to argue about it. If you don't consider code sharing to be a
value of its own, then that is of course also not an argument against
this PEP. I just happen to have different beliefs.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
>> It is impossible to write Python in a native language other than English
>> even with the implementation of this PEP. All you get is a weird mixture
>> of English identifiers from various libraries and identifiers in your
>> native language.
> 
> You have a few English keywords that are not meant to be understood 
> but can be learned.

I am talking about the stdlib, not about the very few keywords Python
has. Are you going to re-write the standard library in your native
language so you can have a consistent use of natural language among your
code?

> It neither encourages or discourages anything. And I don't think 
> encouraring or discouraging code sharing is a good thing. There is 
> simply no general reason to do so.

I disagree, but since that is a question of ideology, it makes little
sense to argue about it.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
>> That is a reason to actively encourage people to write their code in
>> English whereever possible, not one to allow non-ASCII identifiers,
>> which might even do the opposite.
> 
> There is no reason to encourage or discourage people in which language 
> to write their code. 

There is, because code sharing is generally a good thing. If you don't
think it is, then we'll just have to agree to disagree on that point.

> Code that's meant to be shared makes just a tiny
> percentage of all the code written right this moment.
> 
> This "ready to be shared" code is neither better nor worse than 
> "closed" german or chinese-only code.

The implementaton of this PEP would not make Chinese-only Python code
possible. It would only make a Chinese-English gibberish without ASCII
transliteration possible. Also, alot of code that starts out as "closed"
and not meant to be shared is shared at some point (this is how we got
Zope, AFAIK), and this is a thing that should be encouraged.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
>> Identifiers which my terminal cannot even display surely
>> are not very readable.
> 
> This PEP is not about you. It's about people who write in their native 
> language and who are forced to use a dodgy transcription from 
> characters of their own language to ASCII.

It is impossible to write Python in a native language other than English
even with the implementation of this PEP. All you get is a weird mixture
of English identifiers from various libraries and identifiers in your
native language. And even if you consider that more clear and readable
than English-only Python code, the fact that it discourages code sharing
remains.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>> 1) Which additional potential for bugs and which hindrances for
>> code-sharing do you see with the with-statement?
> 
> I'm not sufficiently used to it to understand it immediately when I read it.

http://www.python.org/dev/peps/pep-0343/
It is not that hard to grasp.

> So I would have to look deeper into patches that use it, for example, and
> couldn't accept them at first look. Plus, some editors do not highlight it as
> a Python keyword. So it should have been rejected.

Support for highlighting that is easily added, contrary to support for
displaying all possible Unicode glyphs, let alone typing them in easily.

>> 2) The with-statement does have proven substantial benefits, IMO.
> 
> Not to me. I don't use it, so no-one should. 

Now you are starting to troll?

> And since it does not make sense
> in public projects, it should also be forbidden in in-house projects.

It does make alot of sense in public projects, since it actually *does*
make the code clearer. A programmer who does not understand it at first
can easily find and understand its documentation. The same is *not* true
for things like Kanji glyphs and the like.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>> I think your argument about "isolated projects" is flawed. It is not at
>> all unusual for code that was never intended to be public, whose authors
>> would have sworn that it will never ever be need to read by anyone
>> except themselves, to surprisingly go public at some point in the future.
> 
> Ok, but how is "using non-ASCII identifiers" different from "using mandarin
> tranliterated ASCII identifiers" in that case?

1) Transliterated ASCII identifiers do not have problems such as not
displaying at all and not being easily possible to type.

2) I consider transliterated ASCII identifiers a bad idea, but it is
virtually impossible to prohibit them at the language level.

> Please try to understand what the point of this PEP is.

Please try to understand that the fact that certain bad practices are
possible today is no valid argument for introducing support for more of
them!

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Thorsten Kampe schrieb:
> Because keywords are not meant meant to extended or manipulated or 
> something similar by the programmers. Keywords are well known and only 
> a limited set of words. That's why you can't use keywords as 
> identifiers.

This is true for keywords, but not for the stdlib. Are you suggesting
that the stdlib should be "internationalized"?

> There really is no difference to allow strings or comments in non-
> english languages and non-ASCII characters.

Comments in a non-English language are a bad idea. And of course there
is a difference between strings (data) and identifiers (program logic).

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
>>> Admittedly, it's done in Java, but why should Python fail to support unicode
>>> identifiers in the way Java does?
>> Your example does not prove much. The fact that some people use
>> non-ASCII identifiers when they can does not at all prove that it would
>> be a serious problem for them if they could not.
> 
> Are we trying to prove that?

IMO, if you cannot prove it, the PEP should be rejected, since that
would mean it introduces new problems without any proven substantial
benefits.

> And, would we have serious problems and people running from Python if Python
> 2.5 did not integrate the "with" statement?

1) Which additional potential for bugs and which hindrances for
code-sharing do you see with the with-statement?

2) The with-statement does have proven substantial benefits, IMO.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> René Fleschenberg wrote:
>> Programming is such an English-dominated culture that I even "think" in
>> English about it.
> 
> That's sad.

I don't think so. It enables me to communicate about that topic with a
very broad range of other people, which is A Good Thing.

>> My experience is: If you know so little "technical" English that you
>> cannot come up with well chosen English identifiers, you need to learn
>> it.
> 
> :) This is not about "technical" English, this is about domain specific
> English. How big is your knowledge about, say, biological terms or banking
> terms in English? Would you say you're capable of modelling an application
> from the domain of biology, well specified in a large German document, in
> perfect English terms?

As I have said, I don't need to be able to do that (model the
application in perfect English terms). It is better to model it in
non-perfect English terms than to model it in perfect German terms. Yes,
I do sometimes use a dictionary to look up the correct English term for
a domain-specific German word when programming. It is rarely necessary,
but when it is, I usually prefer to take that effort over writing a
mixture of German and English.

> And: why would you want to do that?

1) To get the broadest possible range of coworkers and maintenance
programmers.

2) To be consistent. The code is more beautiful if it does not
continously jump from one language to another. And the only way to
achieve that is to write it all in English, since the standard library
and alot of other stuff is in English.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> René Fleschenberg wrote:
>> you have failed to do that, in my opinion. All you have presented are
>> vague notions of rare and isolated use-cases.
> 
> I don't think software development at one of the biggest banks in Germany can
> be considered a "rare and isolated use case".

And that software development at that bank is not done in Python because
Python does not support non-ASCII identifiers? Can you provide a source
for that?

> Admittedly, it's done in Java, but why should Python fail to support unicode
> identifiers in the way Java does?

Your example does not prove much. The fact that some people use
non-ASCII identifiers when they can does not at all prove that it would
be a serious problem for them if they could not.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> Sounds like high time for an editor that supports the project team in their
> work, don't you think?

I think your argument about "isolated projects" is flawed. It is not at
all unusual for code that was never intended to be public, whose authors
would have sworn that it will never ever be need to read by anyone
except themselves, to surprisingly go public at some point in the future.

Moreover, wether it uses ASCII-only identifiers or not might actually be
a factor in deciding wether it can then become useful for the community
as a whole or not.

If only some few projects that are so very very isolated from the rest
of the world profit from the change this PEP proposes, then it should
IMHO be feasible to require them to use a special Python branch. That
would keep the burden of all the possible problems away from the rest of
the Python community.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> "go to" is not meant for clarity, nor does it encourage code readability.

Some people would argue that position.

> But that's what this PEP is about.

IMHO, this PEP does not encourage clarity and readability, it
discourages it. Identifiers which my terminal cannot even display surely
are not very readable.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
> 
>> A Python
>>   project that uses Urdu identifiers throughout is just as useless
>>   to me, from a code-exchange point of view, as one written in Perl.
> 
> That's because you can't read it, not because it uses Unicode. It could 
> be written entirely in ASCII, and still be unreadable and impossible to 
> understand.

That is a reason to actively encourage people to write their code in
English whereever possible, not one to allow non-ASCII identifiers,
which might even do the opposite.

>> - Unicode is harder to work with than ASCII in ways that are more
>> important
>>   in code than in human-language text. Humans eyes don't care if two
>>   visually indistinguishable characters are used interchangeably.
>>   Interpreters do. There is no doubt that people will accidentally
>>   introduce mistakes into their code because of this.
> 
> That's no different from typos in ASCII. There's no doubt that we'll give 
> the same answer we've always given for this problem: unit tests, pylint 
> and pychecker.

Maybe it is no different (actually, I think it is: With ASCII, at least
my terminal font can display all the identifiers in a traceback), but
why do you want to create *more* possibilities to do mistakes?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> My personal take on this is: search-and-replace is easier if you used well
> chosen identifiers. Which is easier if you used your native language for them,
> which in turn is easier if you can use the proper spellings. 

I strongly disagree with this. My native language is German, and I do
*not* find it easier to find well chosen identifiers using German. Not
at all. Quite the opposite.

Programming is such an English-dominated culture that I even "think" in
English about it. When I want to explain something related to Computers
to German "non-techies", I often have to think about an appropriate
German word for what I have in mind first. Using the familiar English
term would be alot easier.

My experience is: If you know so little "technical" English that you
cannot come up with well chosen English identifiers, you need to learn
it. If you don't, you will not be able to write decent programs anyway.
All the keywords are in English, all of the standard library is in
English, most of the documentation is only available in English, almost
all third party modules' interfaces are in English.

Any program that uses non-English identifiers in Python is bound to
become gibberish, since it *will* be cluttered with English identifiers
all over the place anyway, wether you like it or not.

The point is: Supporting non-ASCII identifiers does *not* allow people
to write programs "using their native natural language". For that, you
would also have to translate the standard library and so on.

meincsv = csv.reader(open("meinedatei.csv"))
for zeile in meincsv:
for eintrag in zeile:
print eintrag.upper()

Even in that little trivial code snippet, you need to understand stuff
like "reader", "open", "for", "in", "print" and "upper". Mixing in the
German identifiers is both ugly and unnecessary.

> For example, how many German names for a counter variable could you come up
> with? Or english names for a function that does domain specific stuff and that
> was specified in your native language using natively named concepts? Are you
> sure you always know the correct english translations?

I don't need to know the perfect English translation, just one that is
understood by anyone who knows enough "Programming English", which is
just about any programmer in the world.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> Ok, but then maybe that code just will not become Open Source. There's a
> million reasons code cannot be made Open Source, licensing being one, lack of
> resources being another, bad implementation and lack of documentation being
> important also.
> 
> But that won't change by keeping Unicode characters out of source code.

Allowing non-ASCII identifiers will not change existing hindrances for
code-sharing, but it might add a new one.

IMO, the burden of proof is on you. If this PEP has the potential to
introduce another hindrance for code-sharing, the supporters of this PEP
should be required to provide a "damn good reason" for doing so. So far,
you have failed to do that, in my opinion. All you have presented are
vague notions of rare and isolated use-cases.

> I'm only saying that this shouldn't be a language restriction, as there
> definitely *are* projects (I know some for my part) that can benefit from the
> clarity of native language identifiers (just like English speaking projects
> benefit from the English language). And yes, this includes spelling native
> language identifiers in the native way to make them easy to read and fast to
> grasp for those who maintain the code.

If a maintenance programmer does not understand enough English to be
able to easily cope with ASCII-only identifiers, he will have a problem
anyway, since it will be very hard to use the standard library, the
documentation, and so on.

--
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Anders J. Munch schrieb:
> There's any number of things to be done about that.
> 1. # -*- encoding: ascii -*-

This would limit comments and string literals to ASCII, too. I use "-*-
coding: utf-8 -*-" in all of my code and I am still against this PEP.

It is useful to be able to spell my own name correctly in a comment. It
is not useful to do so in a Python identifier.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Steven D'Aprano schrieb:
> How is that different from misreading "disk_burnt = True" as "disk_bumt =
> True"? In the right (or perhaps wrong) font, like the ever-popular Arial,
> the two can be visually indistinguishable. Or "call" versus "cal1"?

That is the wrong question. The right question is: Why do you want to
introduce *more* possibilities to do such mistakes? Does this PEP solve
an actual problem, and if so, is that problem big enough to be worth the
introduction of these new risks and problems?

I think it is not. I think that the problem only really applies to very
isolated use-cases. So isolated that they do not justify a change to
mainline Python. If someone thinks that non-ASCII identifiers are really
needed, he could maintain a special Python branch that supports them. I
doubt that there would be alot of demand for it.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Marc 'BlackJack' Rintsch schrieb:
> You find it in the sources by the line number from the traceback and the
> letters can be copy'n'pasted if you don't know how to input them with your
> keymap or keyboard layout.

Typing them is not the only problem. They might not even *display*
correctly if you don't happen to use a font that supports them.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

Stefan Behnel schrieb:
> I agree that code posted to comp.lang.python should use english identifiers
> and that it is worth considering to use english identifiers in open source
> code that is posted to a public OS project site. Note that I didn't say "ASCII
> identifiers" but plain english identifiers. All other code should use the
> language and encoding that fits its environment best.

Unless you are 150% sure that there will *never* be the need for a
person who does not know your language of choice to be able to read or
modify your code, the language that "fits the environment best" is English.

I simply doubt that the problem which this PEP wants to solve actually
exists. If you know so little English that you really need non-ASCII
identifiers, you will have a very hard time programming Python anyway.

My native language is German, and in code I cooperate on with other
Germans, I still use English identifiers, even if I am "quite sure" that
no non-German will ever have to read the code. It also makes it easier
and more beautiful for me if my code uses the same natural language as
the stdlib and third party modules do. I do not need non-ASCII
characters in Python identifiers.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Do other Python GUI toolkits require this?

[René Fleschenberg]

Antoon Pardon schrieb:
>> Who says the axes are labeled "familiarity" and "learning period"?   I
>> just assume they are labeled (y-axis) "Effort" and (x-axis) "Knowledge"
>> (or "skill" or ).  
> 
> You can assume all you want, but no serious person processing numbers
> would choose axes like that.

The vast majority of world population is not into "processing numbers",
so why should they care?

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confirm password for logged in user

[René Fleschenberg]

André Wyrwa schrieb:
> I'm wondering, though, if there isn't ANY way to have the password
> confirmed for the user that is already logged in. Please note the
> difference, i don't want to write some kind of login functionality. The
> user is already authenticated, i just want to have a typed in password
> checked agains the already logged in users password.

It is not possible to check a password against the shadow file without
having root privileges. Neither with nor without PAM.

Whyt you can do is install (or write yourself) a small program that
checks the password for you. That program must run as root (be installed
with suid root), but your daemon does not need to. The daemon calls the
external program to do the password check. http://unixpapa.com/pwauth
should work for your purposes.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: django learn

[René Fleschenberg]

Hi

Gigs_ schrieb:
> I want to learn to make web pages with django.
> I dont know nothing about HTML.
> 
> How much of HTML I need to know to be able to learn django well?

You need to get a profound knowledge of it, unless you have someone else
who does the HTML/Templating for your project. In that case, you could
probably get away with learning just the basics.

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is type object an instance or class?

[René Fleschenberg]

Hi

The article you read at
http://www.cafepy.com/article/python_types_and_objects is really good,
and the most comprehensive one I know about Python's object system. I
recommend that you read it as many times as you need to understand it.
It can be confusing -- just don't give up ;)

I will try to give some answers to your questions. Note that I assume we
are only speaking of new-style classes. Old-style classes are different,
but pretty uninteresting since there is little reason to use them in new
code.

Another note: As far as this stuff in Python is concerened, "type" and
"class" are, to my knowledge, basically just two different names for the
same thing.

JH schrieb:
> Hi
> http://www.cafepy.com/article/python_types_and_objects/
> I found that a type/class are both a subclass and a instance of base
> type "object".
> 
> It conflicts to my understanding that:
> 
> 1.) a type/class object is created from class statement
> 2.) a instance is created by "calling" a class object.

Why? I see no conflict here.

> A object should not be both a class and an instance at the same time.

It should.

1) Everything is an object.
2) Every object is an instance of a class.

>From this, it logically follows that every class should also be an
instance of a class. Classes are objects, and objects are instances of
classes.

> Further I found out there is a special type call "type" that is a
> subclass of base type "object". All other types are instances of this
> type.  Even base type "object" is an instance of this special type.
> 
> What is role of this type "type" in object creation?  Could someone
> there straighten this concept a little?

I) object' is the root of the inheritance hierarchy. All classes inherit
from 'object'. 'object' is its own baseclass. Also, all objects are
instances of 'object'.

II) 'type' is the root of the type hierarchy. All types (i.e. classes)
are subtypes of 'type'. 'type' is its own type.
Because 'type' also is, like everything else, an object, it is an
instance of 'object' (see I). Because it is a type object (a class), it
also is a subclass of 'object' (again, see I).

Objects are created by instantiating their class/type. Classes (also
called "type objects") are usually created by instantiating 'type'.

The object you instantiate to get a class is called that class'
"metaclass". One can just as well call it that class' type.

Unless you specify something else, the metaclass is 'type'. Sometimes it
can be useful to not use the default 'type' as a metaclass, but a class
that inherits from 'type'.

class A(type):
# Custom code here.
pass

class B(object):
__metaclass__ = A

type(B)# A. We overrode the metaclass.
type(type(B))  # 'type'. The default metaclass.


> For example (Python2.5):
> 
 issubclass(int, object)
> True

All classes are subclasses of 'object'. 'int' is a class, so it is a
subclass of 'object'.

 isinstance(int, object)
> True

All objects are instances of 'object', and 'int' is an object.

 print type(int)
> 

'type' is the default type for classes (the "metaclass"). In the case of
'int', that default was not changed.

 isinstance(int, type)
> True

Since all classes are subclasses of 'object' and 'object' is an instance
of 'type', all classes are instances of 'type'.

 issubclass(int, type)
> False

No reason why it should be. It could be, but it does not have to.

 issubclass(type, object)
> True

'type' is a class, all classes are subclasses of 'object'.

 isinstance(type, object)
> True

'type' is an object, all objects are instances of 'object'.

 isinstance(object, type)
> True

'object' is a class, all classes are instances of 'type'.


Hope this helps ;)

-- 
René
-- 
http://mail.python.org/mailman/listinfo/python-list