Dominoes posted:

You're catching the TypeError before it occurs; ie once you've gotten thing.foo, you have no more error checking, and 10 doesn't have any keys.

Dominoes posted:

@property makes methods look like properties; I think they're for writing Java-style code. I wouldn't use them, since they mask that calculations are being run.

Dominoes posted:

I'm not sure this is a good idea - you're trying to treat it as two different types of objects based on context. Here's a snippet that does what you ask, although as a function rather than a class.

[snip]

Not sure if this helps, but are you familiar with dict's get method? It'll return a default of your choice if it can't find the key.

Boris Galerkin posted:

Oh okay. This made me reconsider about using properties to begin with. It just seems a bit weird that Python is "a consenting adults language" where nothing is private and everything can be accessed and used, yet @property exists to seemingly make things read-only.

Boris Galerkin posted:

I don't see any harm or why it's a bad idea to be able to do this:

Boris Galerkin posted:

e: nevermind this only half works. __repr__ returns an actual Name object so I can't do things like "country.name+country.name['de']". Sad.

Boris Galerkin posted:

Because you write code to do things for you, not the other way around. Here's my lovely jumping through the hoops example:

https://repl.it/GP2U/0

code:

class Belgium(object):

    _names = {'en': 'Belgium',
             'de': 'Belgien',
             'nl': 'Belgie',
             'fr': 'Belgique',
             'default': 'Belgium'}

    def __init__(self):

        class Name(dict):
            def __repr__(self):
                return self['default']

        self.name = Name(self._names)

country = Belgium()

print('My name is {}'.format(country.name))
# >>> My name is Belgium

print('My name is also {}'.format(country.name['de']))
# >>> My name is also Belgien

I can understand if this isn't something that exists in Python. I can understand that this isn't "pythonic." But I want to understand why it's a bad idea to do this? I mean ignore the fact that I defined Name inside the init or whatever. I have no idea what __repr__ does but from a quick search it seems to be the thing that gets called when I just type the name of the class.

Typing "country.name_in_german" sounds like more of a hoop, and honestly making it a method and having to call "country.name()" is just ugly when 99% of the times I just need the default value. Plus the () implies function so isn't it semantically wrong? I'm not computing anything, I'm just getting something that already exists.

e: nevermind this only half works. __repr__ returns an actual Name object so I can't do things like "country.name+country.name['de']". Sad.

Boris Galerkin posted:

(but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed).

huhu posted:

Boris Galerkin posted:

Because it was just an example.

e: And also because I come from a procedural/imperative programming background (my first language was Fortran back when it was still FORTRAN [77]) and I've never learned anything else other than modern versions of Fortran and MATLAB so honestly I have no clue what the point of objects are or when and why I should use them.

I just think it's pretty neat to be able to do:

code:

new_tensor = old_tensor.rotate()

Instead of

code:

new_tensor = rotate_tensor(old_tensor, rotation_matrix)

But honestly the only reason I think the first one is neat is because it looks better to me. I really wasn't joking when I said I liked "foo.thing" better than "foo.thing()" because it looks better without the parenthesis (but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed).

The Zen Of Python posted:

Explicit is better than implicit.
Special cases aren't special enough to break the rules.

Boris Galerkin posted:

Because it was just an example.

e: And also because I come from a procedural/imperative programming background (my first language was Fortran back when it was still FORTRAN [77]) and I've never learned anything else other than modern versions of Fortran and MATLAB so honestly I have no clue what the point of objects are or when and why I should use them.

I just think it's pretty neat to be able to do:

code:

new_tensor = old_tensor.rotate()

Instead of

code:

new_tensor = rotate_tensor(old_tensor, rotation_matrix)

But honestly the only reason I think the first one is neat is because it looks better to me. I really wasn't joking when I said I liked "foo.thing" better than "foo.thing()" because it looks better without the parenthesis (but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed).

quote:

(but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed)

Boris Galerkin posted:

(but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed).

Boris Galerkin posted:

so honestly I have no clue what the point of objects are or when and why I should use them.

Boris Galerkin posted:

Because it was just an example.

e: And also because I come from a procedural/imperative programming background (my first language was Fortran back when it was still FORTRAN [77]) and I've never learned anything else other than modern versions of Fortran and MATLAB so honestly I have no clue what the point of objects are or when and why I should use them.

I just think it's pretty neat to be able to do:

code:

new_tensor = old_tensor.rotate()

Instead of

code:

new_tensor = rotate_tensor(old_tensor, rotation_matrix)

But honestly the only reason I think the first one is neat is because it looks better to me. I really wasn't joking when I said I liked "foo.thing" better than "foo.thing()" because it looks better without the parenthesis (but mostly because I don't think it's semantically correct to call a function to return a value that I've already computed).

