On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked
like
On Fri, 17 Dec 2010 10:53:45 -0500, Steve Holden wrote about for...else:
This construct appears to be unpopular in actual use, and when it comes
up in classes and seminars there is always interesting debate as people
discuss potential uses and realise there are useful applications.
Yes, I
On Fri, 17 Dec 2010 17:26:08 +, Grant Edwards wrote:
Give me code that's easy-to-read and doesn't work rather code that works
and can't be read any day.
Well, in that case, you'll love my new operating system, written in 100%
pure Python:
[start code]
print(this is an operating system)
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2):
if some_good_condition
John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2
On 2010-12-16, John Gordon gor...@panix.com wrote:
I like this style more, mostly because it eliminates a lot of indentation.
However I recall one of my college CS courses stating that one entry,
one exit was a good way to write code, and this style has lots of exits.
So, take the good
On 2010-12-16, John Gordon gor...@panix.com wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def
Am 16.12.2010 22:49, schrieb John Gordon:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod
On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
On Thu, Dec 16, 2010 at 3:41 PM, Stefan Sonnenberg-Carstens
stefan.sonnenb...@pythonmeister.com wrote:
return [x for x,y in
((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff()
or True)) if x][0]
This doesn't work.
On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked
like
John Gordon gor...@panix.com wrote:
But lately I've been preferring this style:
def myMethod(self, arg1, arg2):
if some_bad_condition:
return bad1
elif some_other_bad_condition:
return bad2
elif yet_another_bad_condition:
return bad3
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com...
It doesn't look like you were learning Python. It looks like you were
learning C with Python syntax :(
True, although in many cases one has to interface to legacy C
On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote:
On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning
On 12/16/2010 11:32 PM, Carl Banks wrote:
On Dec 16, 2:56 pm, Ryan Kelly r...@rfk.id.au wrote:
On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion
Writing in Python gives me the luxury of choosing different paradigms
for similar operations. Lately I've been thinking about a minor
detail that peaked my interest and am curious what others think:
Say that I have some function f that I will execute if some variable
v evaluates true. Using a
On Nov 24, 11:46 am, Gerald Britton gerald.brit...@gmail.com wrote:
Say that I have some function f that I will execute if some variable
v evaluates true. Using a classical procedural approach, I might
write:
if v:
f()
I might, however, think more in a functional-programming
On Nov 24, 2010, at 1:46 PM, Gerald Britton wrote:
Say that I have some function f that I will execute if some variable
v evaluates true. Using a classical procedural approach, I might
write:
if v:
f()
I might, however, think more in a functional-programming direction.
Then
Both paradigms are in the bash shell. Using a test switch (like -x for
executiable) mixed with an or ||.
Example:
[-x /usr/bin/firefox ] || exit
I think it's very clear, to old hands, but not so much for a new or
intermediate users.
It certainly is the 'cleaner' form. Like the C style
Gerald Britton gerald.brit...@gmail.com writes:
Writing in Python gives me the luxury of choosing different paradigms
for similar operations. Lately I've been thinking about a minor
detail that peaked my interest and am curious what others think:
Say that I have some function f that I will
Gerald Britton gerald.brit...@gmail.com writes:
if v:
f()
I might, however, think more in a functional-programming direction.
Then I might write:
v and f()
Python has conditional expressions. The above would be:
f() if v else None
using and is bug-prone.
--
On Nov 25, 7:43 am, Paul Rubin no.em...@nospam.invalid wrote:
Gerald Britton gerald.brit...@gmail.com writes:
if v:
f()
I might, however, think more in a functional-programming direction.
Then I might write:
v and f()
Python has conditional expressions. The above
I said:
My intent was to fix an obvious omission: a special case
was discussed in
the Augmented assignment statements section, but an
almost-identical
special case was omitted from the Assignment statements section.
After finally getting registered at bugs.python.org (as described
John Posner wrote:
[snip]
If the object is a class instance and the attribute reference
occurs
on both sides of the assignment operator; for example::
self.x = self.x + 1
... in the RHS expression, ``self.x`` is evaluated with
``getattr()``,
[snip]
If the object is a class instance and the attribute reference
occurs
on both sides of the assignment operator; for example::
self.x = self.x + 1
... in the RHS expression, ``self.x`` is evaluated with
``getattr()``, which can access either an
On Mon Mar 16 03:42:42, I said:
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved
with a getattr() and the result is assigned with a setattr(). Notice that
the
two methods do not necessarily
John Posner wrote:
On Mon Mar 16 03:42:42, I said:
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved
with a getattr() and the result is assigned with a setattr(). Notice that
the
two
In article mailman.1847.1237048379.11746.python-l...@python.org,
Maxim Khitrov mkhit...@gmail.com wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def
John Posner wrote:
Matthew Woodcraft said:
I doubt it's because anyone particularly wanted this
behaviour; it just
falls out of the way '+=' is defined.
At the point where 'inst.x += 1' is compiled,
Python doesn't know
whether 'inst.x' is going to turn out to be a class
attribute or an
On Mar 15, 9:54 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
On Mon, 16 Mar 2009 09:31:59 -, Aaron Brady castiro...@gmail.com
wrote:
[snippety snip]
Otherwise, either /1, every instance has its own entries for class
functions, and subsequent changes to the class don't affect existing
instances, or /2, every method call is of the form x.__class__.foo
Gary Herron gher...@islandtraining.com writes:
Gary Herron gher...@islandtraining.com wrote:
No, you are still misinterpreting your results. But you can be forgiven
because this is quite a subtle point about Python's attribute access.
Here's how it works:
On access, self.count (or
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
[snip Gary Herron's explanation of instance attribute lookup
falling back to class attribute lookup]
It seems clear to me that Maxim understood all this when he asked his
original question (you need to
Rhodri James rho...@wildebst.demon.co.uk writes:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
It seems clear to me that Maxim understood all this when he asked his
original question (you need to understand this subtlety to know why
the trick he was asking about only works for
On Sun, 15 Mar 2009 15:05:04 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Rhodri James rho...@wildebst.demon.co.uk writes:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
It seems clear to me that Maxim understood all this when he asked his
original question (you need to
Maxim Khitrov a écrit :
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class
On Mar 15, 8:56 am, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
[snip Gary Herron's explanation of instance attribute lookup
falling back to class attribute lookup]
It seems clear to me that Maxim
Aaron Brady wrote:
[snip]
However, in my (opined) interpretation, 'list.append(...) is an in-
place operation' is a factual error. In-place operations -also-
rebind their 'argument' (FLOBW for lack of better words). 'append' is
a by-side-effect operation. However colloquially it's mostly
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls()
Cls.x is inst.x
True
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
[snip]
My
John Posner jjpos...@snet.net writes:
My question is ... WHY does the interpreter silently create the
instance attribute at this point, causing a surprising decoupling
from the class attribute? WHY doesn't the interpreter behave as it
would with a simple, non-instance variable:
python
Rhodri James a écrit :
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(snip)
Is there a beneficial effect of silently creating the instance
attribute, which outweighs the detrimental effects: (1)
Rhodri James rho...@wildebst.demon.co.uk writes:
But do you, though? The only occasion I can think of that I'd want
the search to go past the instance is this auto-initialisation,
and frankly I'd rather do that in an __init__ anyway. Perhaps
static methods or class methods work that way, I
John Posner a écrit :
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
Given this class definition:
class Cls(object): x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls() Cls.x is
M R A Barnett p...@mrabarnett.plus.com wrote:
Aaron Brady wrote:
[snip]
However, in my (opined) interpretation, 'list.append(...) is an in-
place operation' is a factual error. In-place operations -also-
rebind their 'argument' (FLOBW for lack of better words). 'append' is
a
Matthew Woodcraft said:
I doubt it's because anyone particularly wanted this
behaviour; it just
falls out of the way '+=' is defined.
At the point where 'inst.x += 1' is compiled,
Python doesn't know
whether 'inst.x' is going to turn out to be a class
attribute or an
instance attribute
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My apologies if the thread has already covered this.) I believe I
understand the
John Posner jjpos...@snet.net wrote:
Summary: I no longer suspect that Python is broken. I *do* think that
there's a situation that is potentially quite confusing:
* In the statement self.x = self.x + 1, the two self.x names can
sometimes refer to different objects.
But this is
Earlier, I said:
I'll look into what the standard Python doc set says on this
matter.
RTFM, in section Augmented assignment statements of python301.chm:
---
For targets which are attribute references, the initial value is retrieved with
a getattr() and the result is assigned with a
On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 1:50 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady castiro...@gmail.com
wrote:
On Mar 15, 12:39 pm, John Posner jjpos...@snet.net wrote:
(My
On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Is there a beneficial effect of silently creating the instance attribute,
which outweighs the
On Mon, 2009-03-16 at 04:02 +, Tim Wintle wrote:
On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
Doh, reply out of thread there - I meant to reply to Rhodi's comment
further down.
Is there any actual advantage to self.attribute picking up
Class.attribute instead of raising a
John Posner wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls()
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect can be achieved by
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect
On Sat, Mar 14, 2009 at 12:50 PM, MRAB goo...@mrabarnett.plus.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
Maxim Khitrov:
When the types are immutable, there is no difference.
But you may want different instances to have different immutable data.
Generally if the data (immutable or not) is the same for all the
instances, use class attributes, otherwise use instance attributes.
Bye,
bearophile
--
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
self.some_value = 0
self.another_value = None
Similar effect
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 12:50 PM, MRAB goo...@mrabarnett.plus.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def
On Sat, Mar 14, 2009 at 12:32 PM, Maxim Khitrov mkhit...@gmail.com wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron gher...@islandtraining.com wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class
Maxim Khitrov wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
self.count += 1
Gary Herron gher...@islandtraining.com writes:
But now you are not listening to what people are telling you. It has
*nothing* to do with the mutability/immutability of the integer and the list
your two classes create.
No! Did you run the code he posted? The immutability makes all the
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron gher...@islandtraining.com wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Gary Herron gher...@islandtraining.com writes:
I think this code is in poor taste: it's clear that it will confuse
people (which is what Maxim was asking about in the first place).
Yes, I see that now, thanks :)
Hallöchen!
Maxim Khitrov writes:
[...]
The advantage of doing this is that the assignments are evaluated
once and thus the creation of that class is a bit faster. Access
is still performed through self.some_value and
self.another_value. Is there a reason to prefer the first style
over the
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron gher...@islandtraining.com wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Gary Herron gher...@islandtraining.com writes:
I think this code is in poor taste: it's clear that it will confuse
people (which is what Maxim was asking about in the first place).
I am trying to become more pythonic as I learn python and get my mind around
it instead of other languages I have used.
I have an app that has a series of classes for objects it uses. From a
style perspective, which should be done:
Different py file for each class
or
One py file with all the
K-Dawg wrote:
I am trying to become more pythonic as I learn python and get my mind
around it instead of other languages I have used.
I have an app that has a series of classes for objects it uses. From a
style perspective, which should be done:
Different py file for each class
or
Steve Holden wrote:
K-Dawg wrote:
I am trying to become more pythonic as I learn python and get my mind
around it instead of other languages I have used.
I have an app that has a series of classes for objects it uses. From a
style perspective, which should be done:
Different py file for each
In old python code i would use 'has_key' to determine if an element
was present in a dictionary.
Python 3.0 will even removed 'has_key'. The reason for removal is that
using the 'in' operator is a cleaner syntax and having two ways to
achieve the same result is against the principle of the
ian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| In old python code i would use 'has_key' to determine if an element
| was present in a dictionary.
|
| Python 3.0 will even removed 'has_key'. The reason for removal is that
| using the 'in' operator is a cleaner syntax and having
On Tue, Apr 8, 2008 at 10:21 PM, ian [EMAIL PROTECTED] wrote:
Ok, so what about 'hasattr' ??
hasattr(myObject,'property')
seems equivalent to
'property' in dir(myObject)
I would suggest that using the 'in' is cleaner in this case also. Is
there a performance penalty here? Or is
On Jan 9, 11:51 pm, Fredrik Lundh [EMAIL PROTECTED] wrote:
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated
-On [20080110 06:51], Steve Brown ([EMAIL PROTECTED]) wrote:
I don't like the duplicated information: But the comment is attractive,
I find it unattractive to be honest.
and the docstring self.__doc__ is already in use in the test log. I've read
that all modules and classes should have
On Behalf Of Steve Brown
What do you think?
I think that comments are for maintainers, and docstrings are for users.
Some of the things I use comments for:
* Visually separate classes (using a syntax-highlighting editor)
* Explain algorithm choices
* Explain bug fixes so I don't later fix
Russ P. wrote:
On Jan 9, 9:47 pm, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the
Russ P. [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Jan 9, 11:51 pm, Fredrik Lundh [EMAIL PROTECTED] wrote:
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class
On Jan 10, 2008 12:47 AM, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the comment
Neil Cerutti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Jan 10, 2008 12:47 AM, Steve Brown [EMAIL PROTECTED] wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
What I'm trying to do with the tests is pare them back so that
the code explicitly and concisely documents the tests.
It is important that the comments and doc strings NOT contain
information about how Temperature Sense works because that
is outside the scope of the test.
More generally,
On Fri, 11 Jan 2008 13:09:26 +1100, Steve Brown wrote:
What I'm trying to do with the tests is pare them back so that the code
explicitly and concisely documents the tests.
Yes, this is good.
It is important that the comments and doc strings NOT contain
information about how Temperature
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the comment is attractive, and
the docstring self.__doc__ is already in use in the
Steve Brown wrote:
I've got a series of modules which look like this:
#
#
# Temperature Sense Test
#
#
class Test3(ar_test.AR_TEST):
Temperature Sense Test
I don't like the duplicated information: But the comment is attractive, and
the docstring
Hari Sekhon wrote:
Is it better to do:
message = This is line1. This is line2 This is line3\n
or
message = This is line1.\n message = message + This is line2\n
message = message + This is line3\n
Since the first method does not follow python's clean and easy
looking indentation
On Thu, 29 Jun 2006 15:31:53 -0700, Scott David Daniels [EMAIL PROTECTED]
wrote:
...
I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code,
See Knuth on Literate Programming and the Web systems (e.g. CWeb).
His goal is to look good typeset with
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
Jorgen Grahn wrote:
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable
indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
Jorgen Grahn wrote:
...
(I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, where identifiers and strings are in Times italic,
operators in Courier, and so on.)
the idea
In article [EMAIL PROTECTED],
Jorgen Grahn [EMAIL PROTECTED] writes:
|
| Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
| time; these people all programmed using fixed-width fonts, on teletypes or
| character-mapped terminals. Hell, even full-screen editors were new and
On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
...
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable
indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under
Jorgen Grahn wrote:
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable
indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under the
assumption that the reader will view it with a
Jorgen Grahn wrote:
On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
...
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable
indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages
On 26/06/06, Claudio Grondi [EMAIL PROTECTED] wrote:
Scott David Daniels wrote: Claudio Grondi wrote: clever stuff to di indentation When necessary to skip first line _and_ indentation: message =
This is line 1 This is line 2 This is line 3 .replace('\n', '\n')[1:] # adjust here '\n' to
Claudio Grondi wrote:
Hari Sekhon wrote:
On 26/06/06, *Claudio Grondi* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Scott David Daniels wrote:
Claudio Grondi wrote:
clever stuff to di indentation
When necessary to skip first line _and_ indentation:
Is it better to do:
message = This is line1.
This is line2
This is line3\n
or
message = This is line1.\n
message = message + This is line2\n
message = message + This is line3\n
Since the first method does not follow python's clean and easy looking
indentation structure but the second just
Hari Sekhon wrote:
Is it better to do:
message = This is line1.
This is line2
This is line3\n
or
message = This is line1.\n
message = message + This is line2\n
message = message + This is line3\n
Is there any reason you can't do it in one line?
message = This is line1.\nThis is
MTD wrote:
Hari Sekhon wrote:
Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Is there any reason you can't do it in one line?
101 - 200 of 216 matches
Mail list logo
