Python classes?

Let's say I have the following code in Python:


class dong():
   x = None
   def __init__(self):
      pass
   def dat_func(self):
      print x.upper()

We know that Python is dynamically typed. So I can change the type of the class member x at run-time when ever I want. That means that for every method in a python class where you have code that depends on the type of the class member x you have to check the integrity of x such that the type of x is what you want it to be.

This code demonstrates the problem.
[code]
x = dong()
x.x = 10
x.dat_func() #error, dat_func expects a str object.

For every fucking class member, any time you want to use it . . . You have to check the type to remind retarded developers that they're wrong.

Now if Python had private members it would be easier, but it fucking doesn't.

Prog 1, Python 0.

What if there is a thread that changes the type of x after you check the integrity of x but before you use it :\

>>2
That would be a failure to consider safe threading (the programmer is to blame most likely) and Python would only be at fault for doing what it was asked to do.

This is what Java programmers actually believe!
Not >>1, though, I don't hope. Though it was nice of you not to play the dynamic/weak typing confusion card.
I shall respond in turn: You should practically never be checking the type before you use something; duck typing and EAFP are tenets of Python programming. Your example is already going to fail, noisily and obviously. An type check isn't going to do shit for you or anyone else.
If you really needed the control, e.g. because an easy mistake to make could cause silent data corruption (you bad designer, you!), you should use a property and check the type at assignment.

>>4
OP here, am a faggot. Please explain duck typing and EAFP.

That piece of code won't work even if dong.x is of the correct type, in dat_func you're referring to x like it was a global variable, which it of course isn't.

>>6
Yes, OP forgot the self but that's not the point here.

>>5
I shall refer to the Python documentation, that explains it at least as well as I would:
http://docs.python.org/py3k/glossary.html#term-duck-typing

Simply put, you shouldn't need to check the type. If it has all necessary properties (even if it's not exactly the type you expected it to be), everything will work. If not, you will get an error when the code tries to use it anyway.

Do I need to have autism to be a good coder?

>>9
gtfo vipper

>>9
Let's not have another fucking thread about autism. Enough with the autism. It's a /b/ fad or something. It's nothing to do with us.

>>11
Do you have autism?

>>7

It shouldn't be self either, x is a static variable of dong, so you should refer to it as dong.x. The reason you could use self here is because you defined it earlier with the x.x = stmt statement.

is this thread over yet?
you're talking about scope and forgetting yourself

>>10
Its spelled VIPPER and you seem like an imageboardtard, please go away.
>>9
Ofcourse
>>11
Now you should know by now that World4ch is filled with autists, that is the norm here.

>>15
I said GET THE FUCK OUT, YOU FUCKING ``VIPPER''.

>>16
Or what?

>>17
Or else I shall conjure the spirits of the computer upon you with my spells, infidel!

>>18
No Anonymous, you are the infidels.

And then VIPPER was a JEW.

I started the VIPPER hating.

<--- check my dubs

thisThread = None
i simply don't understand why OP would try to call toUpper() on anything that's not expected to be a string.


#!/usr/bin/python

class dClass():
    x = None
    def __init__(self):
        pass
    def foo(self,x):
        return str(x).upper()
    def bar(self):
        try: return self.x.upper()
        except: print "no"
if __name__=="__main__":
    dong = dClass()
    dong.foo(9)
    dong.x=82384
    print dong.bar()
    dong.x="lowercase"
    print dong.bar()
    print dong.x

so what's the problem?

>>23
The indentation. And the non-private privates.

’‘AmIdoingitrightguize?“” lol vipper…
25 get
haha dubsz
Python is teh gay

>>24
it was a proof of concept on how OP's post didn't make sense, it's not meant to be functional.
>>25
nice quotes


^{NO SIDE EFFECTS}____{NO EXCEPTIONS}