QuarkJets posted:

Your points on the first codeblock are very good, and indeed that does look better and work better and it makes sense. But then consider this:

code:

new_tensor = old_tensor.rotate
new_tensor2 = old_tensor.rotate(rotation_matrix2)

Thermopyle posted:

Anyway, do you ever split your code into different files for reasons other than language-mandated reasons? The general reason you'd do that is one of the general reasons you'd use objects.

quote:

You talking about your background makes me think you might like learning Elm, as it's completely different from what you'res used to for completely different purposes, and it'll really expand your mind about what you can do with Python as you can implement a lot of the same functional ideas in Python.

quote:

Of course, OOP is full of stupid ideas as well. It's a good idea to become familiar with different paradigms like OOP, functional, etc so you don't end up just using what you know and missing out on better ways to solve problems.

Boris Galerkin posted:

code:

def rotate_tensor(tensor, rotation_matrix):
    A = tensor
    Q = rotation_matrix
    return Q*A*transpose(Q)

new_tensor = rotate_tensor(old_tensor, some_matrix)

vs

code:

class Tensor(object):

    def __init__(self, tensor, rotation_matrix):
    self.A = tensor
    self.Q = rotation_matrix

    def rotate(self, rotation_matrix=None):
    Q = rotation_matrix or self.Q
    return Q*self.A*transpose(Q)

old_tensor = Tensor(a_numpy_ndarray, rotmat)
new_tensor = old_tensor.rotate()

They both do the same thing. It's just more elegant looking to be able to call a rotate() method I think, but at the end of the day all I really care about is that the rotate method or rotate_tensor function gives me back a properly rotated tensor. Plus it's neat that I can assign the rotation matrix to the object already and not have to worry about passing the rotation matrix around anymore. That's the really cool part for me.

Boris Galerkin posted:

For reasons that I can't seem to articulate, this example doesn't make sense to me as something I would do. In my mind it's pretty clear that "rotate" is a function that does the rotation. It's a function, so I would be 100% fine with calling it like a function, eg old_tensor.rotate().

code:

# Call old_tensor to rotate itself against a rotation matrix and return the rotated tensor.
new_tensor = old_tensor.rotate()

# Call old_tensor to retrieve an already rotated tensor and return it.
# ... Maybe I pre-computed the rotated tensor in __init__ for better memory management.
# ... Maybe when I called the rotate() method it also saved a copy of it for retrieval later.
new_tensor2 = old_tensor.rotated

Boris Galerkin posted:

Yep of course. I split my code/functions into separate files/modules in a way that makes sense (e.g., functions that act on tensors go in tensors.py). I'm just having a hard time seeing the practical difference between these two though:

code:

def rotate_tensor(tensor, rotation_matrix):
    A = tensor
    Q = rotation_matrix
    return Q*A*transpose(Q)

new_tensor = rotate_tensor(old_tensor, some_matrix)

vs

code:

class Tensor(object):

    def __init__(self, tensor, rotation_matrix):
    self.A = tensor
    self.Q = rotation_matrix

    def rotate(self, rotation_matrix=None):
    Q = rotation_matrix or self.Q
    return Q*self.A*transpose(Q)

old_tensor = Tensor(a_numpy_ndarray, rotmat)
new_tensor = old_tensor.rotate()

They both do the same thing. It's just more elegant looking to be able to call a rotate() method I think, but at the end of the day all I really care about is that the rotate method or rotate_tensor function gives me back a properly rotated tensor. Plus it's neat that I can assign the rotation matrix to the object already and not have to worry about passing the rotation matrix around anymore. That's the really cool part for me.

Thermopyle posted:

There's a not-entirely-unjustified school of thought in python-land that too many developers pull out classes unnecessarily.

huhu posted:

This code

code:

import sys

#TB I need to setup virtual env

activate_this = '/home/huhu/.virtualenvs/wv_venv/bin/activate_this.py'
exec(activate_this, dict(__file__=activate_this))

sys.path.append('/home/tbumgarner/webapps/chs_web_viewer/web_viewer')
import app as application

is leading to this error. I for the life of me have no idea why this is happening.

code:

[Sun Mar 12 20:10:50.924896 2017] [wsgi:error] [pid 7297:tid 139694796572416] [remote 127.0.0.1:50826]

     exec(activate_this, dict(__file__=activate_this))
   File "<string>", line 1
     /home/huhu/.virtualenvs/wv_venv/bin/activat$
     ^
 SyntaxError: invalid syntax

I was following this tutorial and had to change the execfile() command for python3.

Dominoes posted:

Objects are nice if you're defining something that can be thought of as a datatype, or if you're using a collection of similar items.