15 ms·

Beyond PEP 8 – Best practices for beautiful intelligible code [video]

262 points by nharada 11y ago

mapleoin 11y ago
This is a great talk and I really like the second part where he promotes writing your own adapters for non-idiomatic third-party libraries. That being said, I almost couldn't get past the obnoxious rant at the beginning against maximum line length. The reasons for the rule are made very clear in pep8 as well as the fact that it's not a hard rule and it's fine to override it in your team if you all agree on longer lines.
- JustSomeNobody 11y ago
  I don't think it was obnoxious. But, anytime someone is going to bring up code formatting, others will get their panties all in a twist. It's what people like to argue about when they don't want to argue about real problems.
- coldtea 11y ago
  >The reasons for the rule are made very clear in pep8 And are still BS with today's monitors (including laptop monitors). Besides, PEP8 itself goes on to say: " For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters."
  - masklinn 11y ago
    > And are still BS with today's monitors (including laptop monitors). My 15" laptop monitor can only (readably to me) fit two 100-wide buffers in a visually barebone editor (emacs), move to an editor or IDE where the UI takes more horizontal space because of sidebars (Atom, IntelliJ) and the buffers are close to 80-wide, so 80-wide is a perfectly fine limit as far as I'm concerned. Until I have to perform a 3-way merge, then 80-wide doesn't fit anymore. And age will eventually catch up to me and make things worse.
    - coldtea 11y ago
      Missing the point that you don't have to have ALL your lines > 80. Just the few that need to be so. And for those, you can always either wrap or scroll a little to see them in a 3 way merge, it's not a big deal. Heck, in the eighties that you champion and that they got that rule, they worked with a single 80-wide terminal view, not 2 100-wide side by side and no 3 way merges.
- deleted 11y ago
  [deleted]
- cafard 11y ago
  Many years ago I worked as a copy editor. For a while I imagined, as many copy editors did, that my task was to enforce the rules of the University of Chicago's Manual of Style, especially regarding placement of punctuation with respect to quotation marks, "which" v. "that", etc. Eventually, I understood that making such changes was useful, but not really what editing should be about. It is possible to have unreadable or awkward prose with perfect comma placement, semicolon discipline, and no "which"es without a comma before them. I doubt that I was or am nearly as good an editor as he is a coder. Yet I think that there is a logical progression (not a natural progression, since we don't all make it) from knowing the rules to knowing what the rules are for, to having the confidence to break them when it makes sense.
asafira 11y ago
Someone posted the pycon videos a few months ago on hackernews, and this was actually the only one I watched. What's nice about this IMO is that he's entertaining when talking about a topic that I would normally fall asleep to. It's not that I don't care about code quality --- my coworkers can tell you I definitely care --- but it can be a pretty dry subject. Kudos to Raymond. A few months ago I started to get into some networking and saw that there were a few free online courses available. Unfortunately, despite choosing my favorite one, I ended up falling asleep 3 times already listening to the lectures. Man, I sound like I'm getting old...
harshulj 11y ago
I like the indentation part of PEP 8. Especially the ways to organise arguments while defining functions. Having a common way of writing those is really helpful when reading the code. https://www.python.org/dev/peps/pep-0008/#indentation https://www.python.org/dev/peps/pep-0008/#indentation
japhyr 11y ago
My code is cleaner, and much more intelligible after attending this talk.
wldcordeiro 11y ago
This was one of my favorite talks from this year's Pycon, it really opens your eyes up and lets you see the forest from the trees. It's really easy to get caught up worrying about general PEP8 code style without noticing the non-idiomatic code elsewhere.
- agumonkey 11y ago
  He really built up the second part nicely with the count-the-passes video.
