OKB (not okblacke) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Automatic word-wrap, where available, really is not a solution; it
>> is a bad workaround to a problem caused by the original author of
>> the source code that can be easily avoided by them taking more care
>> while coding.
>
>
"OKB (not okblacke)" writes:
> Yeah, what I'm suggesting as the cleanest way is to simply make it
> all one long string literal, which is wrapped by the editor to the
> proper indentation point. I can't show this in a newgroup post, but
> it'd be like:
>
> def somefunc():
> if som
OKB (not okblacke) wrote:
You don't need to include extraneous
whitespice to get it to line up
^^
+1 on Python 4 providing whitespice. Should liven things up nicely. :-)
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Chris Angelico wrote:
> On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
> Suppose you want to have a lengthy piece of text embedded in your
> source code, which you will then pass to a GUI widget for display.
> You want the widget to handle word wrap, so you don't want internal
> line breaks g
On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
wrote:
> Chris Angelico wrote:
>> That mandates that formatting NOT be a part of the language. I could
>> take C code and reformat it in various ways with a script, and easily
>> guarantee that the script won't affect the code by simply having it
Chris Angelico wrote:
> On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
>> I think exactly the opposite. The source file should re flect
>> the semantic organization of the code, without extraneous concessions
>> to visual display (like "lining things up" with spaces or splitting
>> lo
On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Automatic word-wrap, where available, really is not a solution; it
>> is a bad workaround to a problem caused by the original author of
>> the source code that can be easily avoided by them taking mor
Thomas 'PointedEars' Lahn wrote:
> Automatic word-wrap, where available, really is not a solution; it
> is a bad workaround to a problem caused by the original author of
> the source code that can be easily avoided by them taking more care
> while coding.
I think exactly the opposite. T
Chris Rebert wrote:
> John Gordon wrote:
>> Neil Cerutti writes:
>>> You can fit much more code per unit of horizontal space with a
>>> proportionally spaced font. As a result, that issue, while valid,
>>> is significantly reduced.
>>
>> Is it? I assume one major reason for the 80-character limit
AlienBaby wrote:
>> (on limiting line lengths)..
>
> I didn't see this mentioned;
>
> I have a hard time keeping python code limited to 80 char line lengths
> _because_ indentation is significant,
Are you suggesting that if indentation was not significant, you wouldn't
write such long lines? *
> (on limiting line lengths)..
I didn't see this mentioned;
I have a hard time keeping python code limited to 80 char line lengths
_because_ indentation is significant, and can end up consuming quite a
lot of linespace itself. Couple that with a liking for
long_memorable_explanatory_names, and a
On 26/07/11 00:05, Ethan Furman wrote:
> Ed Leafe wrote:
>> Religious fervor is one thing; freedom of religion is another! ;-)
>>
>> We strive for readability in our code, yet every printed material
>> designed to be read, such as books, newspapers, etc., uses a
>> proportional font.
>
> The book
Brandon Harris wrote:
I don't really think lining things up makes them any easier to read.
I *totally* disagree. Often I'm scanning a dict looking for either a
key or a value, and having them lined up makes it much easier. Yes, I
have to reindent once in a while, but it's still a write few,
Ed Leafe wrote:
Religious fervor is one thing; freedom of religion is another! ;-)
We strive for readability in our code, yet every printed material
> designed to be read, such as books, newspapers, etc., uses a
> proportional font.
The books I purchase use monospaced fonts for code examples.
On 2011-07-24, Ben Finney wrote:
> Code is also more densely expressive and provides less
> redundancy in expression, and the reader is required to make
> much finer scrutiny of it than of natural language text.
The best writing is less redundant than a line of code, not more.
But most people don
Zero Piraeus writes:
> :
>
> > It's also because many people report that it's easier to read text when
> > it's not wider than ~75 characters.
>
> That rule [1] is for paragraphs of prose in proportional text; code is
> both written and read differently. While there most likely is an upper
> limi
:
> It's also because many people report that it's easier to read text when
> it's not wider than ~75 characters.
That rule [1] is for paragraphs of prose in proportional text; code is
both written and read differently. While there most likely is an upper
limit, it's going to be different - large
On 2011-07-22, John Gordon wrote:
> In <98u00kfnf...@mid.individual.net> Neil Cerutti writes:
>
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while valid,
>> is significantly reduced.
>
> Is it? I assume one major reason
Excerpts from Chris Rebert's message of Fri Jul 22 16:56:15 -0400 2011:
> On Fri, Jul 22, 2011 at 12:13 PM, John Gordon wrote:
> > In <98u00kfnf...@mid.individual.net> Neil Cerutti
> > writes:
> >
> >> You can fit much more code per unit of horizontal space with a
> >> proportionally spaced font
On Fri, Jul 22, 2011 at 12:13 PM, John Gordon wrote:
> In <98u00kfnf...@mid.individual.net> Neil Cerutti writes:
>
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while valid,
>> is significantly reduced.
>
> Is it? I assu
Poor sod? Makes it sound bad when you say it like that. I am not forced
to work at that fixed width, but when I work with code, I often have my
vim session split vertically and it's super important to keep things at
80 character to quickly read/edit code.
Brandon L. Harris
On 07/22/2011 02:13
On 2011-07-22, John Gordon wrote:
> In <98u00kfnf...@mid.individual.net> Neil Cerutti writes:
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while
>> valid, is significantly reduced.
>
> Is it? I assume one major reason f
In <98u00kfnf...@mid.individual.net> Neil Cerutti writes:
> You can fit much more code per unit of horizontal space with a
> proportionally spaced font. As a result, that issue, while valid,
> is significantly reduced.
Is it? I assume one major reason for the 80-character limit is to help
the p
On 2011-07-22, Ian Kelly wrote:
> On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti wrote:
>> Under the assumption that leading white space is important for
>> code formatting, but that all alignment after that is
>> unimportant.
>
> ...unless you're trying to adhere to a line length limit. "80
> ch
On Fri, Jul 22, 2011 at 11:43 AM, rusi wrote:
> Also it is more optimized. For the same size -- and therefore
> readability -- a proportional font packs in more text.
More text == less readability. This is one of the reasons I limit my
line lengths.
--
http://mail.python.org/mailman/listinfo/py
On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti wrote:
> Under the assumption that leading white space is important for
> code formatting, but that all alignment after that is
> unimportant.
...unless you're trying to adhere to a line length limit. "80
characters" is a lot easier to do in a fixed-
On Jul 22, 10:05 pm, Michiel Overtoom wrote:
> On Jul 22, 2011, at 12:23, Thomas Jollans wrote:
>
> > On 22/07/11 10:11, Thomas Rachel wrote:
> >> Am 22.07.2011 00:45 schrieb Terry Reedy:
>
> >>> Whether or not they are intended, the rationale is that lining up does
> >>> not work with proportiona
On Sat, Jul 23, 2011 at 3:05 AM, Michiel Overtoom wrote:
> Indeed. Since Windows95 I always use a proportional font for programming:
>
> http://www.michielovertoom.com/incoming/comic-sans-python.jpg
>
> It's so elegant and gives aesthetic pleasure to look at.
http://xkcd.com/590/
ChrisA
--
htt
On Jul 22, 2011, at 12:23, Thomas Jollans wrote:
> On 22/07/11 10:11, Thomas Rachel wrote:
>> Am 22.07.2011 00:45 schrieb Terry Reedy:
>>
>>> Whether or not they are intended, the rationale is that lining up does
>>> not work with proportional fonts.
>>
>> Who on earth would use proportional fo
On 2011-07-22, Thomas Rachel
wrote:
> Am 22.07.2011 00:45 schrieb Terry Reedy:
>> Whether or not they are intended, the rationale is that lining
>> up does not work with proportional fonts.
>
> Who on earth would use proportional fonts in programming?!
Under the assumption that leading white spac
On 22/07/11 10:11, Thomas Rachel wrote:
> Am 22.07.2011 00:45 schrieb Terry Reedy:
>
>> Whether or not they are intended, the rationale is that lining up does
>> not work with proportional fonts.
>
> Who on earth would use proportional fonts in programming?!
Why not? I don't (it doesn't work wit
Am 22.07.2011 00:45 schrieb Terry Reedy:
Whether or not they are intended, the rationale is that lining up does
not work with proportional fonts.
Who on earth would use proportional fonts in programming?!
--
http://mail.python.org/mailman/listinfo/python-list
Religious fervor is one thing; freedom of religion is another! ;-)
We strive for readability in our code, yet every printed material designed to
be read, such as books, newspapers, etc., uses a proportional font. I switched
to proportional fonts years ago, and am only reluctantly using fixed wi
Dan Sommers wrote:
> bruno.desthuilli...@gmail.com wrote:
>> 1/ you can consider the equal sign ('=') is the "binding operator".
>>
>> 2/ since {'key':'val'} is equivalent to dict(key=val), you can consider
>> colons as a binding operator here
>
> But PEP 8 (under Other Recommendations) indicate
On Thu, 21 Jul 2011 13:28:52 -0700, bruno.desthuilli...@gmail.com wrote:
> 1/ you can consider the equal sign ('=') is the "binding operator".
>
> 2/ since {'key':'val'} is equivalent to dict(key=val), you can consider
> colons as a binding operator here
But PEP 8 (under Other Recommendations) i
In article ,
Terry Reedy wrote:
> Whether or not they are intended, the rationale is that lining up does
> not work with proportional fonts.
There are very few things I am absolutely religious about, but
programming in a fixed width font is one of them.
--
http://mail.python.org/mailman/list
On 7/21/2011 2:46 PM, Andrew Berg wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.21 01:32 PM, Thomas Jollans wrote:
So, the PEP says: do not align operators. End of story.
I'm pretty sure that colons, commas and equals signs are not operators.
Whether or not they are in
On 21 juil, 20:46, Andrew Berg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> On 2011.07.21 01:32 PM, Thomas Jollans wrote:> So, the PEP says: do not align
> operators. End of story.
>
> I'm pretty sure that colons, commas and equals signs are not operators.
1/ you can consid
On Jul 21, 1:46 pm, Andrew Berg wrote:
> [snip PGP noise!]
> On 2011.07.21 01:32 PM, Thomas Jollans wrote:
> So, the PEP says: do not align operators. End of story.
>
> I'm pretty sure that colons, commas and equals signs are not operators.
'au contraire mon frere'.
Colons in a dictionary are as
On 2011-07-21, Brandon Harris wrote:
> I don't really think lining things up makes them any easier to
> read. In fact, the consistency in a single space on either side
> of an operator keeps things neat and clean. Also easier to
> maintain in any editor. Always lining up columns of stuff
> require
I don't really think lining things up makes them any easier to read. In
fact, the consistency in a single space on either side of an operator
keeps things neat and clean. Also easier to maintain in any editor.
Always lining up columns of stuff requires readjusting text every time
you add a new
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.21 01:32 PM, Thomas Jollans wrote:
> So, the PEP says: do not align operators. End of story.
I'm pretty sure that colons, commas and equals signs are not operators.
- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/
On 21/07/11 19:51, Andrew Berg wrote:
> Looks nice all lined up, but it violates PEP 8 because of those extra
> spaces, which is only because extra spaces look bad in one-line
> assignments that have nothing to do with lists/tuples or dictionaries.
> This is one of those times not to follow PEP 8 t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I found a couple things that I think should be tweaked in PEP 8. I don't
agree with everything in PEP 8, but I'm not going to debate /those/
points; rather I'm bringing up a couple examples that violate PEP 8, but
don't apply to the reasons given
44 matches
Mail list logo
