How to get/set class attributes in Python

[Peter Dembinski]

[snap]

Nope. Python *is* typed. But it doesnt confuse implementation
with semantic.

Python is typed. And its type system may look strange for anyone who
did only Java or C++ programming before :>

 

[Bruno Desthuilliers]

Chris Spencer a écrit :

I was providing the original poster with a simple way to ensure
appropriate type.

s/appropriate type/specific implementation/

Hint : the appropriate type for print >> XXX is "whatever has a
'write(anything_that_can_be_coerced_to_a_string)' method".

 

[Chris Spencer]

Chris Spencer a écrit :



s/appropriate type/specific implementation/

Hint : the appropriate type for print >> XXX is "whatever has a
'write(anything_that_can_be_coerced_to_a_string)' method".

Certainly, although now I think you're splitting hairs over my
terminology. Let's synchronize our wording with a point made in the
Python docs. Section 2.1 of the Library Reference recommends that the
builtin function isinstance() be used for testing the object type. Does
this then mean that "type" refers to the class of an object? In which
case, wouldn't "interface" refer to a collection of methods, that when
present in a class create an implementation?

Chris

 

[Chris Spencer]

Python is typed. And its type system may look strange for anyone who
did only Java or C++ programming before :>

Of course, in that Python is dynamically typed as opposed to the static
typing of Java or C++. Please excuse my previous mis-wording

Chris

 

[Peter Dembinski]

Of course, in that Python is dynamically typed as opposed to the
static typing of Java or C++. Please excuse my previous mis-wording

Mis-wording?

 

[Chris Spencer]

Mis-wording?

I previously said Python was "untyped", when it's more accurate to say
"dynamically typed".

 

[Axel Straschil]

Hello!

You can 'hide' you getsetters using a property attribute[1]:

For me, the property attribute is a beast:

class A(object):
def getP(self): return 'A'
p = property(getP)
class A2(A):
def getP(self): return 'A2'
a = A()
a2 = A2()
print a.getP(), a2.getP()
print a.p, a2.p

So, property is instance-level super() tool ;-)

Lg,
AXEL.

 

[Terry Hancock]

I really think the problem is that you are trying to use
techniques whose only reason for existing is that they make
up for deficiencies in other languages:

For example, the *reason* for the Java or C++ use of get/set
methods is to allow for the future possibility of needing to
make those operations dynamic. Python solves this by
allowing you to create get/set methods *only when needed*
by using "properties", using exactly the same interface as
provided by ordinary attributes. Thus there is no need to
artificially add get/set methods in the general case.

This results in much cleaner and more concise code.

The *reason* for taking so much care that a variable is of
the right type in classes in C++ or Java is because the
program will crash if they are not. In Python, you would
be better served to:

1) Assume the variables are of a sensible type (not
necessarily the one you expected, though), and provide
exception handling to catch the case where their interface
does not match what you expect.

2) Check for the specific interface methods that you need,
only (if all you plan to do is read from a "file", you
shouldn't worry about whether the "file" object you've been
handed actually has a "write" method or not).
This is often called "duck typing".

3) Use "interfaces" (either from Zope or PyProtocols) to
specify the required *behavior* (not type).

Let's face it -- should it matter if you "are a programmer"
or only if you "can program"? This is the difference in
philosophy behind a dynamically-typed language like
Python and a statically typed one like Java.

 

[Kalle Anke]

1) Assume the variables are of a sensible type (not
necessarily the one you expected, though), and provide
exception handling to catch the case where their interface
does not match what you expect.

The problem I have with this is that I might discover an error at runtime
instead of compile time, this means that I need to really exercise all
possible test cases to make sure that I've covered everything (which of
course is a good thing) but it would be easier to discover this at "compile
time".

(note: I'm not trying to change Python, only that to me statically typing has
it advantages also)

Let's face it -- should it matter if you "are a programmer"
or only if you "can program"? This is the difference in
philosophy behind a dynamically-typed language like
Python and a statically typed one like Java.

I don't really understand what you're meaning (English isn't my native
language as you probably already have discovered)

 

[Mike Meyer]

The problem I have with this is that I might discover an error at runtime
instead of compile time, this means that I need to really exercise all
possible test cases to make sure that I've covered everything (which of
course is a good thing) but it would be easier to discover this at "compile
time".

But static typing only catches *some* of the errors that might
occur. Other errors will occur at run time even with static typing -
so you need to really exercise all possible test cases to make sure
you've covered everything in any case.

(note: I'm not trying to change Python, only that to me statically typing has
it advantages also)

Static typing saves you some time by catching a small subset of
programming errors at compile time. On the other hand, it costs you
time by forcing you to declare a type for - well, everything that
you're going to catch errors for.

It's not clear which cost is larger.

<mike

 

[Terry Hancock]

The problem I have with this is that I might discover an error at runtime
instead of compile time, this means that I need to really exercise all
possible test cases to make sure that I've covered everything (which of
course is a good thing) but it would be easier to discover this at "compile
time".

The Python solution to this problem is called "unittest". It is
at least as easy to do unit testing in Python as it is to properly
handle type-checking in C or Java.

I don't really understand what you're meaning (English isn't my native
language as you probably already have discovered)

(Actually no, you're quite fluent, AFAICT). I was making
an analogy:

Requiring a variable to be, say, a "float" is like insisting that
only people with the job title "Programmer" be allowed to
see the language documentation.

In both situations, real life will confront you with situations
where you will wish that you had been more tolerant. Lots
of us are not "Programmers", but we do quite a bit of programming.

Likewise, you'll be happier to discover that ints or complex
numbers work with your code too, without having to jump
through hoops to make it happen.

I find the biggest problem coming to Python from a language
like C, C++, or Java is that you overthink things and try to
do them the hard way. A lot of times, you find out that the
"Python way" to do the thing is so blindingly obvious that
it just didn't occur to you that it could be that simple.

 

[Kalle Anke]

I find the biggest problem coming to Python from a language
like C, C++, or Java is that you overthink things and try to
do them the hard way. A lot of times, you find out that the
"Python way" to do the thing is so blindingly obvious that
it just didn't occur to you that it could be that simple.

It's very possible that this is the case, I'm not experienced enough in
Python yet to have a opinion on this yet. I tend to think in terms of larger
systems with several programmers ... instead of what I'm actually doing
writing code for my own pleasure.

But I'm learning new stuff every day ... so in 6 months I'll probably have an
opinion.

 

[Simon Brunning]

Oops - I thought I cancelled that post when I relized I was saying nothing,

Would that everyone cancelled their posts when they realised that they
weren't saying anything. ;-)