Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This question is mostly just about curiosity.
As a java programmer myself, I often get frustrated by all the dots on nested variables. (There is kind of a de facto standard in java that any line with a variable with more than 2 dots needs to be re-written). Is there anyway to "rename" a nested variable such that I don't have to type all the dots everytime?
For example
class MyClass():
def my_func():
if not self.app.arguments.foo:
self.app.arguments.foo = 'bar'
print self.app.arguments.foo
Is there a way to write this such that I don't have to type the full name self.app.arguments.foo everytime?
Second, what is the standard 'pythonic' way of using variables as such. Would standard python nomenclature say just use all the dots all the time?
Extra notes
As I said, this is more about curiosity. So lets assume that I do not have access to module b. In other words I can not (more like don't want to) write getter and setter methods.
Also note that the self is important. I know I can do a rename with an import, but you cant import self.
You can use a temporary variable for all but the last item in a chain:
b = self.a.b
if b.c:
b.c = 'foo'
print b.c
If you weren't assigning, you could go all the way to c.
This is a little bit faster as well as being easier to write. However, it may or may not be easier to read.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
This is not a problem I've encountered, but rather just a curiosity about best practices/style in python:
I see stuff like this quite often:
class A:
def __init__(self, qux):
"""...do whatever... maybe this is expensive - maybe it isn't - maybe I don't know if it's expensive"""
def get_baz(foo, bar=A(2)):
"""...do another thing..."""
return baz
I largely avoid function/method calls (like bar=A(2)) in function signatures, because this makes A.__init__ run on import. Do you think avoiding the running of code on import is best practice, or am I just OCD and it's totally fine to handle this on a case-by-case basis? I feel like there is an expectation (at least in the python community) that importing a package/module shouldn't take a significant amount of time/memory.
The common alternative to the above is slightly more verbose, but runs no extra code on import:
def get_baz(foo, bar=None):
if bar is None:
foo = A()
Which do you like more and why? Should I just not care?
(For context, I started thinking about this because importing an internal package at my company took 8 seconds, which was triggering.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In my test suite I have a file called "utils.py" in which I have assorted functions required by many of the tests. To accomplish this I created a "Utils" class and had all of the functions inside it.
A colleague, with more Python experience, insisted that there should be no such class and instead all of these functions should be top-level. Thus "Utils.get_feature_id()" became "get_feature_id()".
Would you concur with his assertion?
Robert
In this case, the only thing you are using the class for is to essentially have the "methods" within a namespace. I agree with your coworker, you could have these functions be top level, but kept in a module so they indeed get put in a namespace, e.g.
import utils
utils.get_feature_id()
Instead of the following, which would presume you marked all your methods as #staticmethod which again just adds an unnecessary layer.
import utils
utils.Utils.get_feature_id()
Yes. If a function doesn't access a self, it should most likely not be a method. You can use a full module if your goal was to arrange your functions in a distinct namespace. Python uses namespaces everywhere, so we need not shy away from global names like C++ tends to and Java enforces (effectively, because they're not that global after all).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm looking for a complete description of Python attribute lookup. I know there have been similar questions and there is this very nice introduction to the descriptor protocol. But it does not cover the entire lookup for example it does not elaborate on special methods.
Ideally, there would be a flowchart starting at x.y and then running through all possibilites including
is it lookup or assignment?
is x a class or an object (or for example a function if that makes a difference)?
is x a builtin if that's relevant?
does x have a __slots__ attribute?
does x have a __getattr__, __setattr__ or __getattribute__ method?
is y, the string a special attribute name
once y is resolved, does it have a __get__ attribute?
etc., etc., you get the idea.
I realise this is a lot of work, so if there are any promising submissions within 5 days from now I'm willing to offer a 250 rep bounty.
Reference version should be Python3.6 and there should be an effort made to demonstrate completeness as far as possible.
I'm sure such a flowchart would be tremendously useful for me and many others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am working on a Python project and since the instance variable names can be directly accessed by specifying class.variablename, I was wondering if it is recommended to implement getter functions for the same. I have not declared the variables as private.
In languages like Java, you implement getters and setters so that you do not need to change the class's interface if you want to add additional processing (such as value validation, access control, or logging) when getting or setting an attribute. This is particularly important if your classes will be used by applications you didn't write.
In Python, you can add code to attributes with #property without changing the interface, so you should do that instead. Use regular attribute access to start, and add #property later if you need to add a behavior.
Even then, keep your getter and setter functions simple. Attribute access is expected to be reasonably quick and you should avoid violating that expectation. If you need to do significant work to obtain a value, a method is appropriate, but give it a descriptive name: calculateFoo() rather than getFoo(), for instance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I wonder whether the recommended practice is to put init in the beginning of class definition or to put interface functions first:
class examp1:
def ifmethod1(self):
pass
def ifmethod2(self):
pass
def __init__(self):
pass
VS.
class examp1:
def __init__(self):
pass
def ifmethod1(self):
pass
def ifmethod2(self):
pass
A lot of people put it first, but every one can have their own opinion and you'll find arguments for both.
To me, being first is simply useful because it's helpful to know __init__ quickly.
In an effort to help coders of other languages grasp Python quickly, ibiblio.org says "__init__ is analogous to a constructor". In that spirit, it would often be put first — constructors in other languages are almost always listed first.
In one example, the Google style guide for Python, it is always listed first.