tdicola 11y ago
I recently saw a good summary of PyCon 2015 talks that included this and a lot of other top notch ones: https://www.fusionbox.com/blog/detail/pycon-2015-talks-you-should-watch/549/ https://www.fusionbox.com/blog/detail/pycon-2015-talks-you-s...
sigzero 11y ago
"PEP8 unto thyself and not unto others" --- Yes!
rajathagasthya 11y ago
This is a great talk. I attended a couple of Python training classes at work by Raymond Hettinger and my Python code quality changed dramatically!
linsomniac 11y ago
This is the best talk from PyCon2015 that I've seen. Raymond is a great speaker, but he really hit it out of the ballpark with this one. Whenever I try to think "How would someone smarter than me solve this?", Raymond is one of the people I am thinking about. I'd highly recommend this talk. Aside: A few days after seeing this, a co-worker asked for my recommendations on a Python project he was working on. Which involved some Python code that was translated over from Java. Pretty much exactly what Raymond was talking about fixing here. I told my coworker he should watch it. A week later he comes to me following up on it, I ask if he's watched it. No... Then he proceeds to ask me what sort of indentation style he should use and what format for the inline docs.
sago 11y ago
One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your editor can be set to 80 col, your shell can too, and then you can leave it and it should work across languages, code-bases, and libraries. An extra line break here or there is preferable to having to drag windows around to read your code. At 80 cols I can get three editor windows on screen, allowing me great views of a lot of relevant code for the bit I'm writing, or a shell in place of one editor that I can be running tests on. Once 82 cols is okay, why not 84, or 90, or 100? What about when the middle column needs 84 cols, and I have to drag everything around. That's rude and productivity sapping. I know some people program with one editor maximised and can have 200 character lines if they like, but a specific width as a convention is helpful. And the convention that is already widely used is going to make fewer people have to accommodate you. The 'ish' is useless in that regard.
- jakeogh 11y ago
  I'm sure you know it's an old design decision that was practical at the time. 100 years from now are we still going to be stuck with 80col's? In your example making the interface smarter could remove the need to manually resize boxes. I like standards, but 80 chars just isnt enough and never was. Is 96 the next reasonable number?
  - sago 11y ago
    'Stuck with'? I don't think we're stuck with anything. I think 80 cols is a very practical width. Most lines in code that is well structured and simple are less than 80 cols wide. Lines that require more than that can be broken. I think in 20 years of Python I've only seen a couple of cases where there wasn't an obvious semantic break point, most of the time such breaks are easy to place at logical points. When you have 80 cols you have more code in your window. You can use the resolution to have taller windows and more windows side-by-side. 1920 pixels gives you nicely 3x80 col editors. Which allows you to look at the code, and its tests, and the shell at the same time, for example.
    - 11y ago
cafard 11y ago
Glad to have seen this, and I will be keeping it in mind in the next few weeks.
mixmastamyk 11y ago
I recommend watching these types of long-form videos at 1.25x or faster. For some reason youtube didn't let me change the speed of this video. Instead I downloaded it with youtube-dl and watched it with vlc.
- andreasvc 11y ago
  I can change the speed if I watch with HTML5; with Flash the option doesn't show (Firefox on Linux).
- agumonkey 11y ago
  I don't even download anymore, I pipe youtube-dl video source url to mpv (which, IIRC is obsolete since mpv gained the ability to find it with the original youtube url).
- markrages 11y ago
  You can do that with low-content videos, but not Raymond Hettinger videos.
