Lawrence D'Oliveiro wrote:
In message
mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel Pichavant
wrote:
Saying that, if one intend to distribute its code, he should stick to 80
chars per line.
Why?
Because some(many ?) people cannot deal with more than 80 chars,
In message mailman.0.1282642167.29448.python-l...@python.org, Jean-Michel
Pichavant wrote:
Lawrence D'Oliveiro wrote:
In message
mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel
Pichavant wrote:
Saying that, if one intend to distribute its code, he should stick to 80
Roy Smith wrote:
There was a fling a while ago with typesetting code in proportional
spaced type. I think some of the Effective C++ series from
Addison-Wesley did that. Yuck.
I don't think proportional spacing is necessarily a
problem, as long as a font is used that makes all
characters
Gregory Ewing wrote:
Roy Smith wrote:
There was a fling a while ago with typesetting code in proportional
spaced type. I think some of the Effective C++ series from
Addison-Wesley did that. Yuck.
I don't think proportional spacing is necessarily a
problem, as long as a font is used that
In article 4c6dfb31$0$1$c3e8...@news.astraweb.com,
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
Of course source code is written in a monospaced typeface, which is a
little wider and consequently fewer characters per page.
There was a fling a while ago with typesetting
On 2010-08-20, Roy Smith r...@panix.com wrote:
In article 4c6dfb31$0$1$c3e8...@news.astraweb.com,
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
Of course source code is written in a monospaced typeface, which is a
little wider and consequently fewer characters per page.
Stefan Schwarzer a écrit :
Hi Neil,
On 2010-08-17 14:42, Neil Cerutti wrote:
(snip)
Looking through my code, the split-up lines almost always include
string literals or elimination of meaningless temporary
variables, e.g.:
self.expiration_date = translate_date(find(response,
On 2010-08-20, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid
wrote:
make this :
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d',
'%m%d%Y'
)
I just HATE
In message
mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel Pichavant
wrote:
Saying that, if one intend to distribute its code, he should stick to 80
chars per line.
Why?
--
http://mail.python.org/mailman/listinfo/python-list
Dear Jean-Michel,
On Aug 18, 2010, at 10:57 AM, Jean-Michel Pichavant wrote:
At least, if you still want to stick with 79 chars, do something like
text = find(response, 'MPNExpirationDate', ).text
self.expiration_date = translate_date(text,'%Y-%m-%d', '%m%d%Y')
I don't necessarily like this
On Fri, 20 Aug 2010 15:09:39 +1200, Lawrence D'Oliveiro wrote:
In message mailman.2242.1282071458.1673.python-l...@python.org, Terry
Reedy wrote:
A reason not mentioned much is that some people have trouble following
packed lines that are too much longer. Wide-page textbooks routinely
put
On 08/17/10 12:59, AK wrote:
On 08/16/2010 10:42 PM, James Mills wrote:
On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line
In message i4e4o6$gc...@localhost.localdomain, Martin Gregorie wrote:
1) ssh terminal windows generally come up as 24 x 80
My terminal windows come up by default at something like 40 lines by 100
characters.
2) at 24 x 80 I can get more ssh terminal windows on the desktop with
minimal
D'Arcy J.M. Cain wrote:
On Tue, 17 Aug 2010 16:28:02 +0200
Stefan Schwarzer sschwar...@sschwarzer.net wrote:
I'd probably reformat this to
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')
or even
Hi Lie,
On 2010-08-18 12:02, Lie Ryan wrote:
On 08/17/10 12:59, AK wrote:
On 08/16/2010 10:42 PM, James Mills wrote:
My personal opinion (despite monitors being wider) is
the horizontal scrolling isn't worth it. Stick to a 80-char width.
But.. why horizontal scrolling, isn't autowrap much
Roy Smith r...@panix.com wrote in message
news:roy-319e47.09055017082...@news.panix.com...
In article i4deqq$4e...@lust.ihug.co.nz,
Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
In message mailman.2212.1282012525.1673.python-l...@python.org, AK
wrote:
As monitors are
In message 4c6a9c72.4040...@sschwarzer.net, Stefan Schwarzer wrote:
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d',
'%m%d%Y')
Might I suggest (guessing at the argument keywords here) :
In article qkoao.53872$gq5.12...@hurricane,
BartC ba...@freeuk.com wrote:
Remember, the old hardcopy terminals used to produce 132-character-wide
listings.
Those of you who think old hardcopy terminals did 132 wide obviously
don't remember the ASR-33 :-)
ASR33s I think might have
In article 4c6b9...@dnews.tpgi.com.au, Lie Ryan lie.1...@gmail.com
wrote:
On 08/17/10 12:59, AK wrote:
On 08/16/2010 10:42 PM, James Mills wrote:
On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote:
As monitors are getting bigger, is there a general change in opinion on
the
Roy Smith r...@panix.com wrote in message
news:roy-181632.07571818082...@news.panix.com...
In article qkoao.53872$gq5.12...@hurricane,
BartC ba...@freeuk.com wrote:
Remember, the old hardcopy terminals used to produce
132-character-wide
listings.
Those of you who think old hardcopy
On 08/18/2010 05:11 AM, Stefan Schwarzer wrote:
Hi Lie,
On 2010-08-18 12:02, Lie Ryan wrote:
On 08/17/10 12:59, AK wrote:
On 08/16/2010 10:42 PM, James Mills wrote:
My personal opinion (despite monitors being wider) is
the horizontal scrolling isn't worth it. Stick to a 80-char width.
On Wed, 18 Aug 2010 23:18:06 +1200
Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
Might I suggest (guessing at the argument keywords here) :
self.expiration_date = translate_date \
(
TheText = find(response, 'MPNExpirationDate').text,
ToFormat
On Wed, 18 Aug 2010 10:57:00 +0200
Jean-Michel Pichavant jeanmic...@sequans.com wrote:
D'Arcy J.M. Cain wrote:
You can extend this if there are complicated sub-calls. Probably
overkill for this example but here is the idea.
self.expiration_date = translate_date(
On 2010-08-18, D'Arcy J.M. Cain da...@druid.net wrote:
The other thing that jumps out at me is having the input format
different than the output format. In any case you need a
better date input function. There's no reason in this day and
age to force users into a particular input form. You
In message mailman.2212.1282012525.1673.python-l...@python.org, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files?
WHAT 79-character limit in source files?
I currently have my Emacs windows set at 100 characters wide, and I’m
On Aug 17, 6:50 am, AK andrei@gmail.com wrote:
On 08/17/2010 12:26 AM, James Mills wrote:
By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..
-andrei
It
Michele Simionato wrote:
On Aug 17, 6:50 am, AK andrei@gmail.com wrote:
On 08/17/2010 12:26 AM, James Mills wrote:
By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users
James Mills prolo...@shortcircuit.net.au wrote in message
news:mailman..1282019212.1673.python-l...@python.org...
On Tue, Aug 17, 2010 at 2:12 PM, AK andrei@gmail.com wrote:
There's no doubt that there are pro's and con's, but to be fair, it's
not like code becomes unreadable over 79
On 2010-08-17, Michael Torrie torr...@gmail.com wrote:
In general if I find myself consistently going longer than 75
or 80 characters, I need to refactor my code to make it more
manageable. If I have to scroll up five pages to find the
beginning of a block, that normally means my code could
In article i4deqq$4e...@lust.ihug.co.nz,
Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
In message mailman.2212.1282012525.1673.python-l...@python.org, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files?
On Tue, 17 Aug 2010 13:00:51 +1000, James Mills wrote:
Roy, under normal circumstances I would agree with you and have a
different opinion. However being vision impaired restricts the available
width (irregardless of the width of the monitor) of text I'm able to
view at once.
I'm with James
Hi Neil,
On 2010-08-17 14:42, Neil Cerutti wrote:
On 2010-08-17, Michael Torrie torr...@gmail.com wrote:
In general if I find myself consistently going longer than 75
or 80 characters, I need to refactor my code to make it more
manageable. If I have to scroll up five pages to find the
On 2010-08-17, Stefan Schwarzer sschwar...@sschwarzer.net wrote:
Hi Neil,
On 2010-08-17 14:42, Neil Cerutti wrote:
Looking through my code, the split-up lines almost always
include string literals or elimination of meaningless
temporary variables, e.g.:
self.expiration_date =
On 08/17/2010 10:28 AM, Stefan Schwarzer wrote:
Hi Neil,
On 2010-08-17 14:42, Neil Cerutti wrote:
On 2010-08-17, Michael Torrietorr...@gmail.com wrote:
In general if I find myself consistently going longer than 75
or 80 characters, I need to refactor my code to make it more
manageable. If I
On Tue, 17 Aug 2010 16:28:02 +0200
Stefan Schwarzer sschwar...@sschwarzer.net wrote:
I'd probably reformat this to
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')
or even
On 2010-08-17 17:44, AK wrote:
On 08/17/2010 10:28 AM, Stefan Schwarzer wrote:
I'd probably reformat this to
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')
or even
self.expiration_date
On 08/17/2010 12:21 PM, Stefan Schwarzer wrote:
On 2010-08-17 17:44, AK wrote:
On 08/17/2010 10:28 AM, Stefan Schwarzer wrote:
I'd probably reformat this to
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d',
On 2010-08-17, AK andrei@gmail.com wrote:
After all, I think it's a matter of balance between
readability, expressiveness and succinctness. If I split a
function in two, that still means that understanding the
functionality of the code will require scrolling around and
looking at the
On 17 August 2010 18:43, AK andrei@gmail.com wrote:
On 08/17/2010 12:21 PM, Stefan Schwarzer wrote:
On 2010-08-17 17:44, AK wrote:
On 08/17/2010 10:28 AM, Stefan Schwarzer wrote:
I'd probably reformat this to
self.expiration_date = translate_date(
On 8/17/2010 2:26 PM, Almar Klein wrote:
On a related note, why is the limit mentioned in PEP8 79 chars, and not
80? I never understood this :)
A newline char or block or underline cursor makes 80. The importance
depended on the terminal. 80 chars on the last line could especially be
a
Almar Klein wrote:
[snip]
I am in favor of the 80-char limit also. Besides the arguments listed
above, when using an IDE it gives you that extra horizontal space to fit
some IDE specific tools (such as source structure).
I must admit that I'm sometimes slightly frustrated when an
On 8/17/2010 3:47 AM, Lawrence D'Oliveiro wrote:
In messagemailman.2212.1282012525.1673.python-l...@python.org, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files?
WHAT 79-character limit in source files?
Only for stdlib.
A reason not mentioned much is that some people have trouble following
packed lines that are too much longer. Wide-page textbooks routinely put
text in two columns for easier reading. This is less of a factor with jagged
edge text, but if the limit were increased to say 150, there would be
If the display is limited to 80 characters then after printing the 80th
the cursor will be at the start of the next line and the newline will
cause the display to leave a blank line (unless the display has some
intelligence and supports pending newlines, of course).
Ahah! So Windows users
Hi Andrei,
On 2010-08-17 18:43, AK wrote:
But let me ask you, would you really prefer to have:
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')
(or the 4-line version of this above), even when
On 08/17/2010 03:32 PM, Stefan Schwarzer wrote:
Hi Andrei,
On 2010-08-17 18:43, AK wrote:
But let me ask you, would you really prefer to have:
self.expiration_date = translate_date(
find(response, 'MPNExpirationDate').text,
'%Y-%m-%d', '%m%d%Y')
On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I have to edit files in 80 width
terminals, it's
On Tue, Aug 17, 2010 at 12:35 PM, AK andrei@gmail.com wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even
In article mailman.2213.1282012961.1673.python-l...@python.org,
James Mills prolo...@shortcircuit.net.au wrote:
On Tue, Aug 17, 2010 at 12:35 PM, AK andrei@gmail.com wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've
On 08/16/2010 10:42 PM, James Mills wrote:
On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more
On Tue, Aug 17, 2010 at 12:50 PM, Roy Smith r...@panix.com wrote:
I disagree with James. I have no problem with going wider than 80, if
it improves readability by not forcing you to fold lines in unnatural
places.
There's more important things to worry about.
Roy, under normal circumstances
On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to work with that
length, even though sometimes I
On 08/16/2010 11:51 PM, Steven D'Aprano wrote:
On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote:
As monitors are getting bigger, is there a general change in opinion on
the 79 chars limit in source files? I've experimented with 98 characters
per line and I find it quite a bit more comfortable to
On Tue, Aug 17, 2010 at 2:12 PM, AK andrei@gmail.com wrote:
There's no doubt that there are pro's and con's, but to be fair, it's
not like code becomes unreadable over 79 chars - the difference is that
when your terminal is 80 chars, it's less convenient for you to read
code that's wider
On 08/17/2010 12:26 AM, James Mills wrote:
On Tue, Aug 17, 2010 at 2:12 PM, AKandrei@gmail.com wrote:
There's no doubt that there are pro's and con's, but to be fair, it's
not like code becomes unreadable over 79 chars - the difference is that
when your terminal is 80 chars, it's less
On Tue, Aug 17, 2010 at 2:50 PM, AK andrei@gmail.com wrote:
By the way, the reason I asked is that we're working on a python
tutorial and I realized that even though I'm used to 99, I wasn't sure
if it's ok to teach that to new users or not..
In my opinion it would be okay to teach.
On 08/16/2010 08:59 PM, AK wrote:
But.. why horizontal scrolling, isn't autowrap much better than that?
Wouldn't it really make a visual mess of Python code if lines wrapped?
Maybe if they wrapped smartly.
In general, the only time I find my lines longer than 75 characters are
strings or
On 08/16/2010 10:50 PM, AK wrote:
I stay away from ugly cramped one-liners; I mostly run over 79 when I
have a few `and` and `or` clauses or long strings. I've also noticed
something interesting: going from 79 to 99 affects a relatively large
number of lines, but going over 99 (i.e. 99 to 132)
59 matches
Mail list logo
