Sujet : Re: Python (was Re: I did not inhale)
De : sebastian (at) *nospam* here.com.invalid (Sebastian)
Groupes : comp.unix.shell comp.unix.programmer comp.lang.miscDate : 28. Aug 2024, 03:48:59
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vam36p$3avsi$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-18-amd64 (x86_64))
In comp.unix.programmer Richard Kettlewell <
invalid@invalid.invalid> wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I?ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it?s a form of experience that must have built up very quickly.
I've seen bugs in production that are due to Python's indentation rules.
Consider this class:
class Foo:
def method1(self):
call1()
call2()
call3()
def method2(self):
call4()
if some_condition:
with some_object() as o:
call5()
# hundreds of other lines of code
call6()
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some delimiter
marking the end of method1(), which would prevent an accidental merger
of this type.