compostor42 11y ago
Seriously tempted to print out the Pythonic NetworkElement code vs the Java style code and put it on my wall. Perfectly embodies why I love Python so much. A humbling reminder of how far I have to go to be even near this guy's level.
- alangpierce 11y ago
  In fairness, Java doesn't need to be as verbose as the "Java-style code" from the talk, especially now that Java 8 (with lambdas) is out. Here's how I would write the code in Java: runWithNetworkElement("171.0.2.45", networkElement -> { for (Route route : networkElement.routingTable()) { System.out.printf("%15s -> %s%n", route.name(), route.ipaddr()); } });
  - coldtea 11y ago
    What's this name() and ipaddr()? Sure, Java 8 has lambads, but have their disposed of getters and setters and added some kind of properties? If not, then the idiomatic way is not name(), it's getName(). (Of course without "unified property access", it's not that much different)
    - alangpierce 11y ago
      No, there aren't any special language features behind route.name() or route.ipaddr(), they're just getters without the "get" name. While methods of the form "getFoo" have plenty of history in Java, it's also fairly common to drop the "get", especially when the class is being used as an immutable value type. For example, both Google's AutoValue library and the Immutables library show examples of getters that drop the "get" prefix: https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value http://immutables.github.io/ http://immutables.github.io/ One argument against the prefix is that immutable value types don't have setters, so it's not as important to distinguish between them. Another argument is that immutable values aren't really objects in the object-oriented sense, so accessing a field really is just a data access as oppose to an action being performed by the class instance. (I guess one aspect of Java that makes this less awkward to implement is that methods and fields have independent namespaces, so nothing stops the Route class from having both a "name" field and a "name()" method. That's possible because Java doesn't have first-class functions, so you can always determine from usage whether something is a field or a method.)
st3fan 11y ago
80 columns is for old people.
- pekk 11y ago
  Because old people are bad and lame, right? How is this kind of remark allowed on HN?
  - st3fan 11y ago
    I'm old.
    - pekk 11y ago
      As a black man, <insert negative remark about black people>.
azeirah 11y ago
Excellent talk. Would recommend to developers outside the python community as well. Some takeaways; 1. Adhere to a great style guide 2. Can you predict what the code does? Can you trace a path through the function calls, if statements and for loops? 3. Can you explain to someone what the code -means-? Why is it the way it is? p = (170, .1, .6); if p[1] > .5: print("bright!") elif p[2] > .5: print("light") That's ok, right? Pretty nice. I can see that it'll print "light". Good enough? No, not really. How are "bright" and "light" related to (170, .1, .6) and .5? How about this? color = Color(hue=170, saturation=.1, luminosity=.6) if color.saturation > .5: print("bright!") elif color.luminosity > .5: print("light!") Far better! I know now that saturation is related to brightness, and that luminosity is related to lightness. It takes about the same time to write, yet is far more legible.
- xorcist 11y ago
  The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". Those things are better explained in a comment, I'd think. Comments are needed, but should not explain what the code does (as in "add 1 to n") and instead exaplin why it does it (as in "fn expects indices to start from 1").
  - coldtea 11y ago
    >The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". It can and the code in question will print both "bright" and "light" if passed a color that matches that. Where did you see that it's an either-or affair in the example? Besides, the key point, is that the code talks about luminocity and brightness levels, and the second example makes that explicit. No comments needed if you know what HSV is. And if you don't, comments are usually not the place to learn about it.
    - berdario 11y ago
      if color.saturation > .5: print("bright!") elif color.luminosity > .5: print("light!") it's an `elif`... it will never print both "bright" and "light" This kind of mistake really detracts from the point that was argued here about code being "intelligible"
seanmcdirmid 11y ago
In my own editor written for my own work, I've implemented language-aware line wrapping, which seems to work pretty well (it is aware of paren blocks, and wraps them together). This is only possible since the editor is semi-structured, but it feels like future. I've also begun experimenting with sub-80 column lines, actually, columns whose widths are completely configurable in real time (sometimes I want wider when focusing, sometimes I need narrower when reading and have other things on the screen). As an example, check out the 7th example in http://research.microsoft.com/en-us/um/people/smcdirm/apx/index.html http://research.microsoft.com/en-us/um/people/smcdirm/apx/in....
- octatoan 11y ago
  Nice. But, seriously, use / for division, please.
pekk 11y ago
"Beyond the prevailing code standards, yet another proposal for doing things my way instead of the standard way"
- coldtea 11y ago
  The whole point of the talk went flying over your head. In fact, he proposed the total inverse of what you say. He said, code standards like PEP8 are good, and should be followed. But those are only code formatting standards. The beyond part wasn't about doing things "his way instead of the standard way" but about doing things the Python way (idiomatic Python) instead of ad-hoc or mimicking other languages you're familiar with way. What he showed are common standard Python approaches to solving issues, taking advantage of what Python offers instead of writing in C or Java etc style. Really, your comment couldn't be further from the spirit and content of the talk.
  - pekk 11y ago
    Not at all, when the talk starts out quibbling about the 80-column standard.
    - coldtea 11y ago
      That's just the intro and is said as an aside. Far from being the essense of the talk. (Of course this is already obvious since the 80-column thing is about PEP8, whereas the essense of the talk is how to better structure your code BEYOND PEP8's formatting rules). Not to mention that even PEP8 concedes that you can raise the max line length limit up to 100 if your team agrees.
