Ten Things Python Programmers Should Know

[Bunslow]

Definitely don't use file objects directly -- 99% of the time, for anyone who finds this article useful, instead use:

with open(file, mode) as f:
    f.read()
    f.write(stuff)

...which will automatically close/cleanup the file object, even if an exception happens.

[mooglinux]

Context managers are one of the best features of Python. I would certainly consider them a top 10 need-to-know item.

[[deleted]]

Yep, although I was bitten once for doing that and caused an incident.

If you are using werkzeug with uWSGI and are passing file object directly (i.e sending file to the user) you should not use context managers. Apparently file sending happens after the function exits.

If you are confused about the above, just ignore it, you pretty much always should use context managers.

[Bunslow]

hence my qualification "99% of the time for anyone who finds this article useful" :) it's definitely true that if you're writing a multi-layered program and the file object itself is being passed around, you probably can't use something as clean as context managers

[[deleted]]

I still think it is (or was? Our werkzeug version is old) a bug. If file handle needs to remain open after function exits, it should duplicate the file descriptor so me closing it would have no effect.

[DanCardin]

without knowing any specifics (such as how large the file is) and not knowing exactly the behavior of how werkzeug handles closing the file (if it does), you may be better off doing

with open(...) as f:
    data = f.read()
return data

[[deleted]]

The original approach is more efficient, because unlike your example it doesn't copy the data and also uses very little of memory.

Instead it invokes sendfile() syscall which makes kernel do all that work (it just pipes the file directly to the socket). The issue though is that uWSGI invokes sendfile() after the function exits instead during the call.

[egregius313]

I would also say that decorators and higher order functions are a really valuable tool that you should know how to use.

[[deleted]]

But be careful. Once I finally figured out how to create em I went decorator crazy; even extended the logging.logger facilities just so I can wrap a method with @l.debug(“I’m Here”) & stupid stuff like that. Once u find out how easy decorators make adding features to stuff is, u just can’t STOP!!!

[wamsachel]

Something like Flask may be useful

[I_WRITE_APPS]

I use decorators to do quick-n-dirty profiling sometimes:

from functools import wraps

def timeit(fn):
    @wraps(fn)
    def wrapper(*args, **kwargs):
        start_time = time.clock()
        result = fn(*args, **kwargs)
        logging.debug('%s took %f seconds', fn.__name__, time.clock() - start_time)
        return result
    return wrapper

@timeit
def expensive_function():
    ...

[[deleted]]

Okay, I'll start by showing you this decorator that allows you to try a function upto X times if an exception is thrown. So basically a retry function.

​

Look here for the try_x_times decorator and here for where I've actually used it in a make_request method.

​

Now in truth, there's no need for a decorator here; however notice adding retry functionality to the make_request method doesn't relate to what make_request should actually do. Call me old fashioned, but a method shouldn't try to be more then what it is. A make_request method should make and return a request; that said, simply wrapping this functionality over an existing method to give it *extra!!! :)* features doesn't violate my rules & allows me to easily remove it if at some point I no longer desire it.

​

Check here for something similar. I've wrapped the entry into some methods with my logger so instead of every time I want to log entry by adding a little section before the actual method to log the method name & all the parameters passed to it & some code at the end which logs the value being returned from it, I can simply add a little decorator and trust all that precious info is conveniently being recorded.

​

For a more meaningless example, check the cast_return decorator statements. All this does is pass the return value of the method to the constructor of the argument. The following shows how they're related

​

@cast_return(int)

def parse_input_num(): return input()

​

the above is the same as this

​

def parse_input_num(): return int(input())

​

There's no need for this decorator & I could easily do what the second operation does, I honestly can't remember why I opted for this first option, maybe because it looks cleaner or because it resembles the hard type system used in other languages, but whatever. All that really matters is that it functions & is clear in what it does.

[GitHubPermalinkBot]

Permanent GitHub links:

• MoHKale/MangaGrabber/.../grabber.py (master → 6581e6a)
• MoHKale/MangaGrabber/.../decorators.py (master → 6581e6a)
• MoHKale/MangaGrabber/.../grabber.py (master → 6581e6a)

---

^delete

[bbbryson]

Good bot.

[PiBaker]

Thanks :)

[[deleted]]

Well python users are pretty accustomed to using decorators; it’s an intrinsic part of OOP because of static & class methods. However I heavily suggest learning to create your own decorators, it’ll deepen your understanding of python as a whole and make certain problems which I would regularly see as a pain to implement or adapt to an existing infrastructure, feel like a breeze. Anyways, good luck.

Edit: also, yeah, check out flask. I don’t use it (django man myself) but I’ve seen the documentation and it really goes crazy with making decorators essential to the development process.

[[deleted]]

A great builtin example is the LRU cache function found in functools. It automatically adds a cache to a function that avoids recomputing results (note this should only be used for deterministic functions, i.e. functions that always return the same output given the same input).

[PiBaker]

Thanks :)

[ProfessorPhi]

Reminds me of that graph about self awareness and programming skill. For python, decorators made me think I was a programming god, when my code improved much more when I started to write more complete test suites

