<br><div class="gmail_quote">On Tue, May 19, 2009 at 10:14 AM, David Stanek <span dir="ltr"><<a href="mailto:dstanek@dstanek.com">dstanek@dstanek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'll bite.<br>
<div class="im"><br>
On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin<br>
<<a href="mailto:aaron.rubin@4dtechnology.com">aaron.rubin@4dtechnology.com</a>> wrote:<br>
> 1) Python is three things which the standard was not designed for: One:<br>
> Object Oriented. Two: Not Hungarian notation Three: Mandatorily uses<br>
> *whitespace* as its defintion for code blocks. Let me explain each one in a<br>
> bit more detail:<br>
> Object Oriented: Because it is not functional-style programming, but<br>
> instead OO, you have to give defintion as to what object type you are using<br>
> before using it. This makes definitions and usage longer than in functional<br>
> programming (when 80 character widths were invented).<br>
> PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber is an example (and<br>
> not an extreme one) of a class (55 characters already) in a rather large<br>
> code base.<br>
<br>
</div>If you are using more than 5 or 6 levels of indentation you may be<br>
doing something wrong. I would guess that your methods are too complex<br>
or maybe you are violating the SRP.</blockquote><div><br></div><div>See below for code example</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="im"><br>
> Not Hungarian: Not only is Python not Hungarian (in general), but the<br>
> PEP-8 specifically tells us to use longer, more descriptive variable names.<br>
> hasInstrumentControllerPhaseDither is an example. Many variables are 15-20<br>
> characters and oftentimes longer. How many of these variables can you fit<br>
> into a line if we are limited to 80?<br>
<br>
</div>I'd like to see an example of your variable names. I don't use<br>
hungarian notation and my name are usually under 10 characters.</blockquote><div><br></div><div>I gave an example already in the snippet you quoted.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<div class="im"><br>
> Whitespace: Python is very unique in that it *uses* whitespace for code<br>
> blocking. It turns out to be very useful, since it visually cues the reader<br>
> where code blocks begin and end by mandate. This creates many situations<br>
> where code *starts* at the 10th indentation (40 characters in our<br>
> standard, 80 characters in some Python standards). Even in normal "great<br>
> design" mode (which takes more time again), you can't help it....your code<br>
> starts at the 6th indentation level often. (28 characters, more than 30%<br>
> of 80 characters already gone. Now how many variables or class names can<br>
> you fit?)<br>
<br>
</div>I'd like to see an example of where using 10 levels of indentation is<br>
good. I'll bet that it's not easy to test.</blockquote><div><br></div><div>Regarding this and the other notion of 5 or 6 being the proper level of indentation:</div><div><br></div><div>class a(object):</div><div>
def method1(simulation=False):</div><div> try:</div><div> if simulation:</div><div> for x in range(10):</div><div> if x>5:</div><div> try:</div>
<div> # here might begin some actual math, with two or three more levels of logic, interfacing with other libraries such as NumPy, etc. where you might need specific error handling</div><div> except CustomError:</div>
<div> # customer error handling</div><div><br></div><div>i.e. the logic code *started* at the 7th indentation level. But I'm sure you can find plenty of examples where it might be more. </div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="im"><br>
> Whitespace (2): Because Python uses whitespace as its sole method of code<br>
> blocking and because this is the visual cue for code blocks, wrapping lines<br>
> obfuscates this and makes the reader think about whether this whitespace was<br>
> there for a code block, or a line-wrap. Thinking about intention of code<br>
> slows us down.<br>
<br>
</div>I partially think you're right. Although I have the same problem with<br>
long lines that have multiple levels of parens.<br>
<div class="im"><br>
> 2) Many of the libraries that are widely used do not adhere to<br>
> the 80 character width line standard. wxPython, NumPy and Boa Constructor<br>
> are a few, but I'm sure there are many, many more. Many libraries do adhere<br>
> to 80 character line width as well. However, a library which is written in<br>
> 80 characters still fits the paradigm of those which are wider and therefore<br>
> backward compliant. In other words, if your tools are geared toward 80<br>
> character line widths and you are now looking at a wider width, things<br>
> become quite difficult. The other way around is fine.<br>
> 3) Writing new code in 80 character line widths takes more time. If I have<br>
> to worry about hitting this width, I have to de-concentrate my efforts of<br>
> writing logical code and concentrate instead on how exactly to format<br>
> this line of code (where to break it, etc....there are a number of rules<br>
> attached to wrapping lines of code). Then I have to re-concentrate on the<br>
> actual task at hand. Alternatively, I can code it up without worrying, then<br>
> when convenient, take some time to reformat to 80 character width. Either<br>
> way, more time.<br>
<br>
</div>I don't really have this issue. The few seconds a day that I waste<br>
formatting code are nothing near the time I waste on YouTube :-)</blockquote><div><br></div><div>or responding to people's posts about character width issues ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<div class="im"><br>
><br>
> 4) Code searching. IDEs have powerful searching features. They list all<br>
> the lines of a file (or files) which match the string you are searching for.<br>
> If things are in one line, this search is meaningful and you can read it<br>
> like you can code. If a line of code actually spans two (or more) lines of<br>
> code, the search is no longer contextually useful and you have to click on<br>
> each item to see what's actually going on. This feature is used heavily in<br>
> many environments (especially large code bases) to save time, but time is<br>
> either lost finding the actual context of a found string, or the search tool<br>
> is avoided altogether because it does not provide meaningful results (i.e. a<br>
> predictive waste of time)<br>
<br>
</div>I would actually like to see tools changed to make this better. Maybe<br>
similar to the way unified diff shows a few lines of context.<br>
<div class="im"><br>
><br>
> 5) Monitors are getting bigger, wider, cheaper. This allows us to have two<br>
> files, side-by-side on a screen that are *both* 120 character width (or even<br>
> wider), without changing font sizes.<br>
<br>
</div>Sure I guess. I am typing this on my EEE 900 which won't like much<br>
more than 90 chars. But even at work I put multiple 80 char wide<br>
windows side by side.<br>
<div class="im"><br>
> 6) Tools are cheap. Time isn't. Get a second monitor, get a more powerful<br>
> editor, do whatever it takes to save time. If viewing more information at<br>
> one time is important, then we should try to make that possible with<br>
> technology, not time.<br>
<br>
</div>Agreed. Use Vim with 80 characters and you will rock out code like<br>
never before. I hear Emacs is good too. What are you currently using.</blockquote><div><br></div><div>Wing IDE. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<div class="im"><br>
> 7) Python is designed to be written more like English than other programming<br>
> languages.<br>
<br>
</div>That's news to me.<br>
<br>
On another note when we hire new developers I often hear this<br>
argument. Once they start coding in Python and using good OO/TDD<br>
techniques they realize that it really doesn't matter. Out of<br>
curiosity how much Python coding do you do?</blockquote><div><br></div><div>Lots and lots and lots :) Started using Python over 10 years ago. Use it all day, every day. Love it :) Using good OO to me seems to accentuate the need for greater line widths (point #1) in a large project (i.e. classes need to be hierarchical in a big project, therefore in order to disambiguate, more characters are needed to refer to this class)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
--<br>
David<br>
blog: <a href="http://www.traceback.org" target="_blank">http://www.traceback.org</a><br>
twitter: <a href="http://twitter.com/dstanek" target="_blank">http://twitter.com/dstanek</a><br>
</font></blockquote></div><br>