scrollaway 11y ago
One of my work projects has this huge, three-page document for style guidelines. All the bells and whistles including the 80 character limit. And then I realized this is all BS. I wrote a very short styleguide with a linkback to pep8 for any "questions" one might have. Problem solved. You don't need to decide every little detail of how your code is going to look in advance, unless there is a solid reason to do so. The styleguide, for those curious: https://github.com/jleclanche/fireplace/blob/master/CONTRIBUTING.md https://github.com/jleclanche/fireplace/blob/master/CONTRIBU... Edit: What a great talk. Really embraces the way I've been thinking about pythonic coding. Loved it.
avinassh 11y ago
I want to understand why makes remarks about PEP8 and core library and sending a PR to fix them. Why shouldn't someone send a PR by changing code which adheres to PEP8? As long as tests are passing and core library follows PEP8, then is there anything to worry?
- rtpg 11y ago
  I agree with this sentiment. If your policy is to keep all your code PEP8 (ideally by making it part of your test suite), then the amount of commit messages which are "PEP8-ify" will be pretty small. If you take a blatantly non-compliant codebase and PEP8-ify it, you'll have many "pep8" lines in your git blame for a point, but by integrating it in your process that will disappear pretty clean.
kkmickos 11y ago
I always use 80 character limit as long lines makes it hard to for me follow the flow, and it's not unusual to lose track of which line I was on when going to the next line. Sure there are huge monitors with insane dpi allowing a ridiculous amount of text, but I'm not getting younger and find myself increasing font size every now and then to be able to read. Getting old sucks sometimes.
antimora 11y ago
It kinda bothers me when in his presentation Raymond says make NP P. A problem is and have always been in P if there is an algorithm for the problem that solves in polynomial time. You can have an algorithm for the same problem that does not solve in polynomial time but this does not change the nature of the problem.
- Lord_DeathMatch 11y ago
  T'was a joke; Non-Pythonic vs Pythonic (NP v P)
atriix 11y ago
This is some good pep talk

262 points by nharada 11y ago

This is a great talk and I really like the second part where he promotes writing your own adapters for non-idiomatic third-party libraries. That being said, I almost couldn't get past the obnoxious rant at the beginning against maximum line length. The reasons for the rule are made very clear in pep8 as well as the fact that it's not a hard rule and it's fine to override it in your team if you all agree on longer lines.

JustSomeNobody 11y ago
I don't think it was obnoxious. But, anytime someone is going to bring up code formatting, others will get their panties all in a twist. It's what people like to argue about when they don't want to argue about real problems.
coldtea 11y ago
>The reasons for the rule are made very clear in pep8 And are still BS with today's monitors (including laptop monitors). Besides, PEP8 itself goes on to say: " For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters."
- masklinn 11y ago
  > And are still BS with today's monitors (including laptop monitors). My 15" laptop monitor can only (readably to me) fit two 100-wide buffers in a visually barebone editor (emacs), move to an editor or IDE where the UI takes more horizontal space because of sidebars (Atom, IntelliJ) and the buffers are close to 80-wide, so 80-wide is a perfectly fine limit as far as I'm concerned. Until I have to perform a 3-way merge, then 80-wide doesn't fit anymore. And age will eventually catch up to me and make things worse.
  - coldtea 11y ago
    Missing the point that you don't have to have ALL your lines > 80. Just the few that need to be so. And for those, you can always either wrap or scroll a little to see them in a 3 way merge, it's not a big deal. Heck, in the eighties that you champion and that they got that rule, they worked with a single 80-wide terminal view, not 2 100-wide side by side and no 3 way merges.
deleted 11y ago
[deleted]
cafard 11y ago
Many years ago I worked as a copy editor. For a while I imagined, as many copy editors did, that my task was to enforce the rules of the University of Chicago's Manual of Style, especially regarding placement of punctuation with respect to quotation marks, "which" v. "that", etc. Eventually, I understood that making such changes was useful, but not really what editing should be about. It is possible to have unreadable or awkward prose with perfect comma placement, semicolon discipline, and no "which"es without a comma before them. I doubt that I was or am nearly as good an editor as he is a coder. Yet I think that there is a logical progression (not a natural progression, since we don't all make it) from knowing the rules to knowing what the rules are for, to having the confidence to break them when it makes sense.