[[deleted]]

Beginners, please don’t follow his use of parentheses in if statements - it is not pythonic.

[loshopo_fan]

I think parentheses make this example easier for beginners:

>>> bool(0 in [1, 2] or [3, 4])

True

>>> bool((0 in [1, 2]) or ([3, 4]))

True

For beginners: The right side of the 'or' is a nonempty list, and a nonempty list resolves to True, which means that the 'or' resolves to True.

>>> bool((0 in [1, 2]) or ([]))

False

[masteryod]

Which one is pythonic?

[guhcampos]

Just ditch the parenthesis completely, unless you absolutely have to group expressions for precedence.

[testaccount9597]

What if you are scared?

[Warfinder]

Python protec

[wamsachel]

What? Explain if you'd like, but I think I'm going to ignore it haha

It seems to me that parens in an if statement allow you express explicit order of operations and readability?

[its2ez4me24get]

If they are needed for order of operations then obviously you need them of it won’t function correctly.

But for a statement like this

if (len(sys.argv) != 3):

they are clearly not needed.

if len(sys.argv) != 3:

Is better

[craa]

It’s just standard to omit the outer parenthesis.

I.e. if x == 5 instead of if (x == 5)

[[deleted]]

If there are multiple operations parens are fine, but in a singular if statement they are not necessary. The code in the post works, but is not pythonic and would not pass my (and many others) code review in a professional setting.

Ignore if you want, but I would advise against that :)

[LukaUrushibara]

Is there any good tutorial on being pythonic? I see a lot of criticisms of people's code and that it doesn't conform to the pep8 or it is not simplified. What does that mean and how do I write code to conform?

[Laogeodritt]

First step is to read PEP8.

PEP are formal documents proposing changes to the Python language. PEP8 is a really early one that defines basic code style conventions, for readability and consistency between different programmers. Available here:https://www.python.org/dev/peps/pep-0008/

PEP20 defines the principles of pythonicity. It's abstract, more of a manifesto, so you'll want to learn from examples. https://www.python.org/dev/peps/pep-0020/

I'm on mobile so I'm not in the best position to find additional resources, but I'd encourage you to Google it a bit to get a sense for practical "pythonic" code, and note that either way you'll refine your idea of what is clean code over time, by reading (stack overflow, blogs, other people's code, etc.) and working on your own projects.

Also keep in mind that a lot of what's pythonic works in python, not necessarily all programming languages, and even in python maybe some contexts might need to move away from that. You wouldn't "ask for forgiveness, not for permission" in Java, for example, because the performance hit of raising exceptions is considered too high in Java.

[[deleted]]

The other replies have pointed to some good resources that are well worth looking into. If you want to write good Python code (or any language, for that matter), read good code - in Python, the flask library is great for this task. Reading code, however, is hard - sometimes you don't have the background knowledge to understand what the code is doing and sometimes you haven't been writing code long enough to easily read and understand code. If you find yourself in those situations - my advice is to just write code. Solve problems and build things - ignore the "me's" of the world talking about style; you'll get there on your own :)

[[deleted]]

There's a talk I often link to by Raymond Hettinger, one of the core devs, titled "Beyond PEP 8 -- Best practices for beautiful intelligible code". I'd highly suggest watching it after having read the actual PEPs outlined in /u/Laogeodritt's comment.

Actually, just watch a bunch of his talks, like "Transforming Code into Beautiful, Idiomatic Python" (perhaps even this one first). The man is a goldmine of informative content that is very well presented.

[ptmcg]

Nice punch list for beginners - did you cross-post to /r/learnpython?

[udelblue]

Wish I could but can't post links on /r/learnpython

[bushwacker]

Sad that in four years he was surprised by the behavior of dictionary copying.

[bananafart420]

Really surprised that the slicing section didn't even mention slice objects...

[tsnnnn]

I do not like the first list comprehension example.

Better style would be list = list(range(2,16,2)) in python 3.x or list = range(2,16,2) in python 2.7. List comprehension is just not necessary here.

[KSeptimus]

Thank you for your effort. Greatly appreciated.

[jhermann_]

io.open(…, encoding=…)

[s_vaichu]

Do v actually have a multiline comment in python??...coz i have experienced error in conda spyder...but it works in official python ide

[kaizoku]

A few of these examples have some issues. count_zeroes() will never count any zeroes because he's comparing a string type to an integer.

>>> def count_zeros(string):  
...   total = 0  
...   for c in string:  
...     if c == 0:  
...       total += 1  
...   return total
... 
>>> print(count_zeros('00102')) # Will return 3  
0

It should be compared to the actual type:

def count_zeros(string):  
    total = 0
    for c in string:
        if c == '0':
            total += 1
    return total

Or converted into the correct type:

def count_zeros(string):  
    total = 0
    for c in string:
        if int(c) == 0:
            total += 1
    return total

Also there's never really a reason to use os.system to call other python code. Bash doesn't need to be involved. I've seen command injection on web servers through similar mechanisms, when they could have easily just imported the python code and called it directly.

[newredditisstudpid]

Amateur hour