Page 10 of 16

Re: Python tricks

Posted: July 20th, 2019, 7:37 pm
by ISayMoo
Thanks!

Re: Python tricks

Posted: July 24th, 2019, 9:19 pm
by Cuchulainn
Duck typing harmful?Image

Re: Python tricks

Posted: July 25th, 2019, 11:08 pm
by ISayMoo
There is no Python API for Unity.

Re: Python tricks

Posted: July 26th, 2019, 4:25 pm
by Cuchulainn
There is no Python API for Unity.
like this Unity??

https://code.visualstudio.com/docs/other/unity

Re: Python tricks

Posted: July 26th, 2019, 4:44 pm
by ISayMoo
Yes, the game engine.

Re: Python tricks

Posted: July 29th, 2019, 10:25 am
by Cuchulainn
I have not seen much written on the topic of robustness and reliability of Python code and 'interaction' with (external) libraries. Some thoughts.

1. Defining contracts
2. Exception handling
3. Exception handling in a multi-language application (e.g. Calling C++ from Python).
4. Standardisation in the Python library developer community (is my domain error the same as your domain error?)

Re: Python tricks

Posted: July 29th, 2019, 7:43 pm
by ISayMoo
1. Docstrings, type annotations (relatively new thing), assertions and explicit checks in conditional statements. The standard way of handling violations of contracts by the caller is to throw an exception (usually TypeError or ValueError).
2. I find Python exceptions very easy to use. The standard exception class hierarchy is convenient to use. I rarely have the dilemma "which type should I throw?"
3. I don't know, but probably not easy. Is it easy in any other language not running in a common VM?
4. Python has a lot of "idioms" which people standardise on: https://en.wikibooks.org/wiki/Python_Programming/Idioms

Re: Python tricks

Posted: July 29th, 2019, 7:45 pm
by ISayMoo
PS. But I think I'm teaching the grandmother to suck eggs. You're selling a course on Python. Surely you know all this already?

Re: Python tricks

Posted: July 29th, 2019, 9:13 pm
by Cuchulainn
With the possible exception of 3, things become interesting when you write a non-trivial application using multiple libraries.

// I am also thinking out loud.

Re: Python tricks

Posted: July 30th, 2019, 6:54 am
by ISayMoo
I am working on a very large Python codebase at work. Things are fine, because we are strict about code consistency, dependency management and having a single version of everything (no "DLL hell").

Re: Python tricks

Posted: July 31st, 2019, 10:09 am
by Cuchulainn
I am working on a very large Python codebase at work. Things are fine, because we are strict about code consistency, dependency management and having a single version of everything (no "DLL hell").
An issue with large systems is managing the dependency graph, e.g. when a well-known public data structure change how does it impact the modules etc.?

I really like how easy modules and packages are in comparison to C/C++ (which does not support modules). But how good are they with Information Hiding?

Re: Python tricks

Posted: July 31st, 2019, 10:10 am
by Cuchulainn
I am working on a very large Python codebase at work. Things are fine, because we are strict about code consistency, dependency management and having a single version of everything (no "DLL hell").
An issue with large systems is managing the dependency graph, e.g. when a well-known public data structure change how does it impact the modules etc.?

I really like how easy modules and packages are in comparison to C/C++ (which does not support modules). But how good are they with Information Hiding? (no private data in Python).

Re: Python tricks

Posted: July 31st, 2019, 10:42 am
by ISayMoo
I really like how easy modules and packages are in comparison to C/C++ (which does not support modules). But how good are they with Information Hiding? (no private data in Python).
There are private data in Python. They are denoted by convention by an underscore in front of variable name. Any linter can catch this.

Re: Python tricks

Posted: July 31st, 2019, 10:44 am
by ISayMoo
I am working on a very large Python codebase at work. Things are fine, because we are strict about code consistency, dependency management and having a single version of everything (no "DLL hell").
An issue with large systems is managing the dependency graph, e.g. when a well-known public data structure change how does it impact the modules etc.?
You scan the build files, find all build units affected by the changes in the build unit(s) the module belongs to, rebuild them, and run test build units (i.e. unit tests) which depend on them.

Re: Python tricks

Posted: July 31st, 2019, 11:14 am
by Cuchulainn
class PointTest:  
# Counterexample: class with "private" attributes
    def __init__(self,x=-10, y=0): #default values
        self.move(x,y)

    def move(self, x, y):    
        self._x = x
        self._y = y
        self.__x = x
        self.__y = y

    def printI(self):
         print (self._x, self._y)
  
    def printII(self):
         print (self.__x, self.__y)

pp = PointTest(1,2)
pp._x = -1; pp._y = -2
print("Private in name only? (PINO)")
print(pp._x); print(pp._y); #-1, -2
#print(pp.__x); print(pp.__y); #AttributeError

pp.printI() #(-1,-2)
pp.printII() #(1,2)

ISayMoo:
I really like how easy modules and packages are in comparison to C/C++ (which does not support modules). But how good are they with Information Hiding? (no private data in Python).
There are private data in Python. They are denoted by convention by an underscore in front of variable name. Any linter can catch this.
Single underscore is still public; seems double underscore is needed.