asafira 11y ago

Someone posted the pycon videos a few months ago on hackernews, and this was actually the only one I watched. What's nice about this IMO is that he's entertaining when talking about a topic that I would normally fall asleep to. It's not that I don't care about code quality --- my coworkers can tell you I definitely care --- but it can be a pretty dry subject. Kudos to Raymond. A few months ago I started to get into some networking and saw that there were a few free online courses available. Unfortunately, despite choosing my favorite one, I ended up falling asleep 3 times already listening to the lectures. Man, I sound like I'm getting old...

harshulj 11y ago

I like the indentation part of PEP 8. Especially the ways to organise arguments while defining functions. Having a common way of writing those is really helpful when reading the code. https://www.python.org/dev/peps/pep-0008/#indentation https://www.python.org/dev/peps/pep-0008/#indentation

japhyr 11y ago

My code is cleaner, and much more intelligible after attending this talk.

wldcordeiro 11y ago

This was one of my favorite talks from this year's Pycon, it really opens your eyes up and lets you see the forest from the trees. It's really easy to get caught up worrying about general PEP8 code style without noticing the non-idiomatic code elsewhere.

agumonkey 11y ago
He really built up the second part nicely with the count-the-passes video.

tdicola 11y ago

I recently saw a good summary of PyCon 2015 talks that included this and a lot of other top notch ones: https://www.fusionbox.com/blog/detail/pycon-2015-talks-you-should-watch/549/ https://www.fusionbox.com/blog/detail/pycon-2015-talks-you-s...

sigzero 11y ago

"PEP8 unto thyself and not unto others" --- Yes!

rajathagasthya 11y ago

This is a great talk. I attended a couple of Python training classes at work by Raymond Hettinger and my Python code quality changed dramatically!

linsomniac 11y ago

This is the best talk from PyCon2015 that I've seen. Raymond is a great speaker, but he really hit it out of the ballpark with this one. Whenever I try to think "How would someone smarter than me solve this?", Raymond is one of the people I am thinking about. I'd highly recommend this talk. Aside: A few days after seeing this, a co-worker asked for my recommendations on a Python project he was working on. Which involved some Python code that was translated over from Java. Pretty much exactly what Raymond was talking about fixing here. I told my coworker he should watch it. A week later he comes to me following up on it, I ask if he's watched it. No... Then he proceeds to ask me what sort of indentation style he should use and what format for the inline docs.

sago 11y ago

One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your editor can be set to 80 col, your shell can too, and then you can leave it and it should work across languages, code-bases, and libraries. An extra line break here or there is preferable to having to drag windows around to read your code. At 80 cols I can get three editor windows on screen, allowing me great views of a lot of relevant code for the bit I'm writing, or a shell in place of one editor that I can be running tests on. Once 82 cols is okay, why not 84, or 90, or 100? What about when the middle column needs 84 cols, and I have to drag everything around. That's rude and productivity sapping. I know some people program with one editor maximised and can have 200 character lines if they like, but a specific width as a convention is helpful. And the convention that is already widely used is going to make fewer people have to accommodate you. The 'ish' is useless in that regard.

jakeogh 11y ago
I'm sure you know it's an old design decision that was practical at the time. 100 years from now are we still going to be stuck with 80col's? In your example making the interface smarter could remove the need to manually resize boxes. I like standards, but 80 chars just isnt enough and never was. Is 96 the next reasonable number?
- sago 11y ago
  'Stuck with'? I don't think we're stuck with anything. I think 80 cols is a very practical width. Most lines in code that is well structured and simple are less than 80 cols wide. Lines that require more than that can be broken. I think in 20 years of Python I've only seen a couple of cases where there wasn't an obvious semantic break point, most of the time such breaks are easy to place at logical points. When you have 80 cols you have more code in your window. You can use the resolution to have taller windows and more windows side-by-side. 1920 pixels gives you nicely 3x80 col editors. Which allows you to look at the code, and its tests, and the shell at the same time, for example.
  - 11y ago

cafard 11y ago

Glad to have seen this, and I will be keeping it in mind in the next few weeks.

mixmastamyk 11y ago

I recommend watching these types of long-form videos at 1.25x or faster. For some reason youtube didn't let me change the speed of this video. Instead I downloaded it with youtube-dl and watched it with vlc.

andreasvc 11y ago
I can change the speed if I watch with HTML5; with Flash the option doesn't show (Firefox on Linux).
agumonkey 11y ago
I don't even download anymore, I pipe youtube-dl video source url to mpv (which, IIRC is obsolete since mpv gained the ability to find it with the original youtube url).
markrages 11y ago
You can do that with low-content videos, but not Raymond Hettinger videos.

compostor42 11y ago

Seriously tempted to print out the Pythonic NetworkElement code vs the Java style code and put it on my wall. Perfectly embodies why I love Python so much. A humbling reminder of how far I have to go to be even near this guy's level.

alangpierce 11y ago
In fairness, Java doesn't need to be as verbose as the "Java-style code" from the talk, especially now that Java 8 (with lambdas) is out. Here's how I would write the code in Java: runWithNetworkElement("171.0.2.45", networkElement -> { for (Route route : networkElement.routingTable()) { System.out.printf("%15s -> %s%n", route.name(), route.ipaddr()); } });
- coldtea 11y ago
  What's this name() and ipaddr()? Sure, Java 8 has lambads, but have their disposed of getters and setters and added some kind of properties? If not, then the idiomatic way is not name(), it's getName(). (Of course without "unified property access", it's not that much different)
  - alangpierce 11y ago
    No, there aren't any special language features behind route.name() or route.ipaddr(), they're just getters without the "get" name. While methods of the form "getFoo" have plenty of history in Java, it's also fairly common to drop the "get", especially when the class is being used as an immutable value type. For example, both Google's AutoValue library and the Immutables library show examples of getters that drop the "get" prefix: https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value http://immutables.github.io/ http://immutables.github.io/ One argument against the prefix is that immutable value types don't have setters, so it's not as important to distinguish between them. Another argument is that immutable values aren't really objects in the object-oriented sense, so accessing a field really is just a data access as oppose to an action being performed by the class instance. (I guess one aspect of Java that makes this less awkward to implement is that methods and fields have independent namespaces, so nothing stops the Route class from having both a "name" field and a "name()" method. That's possible because Java doesn't have first-class functions, so you can always determine from usage whether something is a field or a method.)

st3fan 11y ago

80 columns is for old people.

pekk 11y ago
Because old people are bad and lame, right? How is this kind of remark allowed on HN?
- st3fan 11y ago
  I'm old.
  - pekk 11y ago
    As a black man, <insert negative remark about black people>.

azeirah 11y ago

Excellent talk. Would recommend to developers outside the python community as well. Some takeaways; 1. Adhere to a great style guide 2. Can you predict what the code does? Can you trace a path through the function calls, if statements and for loops? 3. Can you explain to someone what the code -means-? Why is it the way it is? p = (170, .1, .6); if p[1] > .5: print("bright!") elif p[2] > .5: print("light") That's ok, right? Pretty nice. I can see that it'll print "light". Good enough? No, not really. How are "bright" and "light" related to (170, .1, .6) and .5? How about this? color = Color(hue=170, saturation=.1, luminosity=.6) if color.saturation > .5: print("bright!") elif color.luminosity > .5: print("light!") Far better! I know now that saturation is related to brightness, and that luminosity is related to lightness. It takes about the same time to write, yet is far more legible.

xorcist 11y ago
The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". Those things are better explained in a comment, I'd think. Comments are needed, but should not explain what the code does (as in "add 1 to n") and instead exaplin why it does it (as in "fn expects indices to start from 1").
- coldtea 11y ago
  >The obvious question a newcomer would have to that particular code is "Can't a color be bright and light at the same time? Why?". It can and the code in question will print both "bright" and "light" if passed a color that matches that. Where did you see that it's an either-or affair in the example? Besides, the key point, is that the code talks about luminocity and brightness levels, and the second example makes that explicit. No comments needed if you know what HSV is. And if you don't, comments are usually not the place to learn about it.
  - berdario 11y ago
    if color.saturation > .5: print("bright!") elif color.luminosity > .5: print("light!") it's an `elif`... it will never print both "bright" and "light" This kind of mistake really detracts from the point that was argued here about code being "intelligible"

seanmcdirmid 11y ago

In my own editor written for my own work, I've implemented language-aware line wrapping, which seems to work pretty well (it is aware of paren blocks, and wraps them together). This is only possible since the editor is semi-structured, but it feels like future. I've also begun experimenting with sub-80 column lines, actually, columns whose widths are completely configurable in real time (sometimes I want wider when focusing, sometimes I need narrower when reading and have other things on the screen). As an example, check out the 7th example in http://research.microsoft.com/en-us/um/people/smcdirm/apx/index.html http://research.microsoft.com/en-us/um/people/smcdirm/apx/in....

octatoan 11y ago
Nice. But, seriously, use / for division, please.

pekk 11y ago

"Beyond the prevailing code standards, yet another proposal for doing things my way instead of the standard way"

coldtea 11y ago
The whole point of the talk went flying over your head. In fact, he proposed the total inverse of what you say. He said, code standards like PEP8 are good, and should be followed. But those are only code formatting standards. The beyond part wasn't about doing things "his way instead of the standard way" but about doing things the Python way (idiomatic Python) instead of ad-hoc or mimicking other languages you're familiar with way. What he showed are common standard Python approaches to solving issues, taking advantage of what Python offers instead of writing in C or Java etc style. Really, your comment couldn't be further from the spirit and content of the talk.
- pekk 11y ago
  Not at all, when the talk starts out quibbling about the 80-column standard.
  - coldtea 11y ago
    That's just the intro and is said as an aside. Far from being the essense of the talk. (Of course this is already obvious since the 80-column thing is about PEP8, whereas the essense of the talk is how to better structure your code BEYOND PEP8's formatting rules). Not to mention that even PEP8 concedes that you can raise the max line length limit up to 100 if your team agrees.

scrollaway 11y ago

One of my work projects has this huge, three-page document for style guidelines. All the bells and whistles including the 80 character limit. And then I realized this is all BS. I wrote a very short styleguide with a linkback to pep8 for any "questions" one might have. Problem solved. You don't need to decide every little detail of how your code is going to look in advance, unless there is a solid reason to do so. The styleguide, for those curious: https://github.com/jleclanche/fireplace/blob/master/CONTRIBUTING.md https://github.com/jleclanche/fireplace/blob/master/CONTRIBU... Edit: What a great talk. Really embraces the way I've been thinking about pythonic coding. Loved it.

avinassh 11y ago

I want to understand why makes remarks about PEP8 and core library and sending a PR to fix them. Why shouldn't someone send a PR by changing code which adheres to PEP8? As long as tests are passing and core library follows PEP8, then is there anything to worry?

rtpg 11y ago
I agree with this sentiment. If your policy is to keep all your code PEP8 (ideally by making it part of your test suite), then the amount of commit messages which are "PEP8-ify" will be pretty small. If you take a blatantly non-compliant codebase and PEP8-ify it, you'll have many "pep8" lines in your git blame for a point, but by integrating it in your process that will disappear pretty clean.

kkmickos 11y ago

I always use 80 character limit as long lines makes it hard to for me follow the flow, and it's not unusual to lose track of which line I was on when going to the next line. Sure there are huge monitors with insane dpi allowing a ridiculous amount of text, but I'm not getting younger and find myself increasing font size every now and then to be able to read. Getting old sucks sometimes.

antimora 11y ago

It kinda bothers me when in his presentation Raymond says make NP P. A problem is and have always been in P if there is an algorithm for the problem that solves in polynomial time. You can have an algorithm for the same problem that does not solve in polynomial time but this does not change the nature of the problem.

Lord_DeathMatch 11y ago
T'was a joke; Non-Pythonic vs Pythonic (NP v P)

atriix 11y ago

This is some good pep talk