Re: Compare source code

[Seebs]

On 2010-11-06, Steven D'Aprano  wrote:
> On Fri, 05 Nov 2010 18:45:39 +0000, Seebs wrote:
>> On 2010-11-05, Steven D'Aprano 
>> wrote:
>>> Well there's your problem -- you are relying on tools that operate by
>>> magic.

>> Wrong.

> Really? Then how did the logic get screwed up from a mere copy-and-paste 
> operation?

I inserted four spaces in front of a bunch of lines.  :)

> [Aside: he isn't having problems with cutting and pasting code in Python, 
> but in Emacs.]

True.

> You *agreed with him*, and related your story. In context, I think it was 
> perfectly reasonable to conclude that you too used C-M-q in Emacs, which 
> then "magically indents the result". Mark's words, not mine.

Ahh, okay.  I can see how you would have inferred that, but no, that's
not what I did.

> What god-awful editor are you using that can't copy and paste text 
> without mangling it?

It's a side-effect of vi being, by default, configured to prefer to convert
things to tabs.  The particular vi I'm using doesn't, so far as I know
"recognize" file formats, and that default behavior is not merely tolerable
but *preferable* for all of the dozens of other kinds of files I edit.

I've since learned to work around it, but the fact remains that, given a
fairly common behavior, which is *preferable* for every other context, I
ended up with a file where an operation which would have worked for
re-indenting any other language I use didn't for re-indenting Python.
I've long since figured out ways to prevent that, but that wasn't the
point; the point was how much harder it was to fix indentation once it
had gotten mangled than it would be in, oh, any other programming language
or file format I've used.  (Even Makefiles are easier to fix, if only because
they're so much simpler.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Silly newbie question - Carrot character (^)

[Seebs]

On 2010-11-05, Nobody  wrote:
> However, it's still written for language lawyers.

> IMHO, the lack of a reference manual for the language itself is a major
> hole in Python's documentation.

I'm a bit lost here.  Could you highlight some of the differences
between "a reference manual for the language itself" and "something
written for language lawyers"?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, Grant Edwards  wrote:
> On 2010-11-05, Seebs  wrote:
>> On 2010-11-05, Emile van Sebille  wrote:
>>> So, which of your tools are you married to that are causing your issues?

>> Python.

> I think you should quit using Python and choose a language that works
> with whatever tools are causing all your white-space corruption
> problems.

Ahh, but that's the thing.  I'm married to it -- there's existing projects
I want to work on which are in Python.

Anyway, it was a sort of frivolous answer, but it's ha-ha-only-serious;
after all, there were no serious issues with any of these tools before.

There's a saying a friend of mine has; "a lack of communication is never
exclusively one party's fault."  This applies, in many cases, to things
like "issues" that occur when two programs clash in some aspect of their
designs.  In some cases, there might be a real and unambiguous standard
to be violated.  In others, though, you can have a problem which arises
from a clash in expectations between two programs, either of which is fine
on its own.

There is a clash between Python and the whole category of things which
sometimes lose whitespace.  Because that category is reasonably large,
and known to be large, and unlikely to vanish, many language designers
choose to build their languages to be robust in the face of minor changes
in whitespace.  Python chose not to, and that is a source of conflicts.

Were someone to invent a *new* text editor, which mangled whitespace, I
would accuse it of being gratuitously incompatible with Python; I tend
to regard compatibility, once you get past the standards, as a matter
of temporal precedence.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, D'Arcy J.M. Cain  wrote:
> The simple fact is that the combination of your tools and Python is
> broken.  The combination of my tools and Python is not.  That's lucky
> for me since I really, really like IAS.  That's unlucky for people who
> have to work with tools that mangle code.  But don't crusade to change
> my language.  Use Perl or C or even pybraces.

No one is crusading to change Python, or even suggesting that it should
be changed.

> I am offering no solutions.  Why would I since I don't see a problem?

One of the things many people try to do is develop the ability to "see"
problems that affect other people but possibly not themselves.  This allows
people to offer solutions to those problems, which is often viewed as
a kind of contribution to a community.  Certainly, it's more useful than
posting nothing more than "that's not a problem for me."

I can just see how well this attitude must work in other circumstances:
Some Guy:  Oh, *...@#.  I think I just sprained my ankle.

Darcy:  I didn't.

Some Guy:  I don't think I can walk up these stairs.

Darcy:  I don't have a problem with stairs.  Stop trying to
change this path.  It works fine.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, Ethan Furman  wrote:
> The verifiable benefit for me is ease of use, ease of thought, ease of 
> typing... I realize these are not benefits for everyone, but they are 
> for some -- and I would venture a guess that the ease of thought benefit 
> is one of the primary reasons Python is popular.  I am definitely one of 
> those that think indentation based structure is one of Python's best 
> features.

Could you explain more the "ease of thought" thing?  I haven't yet noticed
it, but it might be something to look out for as I get more experienced.

It certainly sounds like something that would be a benefit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, Emile van Sebille  wrote:
> So, which of your tools are you married to that are causing your issues?

Python.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, Steven D'Aprano  wrote:
> On Thu, 04 Nov 2010 20:17:35 +0000, Seebs wrote:
>> That was the thing which bit me the worst.  I had a fairly large block
>> of code in a first-pass ugly program.  I wanted to start refactoring it,
>> so I moved a big hunk of code into a method (with plans to further
>> refactor).  It took about fifteen minutes to redo the logic.

> Well there's your problem -- you are relying on tools that operate by 
> magic.

Wrong.

> Rather than re-create the logic, why not just hit Undo and then re-paste 
> the code *without* the magic auto-reformat? Half a second, to undo and re-
> paste, followed by 10 or 20 seconds to select the appropriate lines and 
> *explicitly* re-indent the lines to the correct level.

There was no magic auto-reformat.  Where did you invent that from?  Why are
you making stuff up which I never said or referred to?

> For somebody who keeps tossing around the mantra that "explicit is better 
> than implicit", you're amazingly reliant on a tool that performs massive, 
> apparently irreversible formatting operations implicitly.

No, I am not.  No such tool was involved.  I never mentioned one, referred
to one, or hinted at one -- and have never used one, because I hate them.
In fact, it is ludicrous to imagine that I was using one, given that I've
stated in this very thread that so far as I know such a tool cannot
be created for Python.

Your decision to invent something I never referred to is not a problem with
my approach to the language.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-05, Steven D'Aprano  wrote:
> How does an edit accidentally add a trailing space to a large number of 
> lines?

I would love to know the answer to this question.

However, empirically, it happens.

My guess would be cutting and pasting in some way.

> So we keep coming back to work-arounds for tools that mangle your data 
> for no good reason...

To some extent, this is true.

How about this.  How about we make the Python TCP Stack.  The Python TCP
Stack works on the same principles that you advocate for the Python
language.  For instance, if any packet it receives is malformed or
contrary to the applicable specs, it has a 95% chance of dropping the packet,
and a 5% chance of interpreting the packet as being of a different type
entirely.

This will NEVER be a problem, and is a good design, because handling
packets which contain any kind of spec violation is just work-arounds
for broken tools, right?

And the first thing we should do is *always* to ensure that, if anything
anywhere does not live up to our proposed specification, it causes us to
fail in spectacular ways.

Of course, to fully capture the feel of Python's choice here, we have
to include some common packet variant, which violates no RFCs, as
one of the "broken" ones on the grounds that it doesn't make sense to
us and isn't easy for a newcomer to read.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Terry Reedy  wrote:
> I am sorry you feel compelled to use a language you so dislike. Not our 
> fault though.

I don't dislike it all that much.  What I dislike is being told that the
problems don't exist.

> If you add the normally redundant information in the form of explicit 
> dedents (anything starting with '#' and distinguishable from normal 
> comments), then it is not too hard to re-indent even after all indents 
> have been removed. I believe this has been dome more than once. By using 
> a stylized comment, the augmented code runs without preprocessing. I 
> also believe at lease one person has written a preprocessor for 
> 'python-with-braces'.

Yes.  They did this because there is no reason that anyone would ever
prefer it or find some benefit to it, of course.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Grant Edwards  wrote:
> It exists because so many people change whitespace intentionally in C
> source code because no two C programmers seem able to agree on how to
> format code.  Diff -b allows you to attempt to ignore semantically
> null stylistic changes made by programmers.

I don't agree with this interpretation, just because the changes it
filters out are hardly ever intentional when I actually look at them.

They're a mix of space/tab changes which don't affect actual indentation,
trailing whitespace, and the like.

The kinds of changes that would be made by C programmers trying to change
source formatting are usually far beyond what "diff -b" would "fix".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, D'Arcy J.M. Cain  wrote:
> Right.  If you mangle spaces in Python or mangle braces in C then
> recovery becomes impossible.  I don't think anyone is contesting that.
> What we question is the idea that somehow Python is special in this
> regard.  If you move files around in ways that change them then your
> tools are broken.  The fact that the breakage is somewhat "friendlier"
> to some types of files is interesting but irrelevant.

Again, why does "diff -b" exist?

It exists because so many things change whitespace unintentionally that
it's a common failure mode.  Thus, people developing data file formats
often put substantial effort into *guaranteeing* that they will survive
changes to the contents of blocks of whitespace -- it won't matter
whether you used spaces or tabs, or how many spaces there are.  This
is done because, if you don't do it, your files sometimes get broken.

I have never heard of a problem where sending something via a common
commercial mail client with its default settings resulted in the
destruction of braces.  I have regularly seen people report that one
mail client or another is losing or adding spaces, converting tabs
to spaces, converting spaces to tabs, or whatever.

To some extent, it may be largely a matter of convention; it is
conceivable that, had Python been a major and influential language
in 1970, tools in general would be much more careful about preserving
spaces.  But that's not what happened.  Python was created in a world
where the decision had already been made by many engineers (often
poor ones) that it was not a big deal to mess up spacing a bit.

I'd guess this decision goes back to early typesetting.  Spaces
are fungible; other content isn't.  The distinction that is tracked
is "was there space between these characters or not".  Given that
widespread presupposition, and that many file formats have been
adapted to that, I don't think it was a good choice to build
something which would be broken by that common failure mode.

It's not as though widespread spacing problems are a surprise.  They
are so commonplace that multiple utility programs provide, as standard
options, features to work around them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Mark Wooding  wrote:
> Seebs  writes:
>> Python's the only language I use where an obvious flaw, which is
>> repeatedly observed by everyone I know who uses the language, is
>> militantly and stridently defended by dismissing, insulting, and
>> attacking the character and motives of anyone who suggests that it
>> might be a bit of a nuisance.

> So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
> a pretty similar reaction.

I don't use it.  I'm also not as sure that the parens are an obvious
flaw -- I am not aware of whole categories of software which regularly
destroy parens.

>   * I /do/ have a significant problem with cutting and pasting code in
> Python.  In most languages, I can haul a chunk of code about, hit
> C-M-q, and Emacs magically indents the result properly.  This is,
> unfortunately, impossible with Python.  It has caused me real bugs,
> and I have to be extra careful to fix the indentation up.

That was the thing which bit me the worst.  I had a fairly large block
of code in a first-pass ugly program.  I wanted to start refactoring
it, so I moved a big hunk of code into a method (with plans to further
refactor).  It took about fifteen minutes to redo the logic.

> I /like/ Python.  I use it frequently.  I /don't/ want to change its
> structure marked by indentation.  I'm /willing/ to put up with some
> inconvenience because Python makes up for it in other ways.  But there
> /is/ inconvenience, and it does need putting up with.  I think the
> benefits are worth the costs; others may disagree.

That makes sense to me.  I think it depends a lot on what I compare
Python to.  I get along quite well with Ruby, but I loathe PHP.  Comparing
Python to Ruby, I find the indentation quite annoying.  Comparing Python to
PHP, I find the indentation a very mild price to pay for my sanity.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Steven D'Aprano  wrote:
> And people have suggested that if your workflow leads to indentation 
> being mangled and your source code no longer running, the solution is to 
> change the workflow.

Yup.

But it strikes me as unmistakably a shortcoming of Python (and Makefiles,
for that matter) that code for them can't survive a common failure mode
that everything else I use can.

> What burden?

The burden of using different tools because suddenly the version of vi
I've been using since 1990 is magically "broken" even though it's never
caused a problem before.

> You keep talking about this burden of not-having-to-type-
> braces, but I don't see any burden, and nor do the majority of Python 
> programmers.

Of course not.  Most of the people who find it annoying *don't use Python*.

Of the programmers I know who don't use Python, 100% have cited the annoyance
value *to them* of the whitespace thing as the main reason they don't.  Of
the programmers I know outside this newsgroup who *do* use Python, 100% have
said the whitespace thing is annoying and they wish Python didn't have it,
but they have to use Python for some externally-imposed reason, so they put
up with it.

Outside of people who seem to be deeply emotionally invested in insisting
that it is never, at all, in ANY way, for ANY person, annoying, it seems
to be pretty consistent to observe that, benefits or no benefits, it has
some kind of non-zero annoyance value.

Other languages I use are mostly amenable to the development of tools
to automatically indent code.  Makefiles and Python are the only two
exceptions... And if I were an advocate for a language, the fact that it's
lumped itself in with Makefiles in a significant way would be a weakness
I'd feel obliged to be up front about.  :)

The underlying issue is this:

* Not having to type braces:  Yay!
* Having structure map to functionality:  Some people quite like it, and
  certainly there exists a class of theoretical errors which it prevents.
* Not being able to write an auto-indenter, ever, because it is by
  design theoretically impossible:  Annoying.

I guess if people could show me some of these errors in other languages
where indentation is misleading and bugs resulted, I'd be more persuaded
by the second point there.  As is, I find the brittleness more annoying
than I've ever found braces or 'end' or whatever.  It's not annoying
enough for me to refuse to use the language when there are other
compelling reasons to, but it's certainly annoying enough that I'll never
use Python for something where I have unfettered choice of language.  It's
less fun to program in, for me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> The answer is because whitespace changes (spaces to tabs, different
>> tab stops, etcetera) are an extremely common failure mode, such that
>> it's quite common for files to end up with unintentional whitespace
>> changes.

> Except the diff option is to *ignore* such differences, not highlight them.

Yes.  That's because those changes are irrelevant, so people don't
care about them, so they want an option to handle the common case where
whitespace got changed but no one cares about that.

But unintentional whitespace changes are common enough that you *need*
the ability to filter them out and just look at "real" changes.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-04, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> It is extremely useful to me to have spaces converted to tabs
>> for every other file I edit.

> I???m thinking of going the other way. After many years of treating tabs as 
> four-column steps, I might give up on them and use spaces everywhere.

I *absolutely must* use tabs for Makefiles.

For code in most other languages, it's merely a factor of 8 improvement
in storage.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Michael Torrie  wrote:
> I suggest, then that Pascal or Ruby would suit your needs better than
> Python.

In the absence of network effects, I'd just be using Ruby.  I have reason
to work with projects that have a lot of existing Python, though, so I
use it too.

> As for refactoring code, vim makes it really easy to move blocks in and
> out.

Yes, though I mostly use nvi, same thing -- basically.  The issue I've
had is that the automatic-tab thing (which I actively want for everything
else I edit) tends to make it quirky.

> The only time I could see this becoming an issue is if functions
> or blocks of code are too long to see on a page at once.  If this is the
> case, break them up.  Sounds to me like your problems with refactoring
> and indention in python could be do to these kinds of design issues.
> Having curly braces certainly doesn't help in these situations either.
> More than once I've had C code I was refactoring that broke due to the
> fact that while trying to move blocks around I misplaced a brace, an
> issue I never have in Python.

For me, I'd rather have the compiler choke because I have mismatched
braces than have the code run apparently just fine except that something
has unintentionally moved in or out of an else clause because there was
no marker.  I've had both happen, probably.

> In the meantime, whitespace structure is one of the things about Python
> that I like the *most* about the language.  Being able to crank out
> executable pseudo-code is pretty addictive.  And I never write
> pseudo-code on paper with begin and end blocks cause it's too much
> effort when scribbling by hand.

I never write on paper anyway.  :)

Anyway, I'm not disputing that there are things that it makes nicer.  I'm
just observing that there exists a category of failures which is completely
unique to Python, which no other language (except BF, which I'm not sure
I ought to count) has, which tends to show up occasionally until you've
gotten all the changed tools and habits, and even then can show up when
dealing with other people who use tools which, well, work perfectly for
everything else.  But not for this.

Only other tool I know with a comparable dependance on spacing is Makefiles,
and I have never in my life met someone who used them and didn't think
that was a loathesome error which should never have made it into
production code.  Python's not nearly as bad, actually.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 20:30:43 +0000, Seebs wrote:
>> I'm not expecting it to change;

> Then why talk about it?

Because I find technical questions interesting in and of themselves.  I
will happily talk with people about the reasons for which the C preprocessor
is the way it is, even though it's never going to change and we all
hate it like poison.

>> I'm pointing out that insisting that it's not a problem is
>> *insulting* to the people for whom it is a problem.

> And insisting that it is a problem is equally insulting to those for whom 
> it is not a problem.

No, it isn't.

A friend of mine is colorblind.  For him, certain red/green pairings are
indistinguishable.  For me to insist that it is not a problem that a
user interface uses those to distinguish two things is insulting to
him; I am dismissing a very real problem.  For him to insist that it
is a problem for him is in no way insulting me.  He's not saying that it's
a problem for me.  He's merely saying that *there exist* people for whom
it is a problem.

No one has claimed that this is a problem *for everybody*.  Just that
there exist real-world workflows for which it is a problem, or people
for whom it is a problem.

This is an asymmetrical situation.  The opposite of "it's never a
problem for anybody" isn't "it is always a problem for everybody"
but "it is at least sometimes a problem for at least some people."

The reality is, the indentation-instead-of-markers thing *does* sometimes
lead to problems.  We could blame it on tools, but the tools could just as
easily blame the language for being brittle.  Given the degree to which
the rest of the world has standardized on not caring how *much*
whitespace is between things (though sometimes caring whether or not
there's *any* whitespace between them), it seems to me that the odd
man out is the one who is creating the burden.

Once many file formats exist which don't care how many spaces you
use, and many tools have been developed with those file formats in
mind, coming up with a new file format which cares how many spaces you
use seems a little short-sighted.  Demanding that all tools be changed
to fit a new paradigm is a pretty big demand to place on people.

On the whole, I don't personally think the benefits have been worth it.
I think Python would be a better, richer, language if it used explicit
end tokens of some sort.  Maybe it wouldn't.  I do know, though, that
of the programmers I know outside the Python newsgroup, not a single
one likes that aspect of Python.  It is consistently regarded as an
annoying quirk.  Some use Python anyway; it has merits, certainly.  If
I were offered a choice between Python and PHP for a project, I would
*absolutely* pick Python.  (Subject, of course, to the assumption that
the project would in some way involve computers, or programming, or
that I would at some point have to either write code for the project
use it, or possibly come within twenty feet of someone who was working
on it; outside of those limitations, I might consider PHP.)

I feel the same way about pretty much every language I use.  C would
be a much better language if the macro processor weren't such a giant
filesystem verification stage for a filesystem distributed across
multiple machines*.  They all have flaws.

Python's the only language I use where an obvious flaw, which is repeatedly
observed by everyone I know who uses the language, is militantly and
stridently defended by dismissing, insulting, and attacking the character
and motives of anyone who suggests that it might be a bit of a nuisance.

I suspect part of that is simply because it *is* a tradeoff, and there
are good reasons for it.  It offers some advantages.  It's not something
that you'd be insane to like; the problems are easily mitigated once you
know about them, and the benefits are worth it.  If I worked with a lot
more novice-level C programmers who hadn't yet had the importance of
careful style drilled into them, I might well find the indentation problems
people keep talking about to be a real thing, possibly even a very
serious one.

But the fact remains, being brittle in the face of whitespace changes *is*
a flaw.  It breaks code under circumstances which are, for better or
worse, common.  As I pointed out before:  There is a *REASON* that diff
has an option for ignoring whitespace changes -- because they are common
enough that such an option is commonly useful for distinguishing between
real changes and inadvertant ones.

Note that "whitespace indentation" in and of itself isn't the thing I'm
describing as a flaw; it's the side-effect of being brittle when whitespace
changes.  The indentation thing as a whole has some definite plusses, and
it's a tradeoff that I think may even be a good 

Re: Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano  wrote:
> Yes. How does that contradict what I said?

Once you understand that you do have to break the rules occasionally,
it is a good idea to design things that will be robust when the rules
are broken.

> Ah, argument by misunderstanding the Zen!

I see.  So explicit boundaries are a good thing, except when they are
one specific special case.

Let us imagine a hypothetical mirror-universe person, who is otherwise
like you, but:

1.  Has a goatee.
2.  Actually hates the indentation rules, wishes Python had braces,
but has become emotionally invested in defending the status quo because
if he had to suffer, dammit, everyone else should have to suffer too.

You have not yet made a single argument that he wouldn't have made
too.

>> It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation. 
>> That's not a burden, it's good engineering practice.

> Python does explicitly mark blocks. It does it by changes in indentation. 
> An indent is an explicit start-block. An outdent is an explicit end-
> block. There is nothing implicit in a change in indent level.

What's the token that marks the end of a block, corresponding to the
colon used to introduce it?

> It simply isn't possible to have implicit start/end block markers, unless 
> you restrict your language in ways that exclude most blocks. E.g. if all 
> if blocks were restricted to a single statement, then you could have an 
> implicit block -- the block in one statement. Stating that Python uses 
> implicit block markers is simply wrong.

No, it isn't.  There's no token telling you where the block ended.

C *allows* implicit blocks, and this is widely regarded as a key flaw.
However, it also allows you to explicitly mark blocks in a way which
is robust against common errors, allowing software to automatically
fix up differences between, say, competing indentation styles.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Grant Edwards  wrote:
> On 2010-11-03, Seebs  wrote:
>> Explicit is better than implicit.  It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation.  That's
>> not a burden, it's good engineering practice.

> Dededenting does explicitly mark the end of a block.

If you can't point to the token, it's implicit.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano  wrote:
> On Tue, 02 Nov 2010 19:26:56 +, Tim Harig wrote:
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 

> Really?

Yes.

> I'm not aware of *any* language that promotes tabs over spaces.

Makefiles.

> I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

No.  However, you've got a fallacy of the excluded middle here -- you're
ignoring the very large set of "doesn't care either way", and looking only
at things that prefer one or the other.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

I don't consider it broken for a tool to favor a more logical style which
is *actually* required by at least one format, and not a problem for anything
I've ever used except (sort of) Python.

In fact, Python works perfectly with tabs; it's just other Python
programmers who get fussy.  :)

> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

I don't miss them, or care about them; after all, I can just run indent/cb
to format something however I like, and run it again to match any given
coding style standard.  Problem solved.

> * it's not an issue for thousands of other users;

This is a non-argument.  That something isn't a problem for other people
makes no difference to the people for whom it's a problem.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

I have never found any other editor that I like as much as the one I use
now.

> * and even if there is no right tool for the job, the feature isn't going 
> to change;

I think you miss the point of the observation.  I'm not expecting it to
change; I'm pointing out that insisting that it's not a problem is
*insulting* to the people for whom it is a problem.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Oh, I'd happily contribute code if it'd matter.  But it wouldn't.

>> It would be much better if the community would simply acknowledge that
>> this is a tradeoff the the language has made and one which is often
>> misunderstood by many first time Python programmers.

> Been there, done that. This is *old news*.

I haven't seen it done yet.  I've seen a whole lot of people tell me that
an editor I've been using for twenty years is "broken" because I found
a program that is brittle with regards to its inputs that is prone to
being triggered by a behavior which has been free of problems (and indeed
in some cases *mandatory*) for everything else.  I've seen people smugly
tell me that I'd love this if I just tried it.  That didn't work for
pickles, it didn't work for Player-vs-Player fighting in video games,
and it's not gonna work for the lack of end markers.

Explicit is better than implicit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 01:25:56 +0000, Seebs wrote:
>> Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
>> *extremely common* bad thing, 

> I question that.

> You've claimed that you have to deal with broken indentation on a regular 
> basis.

I'd guess I see something which got screwed up somehow every couple of
weeks, usually while refactoring stuff.

>> and I fundamentally don't think it was a
>> good choice to build a system with no redundancy against it.

> Python does have some redundancy against indentation mangling. Not all 
> combinations of indentation are legal.

True, but it doesn't seem to catch the most common failure modes.

> And so on. True, there are some failure modes which can't be easily 
> recovered from without reading and understanding the code. That's okay. 
> Such failure modes are vanishingly rare -- for every twenty thousand 
> braces you avoid typing, you might, if you're unlucky, need to fix an 
> instance of broken indentation.

This is ridiculous overstatement.  Moving a single block of overly-nested
code out into a separate method could generate several indentation
mishaps if Something Goes Wrong, which it does sometimes.  I haven't
written more than a couple hundred blocks in Python, so I'm a factor of a
hundred out from twenty thousand braces, and I've had six or seven
indentation problems.

And yes, I can just recreate it, but it takes more effort, since I can't
do things like just handing it to an automated tool that can correct
it completely automatically.

Furthermore, I don't WANT to skip closing braces.  EXPLICIT IS BETTER
THAN IMPLICIT.  I *WANT* to have the beginnings and ends marked.

I want end braces or "end" or something at the end of a block for
the same reason that I prefer:
x = "hello, world"
to
x = "hello, world
where we just assume the string ends at the end of the line.

>> That
>> "redundant" information saves our hides on a regular basis in an
>> imperfect world.

> So you say.

Well, it works for me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano  wrote:
> On Wed, 03 Nov 2010 02:40:11 +0000, Seebs wrote:
>> Sure, but there's also no way for you to spot that something looks
>> suspicious.  In Python, if something is misindented, it does what you
>> told it to do, and there's no way for you to tell, by looking at it,
>> that it isn't what was intended.  In C, if something is misindented, it
>> does what you told it to do, but it's obvious looking at the code that
>> something went wrong.

> If it's that obvious, why do people keep causing those indentation-
> related bugs in C?

I don't think they do.  I can't remember the last time I've seen one.

> I'm glad for you that you have a finely trained attention to detail that 
> is able to instantly spot misindented C code (or is that misplaced braces 
> and correctly indented?), but it is a notoriously common error which 
> suggests that it's not anywhere near as obvious as you think.

It's "notoriously common", but can you show me an actual example of
it happening in real code?  Not a "hey guys look how misleading this
would be" example conjured up for illustration, but an *actual* example
in live code?

I can't remember one, except I think maybe I saw one somewhere in...
hmm.  No, wait, that was perl.

>> This level of dogmatism about what should always be the case is not
>> conducive to good software engineering practices.

> I question that assertion. Good engineering practices is about setting 
> best practices, and following them, not avoiding them because there might 
> be the odd exception here and there.

I don't think I buy this.  I've seen a whole lot of good writers and good
programmers, and in both groups, they consistently report that you have
to know how the rules work before you break them.

> The language shouldn't make 
> everyone carry the burden of supporting two-page functions all the time, 
> just to save you an insignificant amount of trouble on the vanishingly 
> rare occasion you need a function that is two pages long.

I don't think there's a particularly big burden there.

Explicit is better than implicit.  It is *better* to explicitly mark the
ends of things than to have it be implicit in dropping indentation.  That's
not a burden, it's good engineering practice.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trouble with importing

[Seebs]

On 2010-11-02, Ben Ahrens  wrote:
> I did indeed continue to top-post, and you should plonk me.

Edited for accuracy.  Done.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-03, D'Arcy J.M. Cain  wrote:
> On 03 Nov 2010 01:20:40 GMT
> Seebs  wrote:
>> However, I have probably seen all of two or three bugs ever related to
>> mis-indented C, and I've had various things screw up or wreck indentation

> Really?  I have never seen bugs in C related to indentation.  I have
> seen plenty related to braces.  What I have seen is bugs hidden by the
> indentation not matching the block structure.

Right.  That's *related to* indentation -- it wouldn't be there (we hope)
had the indentation been right.

> Wrong indentation in
> Python *is* a bug.  There's no other visual signal to hide the error.

Sure, but there's also no way for you to spot that something looks
suspicious.  In Python, if something is misindented, it does what you
told it to do, and there's no way for you to tell, by looking at it,
that it isn't what was intended.  In C, if something is misindented,
it does what you told it to do, but it's obvious looking at the code
that something went wrong.

> But I can see the other end of the block in Python.  I don't need any
> tricks to make sure that it is the end.  And if your block is too big
> to see the structure easily then that just means that some code should
> be factored out to a method.

This level of dogmatism about what should always be the case is not
conducive to good software engineering practices.  It is not obvious to
me that it's *always* the case.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Grant Edwards  wrote:
> Huh? Indentation is invisible?  You can't see the indentation in
> Python source code?

The difference between tabs and spaces is invisible on a great
number of the devices on which people display code.

Indentation is visible, but the underlying structure of it may not
be.  (It's worse than that, because for instance "  " is
quite hard to distinguish from the quite similar "  ".)  And at
least one of them is clearly wrong.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Tim Harig  wrote:
> This is Python's most noticable blemish outside of the community.
> Everybody knows that Python is the language that forces you to use a
> particular style of formatting; and, that is a turn-off for many people.

Honestly, I could probably live with that; the killer is the impossibility
of recovering from white space damage.  I have had many things happen to
code over the years which required someone to run them through indent/cb.

> It is a big mistake that whenever the issue arises, the community
> effectively attacks anybody who might have disagreements with the tradeoffs
> made for the Python language.  This tends to set people on the defensive
> and gives them a bad taste about the language as a whole.

Yes.  It does not create an impression that this is an engineering tradeoff
which has been considered and understood; it creates the impression that
people are defensive enough about it that they're not able to confidently
acknowledge the shortcomings while maintaining that the tradeoff is worth
it.

I like C.  If you tell me that C's macro processor sucks, I will agree
with you.  I don't have to make excuses or pretend that there's no
downsides; I can justify my preference for the language even *granting*
those downsides (and downsides aplenty are to be found).

> It would be much better if the community would simply acknowledge that
> this is a tradeoff the the language has made and one which is often
> misunderstood by many first time Python programmers.  Then it is possible
> transition to Python's strengths.  Don't simply ignore that there *are*
> potential downfalls to this approach.

Amen.

I am fine with this tradeoff.  It's not what I would have picked, but
hey, I'm not Dutch.  What I'm not fine with is people telling me that
it's not a tradeoff and that all the problems are my fault.

If someone designed a protocol where a particular kind of file was required
to be sent via email, as plain text, with many lines starting "From ", and
the protocol died horribly whenever it encountered ">From " at the
beginning of a line, no amount of pointing out that the mail servers in
question were wrong would make it a good design for a protocol.

Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
*extremely common* bad thing, and I fundamentally don't think it was
a good choice to build a system with no redundancy against it.  That
"redundant" information saves our hides on a regular basis in an
imperfect world.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, D'Arcy J.M. Cain  wrote:
> "Large" is no excuse for incompetency.

It is in practice.

> So configure it to recognize Python files and act accordingly.

So far as I know, it doesn't have a feature to do this.  In any event,
I work around it okay.

>> No, they aren't.  See... That would work *if I knew for sure what the intent
>> was*.
>> 
>>  if foo:
>>  bar
>>  else:
>>  baz
>>  quux
>> 
>> Does it look right?  We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a 
>> typo.

> And C has the same problem.

Not quite!

> if (foo)
> bar;
> else
> baz;
>
> quux;

> Is quux meant to be part of the else clause?  The writer's indentation
> suggests "yes" but the code says "no".

Right.

And that's the thing:  In C, I know there's something wrong here.  I may not
know what it is, but I know *something* is wrong.

> Same is true for the C code.

Pretty much!

> In both cases you can tell what the code
> will do (modulo weird macros in the C code) but the intention is
> impossible to determine without mind reading abilities in both cases.
> We do know that the Python code *appears* to be doing exactly what the
> author intended and the C code *appears* to not be.

Yes.  And in my experience, that means that since the code must be
wrong (or I wouldn't be looking at it), it's very nice that in one of
them, I've just been told for sure that the writer was confused right
here at this line.  In the other, I have no way of knowing that the
writer was confused.

What was it someone once said?  "Explicit is better than implicit."

I *like* my parity bits.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Emile van Sebille  wrote:
> What is right is that there's no question that quux is subsequent to baz 
> in all cases barring exceptions (and assuming no tabs intermixed)

Yes, but that doesn't mean it does what the programmer intended, just
that it does what it does.

> The apparent structure in python _is_ the structure, whereas otherwise 
> you've got to count your ;'s and {}'s etc to determine and verify the 
> structure matches the apparent structure provided by the programmer.

Yes.

I understand this.

However, I have probably seen all of two or three bugs ever related to
mis-indented C, and I've had various things screw up or wreck indentation
on dozens of occasions.  Being able to recover has been nice.  (So's being
able to use fence matching to jump to the other end of a block.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Grant Edwards  wrote:
> And you think compatibility with your broken e-mail server is a good
> reason to change the syntax of a programming language?

No.  I never said that.

>> Many editors helpfully convert spaces to tabs by default some or all
>> of the time.  And so on.

> Such editors are broken.

If I use an editor for twenty years, and it works beautifully with fifteen
different programming languages across five operating systems, and someone
comes along with a file format which tends to silently break when treated
the same way, my first response is not to blame the editor.

> I think it's brilliant (indentation that actually means something, not
> scanf).

It is.  However, it's also brittle.

>> The "problem" it fixes is something that's hardly ever been a problem
>> for me in C or related languages -- and which could be completely
>> eliminated by automated indenters, which were actually conceptually
>> possible.

> They're only possible if you put redundant block markers in the
> source.

Yes.  Or make the block markers not-redundant.

> Then you're doing something terribly wrong.  I find indentation-based
> structure to be completely effortless.

And it is *ABSOLUTELY CERTAIN* that, if any two people have different
experiences of how easy or hard something is, it's because one of them
is doing something wrong, right?

Because people are *never* actually different.  There is no such thing
as "preferences".  There is no such thing as a "matter of taste".  No,
no.  If one person finds something comfortable, and another dislikes it,
it's because the second one is *doing something terribly wrong*.

> Are you using an editor that
> doesn't have a Python mode?

Yes.  I haven't used "modes" in editors until now.  I've never needed to.
Every other file format I work with is robust about this.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Grant Edwards  wrote:
> True, but the fact that diff has an option that for Python sources
> will produces useless results doesn't seem like a valid indictment of
> Python's syntax and semantics.

The question is *why* diff has that option.

The answer is because whitespace changes (spaces to tabs, different
tab stops, etcetera) are an extremely common failure mode, such that
it's quite common for files to end up with unintentional whitespace
changes.

This, in turn, is why there are so many tools to automatically fix up
whitespace type issues, such as cb/indent for C, auto-indentation for
many languages (including stuff like XML) features in editors, and so
on -- because it's a common problem.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, Steven D'Aprano  wrote:
> I've lost more time to reading people's bitching about indentation than I 
> have dealing with indentation problems.

Doesn't totally surprise me.  :)

> But then, I don't insist on using tools which are broken by design.

Neither do I.

> If your email server converts plain text to HTML, it is broken.

Yup.  I have an open ticket with the IT department.  :)

> If your 
> editor changes spaces to tabs, or visa versa, without being told to do so 
> (either by an explicit command or an obvious setting), then your editor 
> is broken.

Yes.  But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

> If you are stuck with broken mail servers and broken editors and broken 
> tools because of political reasons, then you have my sympathy. But stop 
> insisting that everybody has to carry the overhead of your work-arounds 
> for your broken tools.

I have made no such insistance.  I have not said Python should change.  I
have not said other people should want what I want.  I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

I have merely observed that Python is, in this respect, gratuitously
brittle.  It doesn't observe the robustness principle; it is
conservative in what it accepts, and in particular, is vulnerable to a
category of problem which is fairly common, well-known, and likely to
remain common for the next few decades.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff.  I do dislike
it when people smugly tell me off for having different preferences.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-02, D'Arcy J.M. Cain  wrote:
> You have problems.  Indentation as syntax isn't one of them.

In the absence of indentation as syntax, they haven't bugged me.

> "No one
> knows why" email is being "magically" transformed?

Yay for a large company IT department with both MS and Blackberry
stuff involved.

> Your editor has a
> mind of its own?  Yikes!

It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

>> I've lost more time to indentation issues in Python in a month than
>> I've lost to mismatches between indentation and flow in C in twenty

> Your experience is 180 from mine.

Could be.  But really, I've simply never seen a real problem with
flow/indentation mismatches in C.

>> At least in C, if I see:
>>  if (foo)
>>  a;
>>  else
>>  b;
>>  c;
>> 
>> I *know* that something is wrong.

> Does it look right?  With Python looking right and being right are the
> same thing.

No, they aren't.  See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right?  We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C.  The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: *** FBI gets a warm welcome in Chicago for their EXCELLENTperformance - cheers to NEW CONS ***

[Seebs]

On 2010-11-02, brf...@gmail.com  wrote:
> How exactly does this relate to python?

1.  It doesn't.  It's spam.  Duh.
2.  Don't respond to spam.
3.  Don't top-post.
4.  If I see even one more post from you where the entire previous post
is quoted under your text, I will plonk you.  I warn you now because
most posters will do the same thing, and you will get very lonely
once no one bothers to read your posts.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare source code

[Seebs]

On 2010-11-01, Grant Edwards  wrote:
> On 2010-11-01, Lawrence D'Oliveiro  wrote:
>> In message <8j8am4fk2...@mid.individual.net>, Peter Pearson wrote:
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.

>> I'm getting less and less keen on that particular feature of Python...

> Why?

> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.

Sure.

> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.

Right.

But there's no *reason* to do that, while there are many common daily
events which result in whitespace changes.  e.g., any email sent
to my work account is being magically transformed into HTML (no one
knows why) on the server, so I can't get correct indentation except
in attachments.  Many editors helpfully convert spaces to tabs
by default some or all of the time.  And so on.

The more I use it, the more I think it was an interesting experiment
which has worked out about as well as scanf.  The "problem" it fixes
is something that's hardly ever been a problem for me in C or
related languages -- and which could be completely eliminated by
automated indenters, which were actually conceptually possible.

I've lost more time to indentation issues in Python in a month than
I've lost to mismatches between indentation and flow in C in twenty
years.  In theory, it sounds like it would help to eliminate the
ambiguity.  In practice, eliminating the question of whether code
was intended to follow explicit flow rather than indentation just
means that when there's a mistake you don't even get a warning that
someone was confused.

At least in C, if I see:
if (foo)
a;
else
b;
c;

I *know* that something is wrong.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python changes

[Seebs]

On 2010-10-28, Craig McRoberts  wrote:
>I've already resigned
>myself to starting over from the beginning, but are my books from
>that time period even worth using now?

Impression I get is mostly "no".  I think you'll find life overall a lot
better now, though.  Programming languages tend to improve, with some
very notable exceptions.  :P

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why "flat is better than nested"?

[Seebs]

On 2010-10-26, kj  wrote:
> (Though, humorless as it is of me, I still would prefer the ZoP
> out of the standard library, to save myself having to tell those
> who are even newer to Python than me not to take it seriously.)

Well, not to take it *too* seriously.

It's like any other Zen -- it's wonderful as long as you take it about
the right amount seriously.  If someone could tell you how seriously
that is, it wouldn't be Zen.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode questions

[Seebs]

On 2010-10-25, Lawrence D'Oliveiro  wrote:
> In message , Petite 
> Abeille wrote:
>> Characters vs. Bytes

> And why do certain people insist on referring to bytes as ???octets

One common reason is that there have been machines on which "bytes" were
not 8 bits.  In particular, the usage of "byte" as "the smallest addressible
storage" has been rather firmly ensconced in the C spec, so people used to
that are likely aware that, on a machine where the smallest directly
addressible chunk of space is 16 bits, it's quite likely that char is 16
bits, and thus by definition a "byte" is 16 bits, and if you want an octet,
you have to extract it from a byte.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-22, Jean-Michel Pichavant  wrote:
>> I'm all for descriptive names, but there's a great deal of benefit to
>> knowing when a descriptive name will help, and when all you need is a
>> variable which will be quickly recognized.

>> Compare:
>> [theValueInTheList.func() forTheValueInTheList in theList]
>> [x.func() for x in list]

>> One of these is much, much, easier to read than the other.  It's
>> not the one that used a "descriptive" name.

> You did not use descriptive names in your example, but verbose names. 
> That makes a huge difference.

Well, they certainly describe the objects in question better.

> [ str(day) for day in week ]
> [ str(x) for x in _list]
> [ str(d) for d in w ]

> I let you decide which one is better. After that I'm running out of 
> arguments :o)

This is an interesting example!  I would probably use str(x) for x, because
the idiom of using "x" trumps the details of what we think x is in a
particular case, but I do like "week" better than "_list", certainly.

Unless, of course, we have context:

def strings(week):
[ str(day) for day in week ];

In that case, I'd think that
[ str(x) for x in list ]
would be much clearer.

In general, I don't like to use single-letter abbreviations unless they're
consistent as part of an idiom.  I'm fine with "s" for a string, "e" for
an exception, or "i" for an index.  I wouldn't normally use "d" for a day,
because that's not a convention.  (There's similarity to pronouns; pronouns
are great, but you can't usually just invent new ones.)

> Note that I did not suggest to write
> [ aDayInAWeek.displaymeCauseImAwesome() for aDayInAWeek in 
> weekContainingSomeDaysHopefully ]

Heh.

I think one thing that's been somewhat missed is the importance of
surrounding context.

I would have no problem with:

except KeyError, e:
print "How on earth did we get a KeyError:", e
exit(1)

or something similar.  (Ignoring, for now, the issues with "exit(1)".

If we had a much larger and more complicated bit of processing, much
of which didn't use or refer to the exception, and then came back to it,
though, I might prefer a name which will be easier to track:

except KeyError, e:
# time to get clever!
new = alternative_list()
new = [x.fixup() for x in new]
if new.size > 3:
more_complicated()
stuff_here()
else:
and_now_a_little_song()
...
...
...
else:
print "I couldn't recover, sorry.", e

I'd find that much less attractive, because at that point, e is no longer
really working like a pronoun; it's not a common thread throughout the
execution, but a reference to context some distance previously, and it
hasn't been maintained.  So a big part of the question, for me, is how
regular and consistent the usage is.  I don't mind i for a loop index for
something that's heavily using i.  I don't mind it for something where
i is never used at all inside the loop, just as a counter.  But if there's
a large complicated bit of processing, with a single reference to "i"
buried in the middle of it, then I'm going to want to replace it with a
name that tells you what it is.

The tradeoff there is largely a question of what it's like to read the
code.  If reading the code makes the variable's usage obvious, a one-letter
name may be appropriate, especially if the variable's meaning is really
nothing more specific than "that thing we're working with".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-22, Jean-Michel Pichavant  wrote:
> Seebs wrote:
>> On 2010-10-21, Jean-Michel Pichavant  wrote:
>>> list1 = []
>>> for x in theList:
>>> if x[0] == 4: 
>>> list1 += x;
>>> return list1

>>> flaggedCells = []
>>> for cell in theBoard:
>>> if cell[STATUS_VALUE] == FLAGGED:
>>> flaggedCells += cell
>>> return flaggedCells   

>> The latter is better, but:

> Right, may be there is an even better solution. This is not the point. 
> The point of this example is to show the power of meaningful names in a 
> very basic example. You said it yourself, the latter is better.

But it's a very contrived example, where bad style is held up for admiration
by comparison with atrocious style.  That's not a persuasive argument!

In fact, the "better" example can be massively improved by *shortening*
it, lending weight to my general contention that verbosity for the sake
of feeling like we're making things clearer is not an effective way to
make things clearer.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-22, Jean-Michel Pichavant  wrote:
> Seebs wrote:
>> The one that brought this up, though, was "except FooError, e:", and in
>> that case, there is no need for any further description; the description
>> is provided by the "except", and "e" is a perfectly reasonable, idiomatic,
>> pronoun for the caught exception.

> same for the exception.

No, not the same.

> Let's say you're reading some code, someone else code. You can't just 
> read  everything so you're reading through quickly.

> You first hit that line:

> "print e"

Yup.

> You have *no* idea what e could be. It could be the number e... You can 
> now try to read through the above code and find out. And it's easy to do 
> that, Anyone can do that. But it takes time ! only 1 sec maybe but 
> that's still 1 sec, and when you are reveiewing code, it can be really 
> tedious.

I don't think I ever first hit the first line of a block rather than the
control for the block.

> Immagine now you hit
> "print exception".
> Then you know, he's trying to print an exception, do you need to care 
> about that ? If so introspect the code, try to know wich exception 
> class, but if the answer is 'I don't care about the exception being 
> printed' you can just continue and read the code like a book :) It saves 
> a lots of time.

Except it doesn't.

Because it takes enough longer to read that, and enough longer to read
the surrounding code, that it's taken me longer than it would have if the
name had been short.

> Regarding another point you mentioned in this thread, your brain can 
> read "number" as fast as "num" so it doesn't take more time to read 
> proper english, than abreviations all around (I think it's the opposite 
> actually).

There certainly exist cases where a shorter thing is harder to read than
a longer thing, however, there are many cases where short names, especially
idiomatic ones, are much, much, faster.  Individual letters are things
that most English speakers will pick up essentially instantly, making them
good candidates for variables.

There is a reason that mathematicians write dy/dx, rather than
"the rate of change of the vertical axis value divided by the rate
of change of the horizontal axis value."  It's that people can, in fact,
read these things much faster.

> Your brain can instantly recognize a known face

Strictly speaking, actually, no.  But I grant that most peoples' can.  :)

> All I'm saying is that the brain is not reading a sequence of letters, 
> but recognize some known pattern as a whole, so reading time is not 
> related the word length.

Yes, and all you're saying is wrong.  Reading time is strongly related to
word length overall.  If you are looking entirely at known words, you
will absolutely read "he" a lot faster than you read
"antidisestablishmentarianism".  Similarly, even people who are pretty
active in the field might have to slow down to tell homoiousia from
homoousia, while very few people will have a hard time telling x from
y.  The more long words you embed, the more of the data you're presenting
the user with is irrelevant to what's happening.

For short to medium length words, there's not usually much advantage
from a shorter word, assuming that everything you're looking at is in
fact natural words, but you're more likely to overlook typos or miss
details.

Coupled with punctuation, layout, and the rest, short words can help
reduce the wall-of-text effect, which can massively hurt reading speed.

I'm all for descriptive names, but there's a great deal of benefit to
knowing when a descriptive name will help, and when all you need is a
variable which will be quickly recognized.

Compare:
[theValueInTheList.func() forTheValueInTheList in theList]
[x.func() for x in list]

One of these is much, much, easier to read than the other.  It's
not the one that used a "descriptive" name.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-21, Jean-Michel Pichavant  wrote:
> It can be short if descriptive:

> for o, c in cars:
> park(o)
> phone(c)

> for owner, car in cars: # by just using meaningful names you give the 
> info to the reader that you expect cars to be a list of tuple (owner, car)
> park(owner)
> phone(car) # see how it is easier to spot bug

In this case, yes.

The one that brought this up, though, was "except FooError, e:", and in
that case, there is no need for any further description; the description
is provided by the "except", and "e" is a perfectly reasonable, idiomatic,
pronoun for the caught exception.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-21, Jean-Michel Pichavant  wrote:
> Let me quote the paper I linked in the previous post:
>
> list1 = []
> for x in theList:
> if x[0] == 4: 
> list1 += x;
> return list1
>
> compare it to:
>
> flaggedCells = []
> for cell in theBoard:
> if cell[STATUS_VALUE] == FLAGGED:
> flaggedCells += cell
> return flaggedCells   

The latter is better, but:

flagged = []
for cell in board:
if cell.flagged():
flagged += cell;

is probably even better.  (Here's where I love Ruby's idiom of
"flagged?" as a method name.)

The "Cells" suffix on flagged is questionable; I'd omit it in context because
the programmer knows we're working on cells.  The "the" prefix on "theBoard"
is actively harmful -- it communicates nothing and clutters.  Adding symbolic
words to the cell[0] == 4 test is a great idea, but it's been done
questionably:
1.  Did we just clutter the entire global namespace with "FLAGGED"
and "STATUS_VALUE"?  If not, what namespace are they in, that
we're able to use them unqualified?
2.  Why are we exposing that much of our interface in the first place?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-21, Jean-Michel Pichavant  wrote:
> In the middle of thousand lines of code, when you are reviewing or 
> debugging, the later is better TMO, the point is that x, y, z = is only 
> easy to read during the assignement.

Bull.

> x, y, z = p.nextpoint()
> [snip a dozen of code line]
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> ...
> y += 1 # hmmm ??

Uh, no.

That is not confusing at all.  That is CLEAR AND TRANSPARENT.

> yCoordinate += 1

In the real world, this will take substantially longer for the reader
to comprehend.  You've just taken the important information (y), and
hidden it behind 10 times as much UNIMPORTANT information.  You're
forcing them to read 11 characters, 10 of which are just tagging,
and made it much easier for them to miss that the "y" here should have
been an "x", because the word is 90% correct anyway...

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-21, Martin P. Hellwig  wrote:
> Although intuitively I would say the shorthand, however that is 
> depending on the context being me knowing at least the basics of 3d 
> spaces and having the pre-warning that you are going to mention 
> something with either coordinates or colours.

> Take away this pre-information, as you would when first reading an 
> application, and all of the sudden the latter would be much clearer to 
> the fellow programmer.

Would it really?  Would it stay clearer to the new programmer for more
than two or three minutes?

I don't think it would.  At worst, the new programmer has to look up
coordinates, once, and then we're back to the state where calling them
x, y, and z, or calling them r, g, and b, is MUCH easier on the new
guy.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-20, Matteo Landi  wrote:
> Another situation in which I needed to disable such kind of warnings
> is while working with graphics modules.
> I often use variable names such as x, y, z for coordinates, or r,g,b for 
> colors.
> Would longer names make the reader's life easier?

Interesting point.  Which is really easier to read:

x, y, z = p.nextpoint()

xCoordinate, yCoordinate, zCoordinate = polygon.nextPointCoordinates()

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-20, Jean-Michel Pichavant  wrote:
> except ValueError, e:

> Use meaningful names, this is so important.

It's important, but meaning can come from idiom, not from the word used.

> 'e' is not meaningful. 

Sure it is.  It's like i for a loop index.

There's a reason mathematicians use x, not the_value_that_can_vary.

> When dealing with such issue like "I'm too lazy to 
> write proper engligh" always think that what is the most important thing 
> is to save the Reader's time, not the Writer's time. Using 'e' would 
> force to reader to introspect to code to get an idea of what 'e' is. 

If the reader can't track a single-letter idiomatic name over two consecutive
lines of code, I don't think I can save the reader time.  The reader is beyond
my ability to help at that point.

Furthermore, long names take longer to read and process.

As a *reader*, I vastly prefer:
except foo, e:
print "Fatal error:", e
to anything you could do with a longer name.

Consider, admittedly a C example:
for (int i = 0; i < n; ++i)
a[i] += 1;
vs:
for (int index_into_array = 0; index_into_array < size_of_array; 
++index_into_array)
array_into_which_we_are_indexing[index_into_array] += 1;

Here's the thing.  The issue is not that I'm too lazy to write English.  The
issue is that English, like every other language, USES PRONOUNS.  Because
pronouns are a good way to MASSIVELY streamline communication.  It's not just
a convenience to the writer/speaker; it also makes life easier for the
reader/listener.

Short variable names are pronouns.  They make sense when you'd use a
pronoun in English.

"If we catch a KeyError, we print an error message including it."

We'd use a pronoun.  Makes sense to use a short variable name.

> Moreover, code completion makes use of long names costless.

No, it doesn't.  It preserves their higher cognitive load in parsing.

Dogmatism about rejecting short variable names is inconsistent with the
psychology of human readers.  Compilers don't care about length of
variable names.  Humans do, and there are times when they benefit more
from a short and recognizeable name than they do from a long and
"expressive" one.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Code smells: too many parameters, too many attributes (was: pylint -- should I just ignore it sometimes?)

[Seebs]

On 2010-10-20, Ben Finney  wrote:
> It's a code smell. Many discrete attributes is a sign that the design
> can be improved by combining related attributes into a complex type.

Ahh.

I think that makes sense.  In this case, I don't think it's worth it,
but I can see why it would be in some cases.  There are cases where there's
a thing that really DOES have that many attributes, but I've seen lots
of cases where it made sense to subdivide them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Alexander Kapps  wrote:
> The general idea is, that modules, classes, methods, and functions 
> should be small so they are better reusable, manageable and 
> understandable.

Makes sense.

> If you have a huge class or function with many 
> attributes or local variables, it's often a sign, that your 
> class/function does to much and you better refactor this into 
> smaller pieces.

That is often practical, but it can involve tradeoffs -- there can be
a great deal of additional complexity from the interactions between the
refactored pieces.

I tend to refactor mostly if the pieces have some kind of value outside
their original context.  In some cases, a process is just, well, sorta long,
but there's no relevance to breaking the components out -- they're not
separately useful anywhere.

> I don't know why "the standard" (what standard?) says what it says, 
> but I guess, it's the result of long time experiences and analysis 
> of existing code. Trust them, unless you are sure to know better.

Well, one of the reasons I'm asking is to find out, from experienced
developers, how trustworthy the pylint people are, and what the target
audience is...  Should I be treating this the way I'd treat a list of
coding style rules handed down by a first year CS teacher, which are great
rules for first year CS students, or the way I'd be treating a corporate
style document which is a mandated part of continued employment?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Ben Finney  wrote:
> Tools like pylint are far more useful if every message they emit is
> something that you must deal with, rather than ignore every time you see
> it. That way, it's feasible to get the output to no messages at all, and
> have a defensible reason for every disabled message.

That makes sense -- we do the same thing with warnings in C, usually.

I'll see whether I can find ways to, say, suppress a message for a specific
line rather than in general.  (Though I have no idea what line number to
use for a warning about too many instance attributes...)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Martin P. Hellwig  wrote:
> Speaking without context here, so take it with as much salt as required 
> ;-), it is not that unusual. However there are some things to consider, 
> for example are all these attributes related to each other? If so 
> wouldn't it be more pythonic to have one attribute which is a dictionary 
> and store your stuff in there?

I don't know.  Does "pythonic" mean "needlessly verbose"?  :)

I did, in an early draft, have something that basically came down to:

self.foo = {}
self.foo['a'] = a()
self.foo['b'] = b()

and then I realized that I could just write:
self.a = a()
self.b = b()

and spend a lot less extra typing on repeating something that, by virtue
of being repeated constantly, was therefore meaningless.  It wasn't creating
a meaningful distinction, it wasn't showing a meaningful relationship...
All these things are attributes of the thing itself, not attributes of its
dictionary.

> As everything pylint is a really useful tool especially when you just 
> start writing in python and it can give you valuable clues on how to 
> improve your programming. So just take it as hints that there might be 
> ways to write it better, have a think about it, perhaps ask as you have 
> done, and happily ignore it if all else fails :-)

Part of the trick is I'm trying to figure out when the problem is that my
intuition about what makes code "readable" contradicts the norms of the python
community, and when the problem is just that pylint is being dogmatic where
real programmers would likely exercise judgement.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Martin P. Hellwig  wrote:
> Well, as with all styles IMHO, if there is a _good_ reason to break it, 
> then by all means do, but you might want to consider putting in a 
> comment why you did that and add the #pylint: disable-msg= 
> on that line. If that is overkill, why not just comply to the standard 
> and avoid all the fuzz?

Well, part of what I'm trying to understand is why the standard in question
says what it says.  I'm pretty much mystified by a claim that something with
seven instance attributes is "too complicated".  For instance, I've got a
class which represents (approximately) a C function, for use in writing
various wrappers related to it.  It has name, return type, args, default
values, a list of arguments which need various modifications, a default
return value, and so on... And it ends up with, apparently, 10 instance
attributes.

I can't tell whether there's actually a general consensus that classes
should never be nearly that complicated, or whether pylint is being a little
dogmatic here -- I haven't seen enough other Python to be sure.  I'm
used to having objects with anywhere from two or three to a dozen or more
attributes, depending on what kind of thing they model.  It seems like a
very odd measure of complexity; is it really that unusual for objects to have
more than seven meaningful attributes?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Shawn Milochik  wrote:
> Just to be pedantic (or maybe even helpful), the use of the comma
> after the exception is deprecated in favor of 'as.'

Not in code that has to run on older Pythons.

I'm pretty sure I have to work with everything from 2.4 to 2.6 or so.

That reminds me, though.  Speaking of deprecation, I have:
from string import Template
(see PEP 292 or so?), and pylint says "Uses of a deprecated module 'string'",
but I don't know of a way to get Template except by doing that.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint -- should I just ignore it sometimes?

[Seebs]

On 2010-10-19, Steven D'Aprano  wrote:
> On Tue, 19 Oct 2010 19:57:36 +0000, Seebs wrote:
>> One:  I am a big, big, fan of idiomatic short names where appropriate.
>> For instance:
>>  catch , e:

> That would be except, not catch.

Er, yeah, that.

> Well, that name is 98 characters, which means it's impossible to use it 
> without exceeding the 78 or 79 character per line limit, so I guess that 
> since there's no other alternative between 1 character and 98, you'll 
> just have to break down and ignore pylint.

:)

> Perhaps you should have a read of PEP 8, the recommended style guide.

Will do.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

pylint -- should I just ignore it sometimes?

[Seebs]

So, I'm messing around with pylint.  Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.

There's a few exceptions.

One:  I am a big, big, fan of idiomatic short names where appropriate.
For instance:
catch , e:
I don't want a long, verbose, name -- "e" is about as much in need of
a long and descriptive name as the stereotypical "i" one would use as
a loop index (in a language without iterators).  Should I just ignore
that, or is it really more Pythonic to say something like:
catch KeyError, 
exception_resulting_from_the_use_of_a_key_not_defined_for_the_dictionary_in_which_it_was_looked_up:

Secondly:  I am getting a couple of hits on things like "Too many instance
attributes (8/7) or "Too many branches (14/12)".  In the cases in question,
it doesn't seem to me that the number of instance attributes is particularly
devastatingly complicated, because the instances in question are, by design,
sort of data stores; they carry a handful of precomputed results that are
then reused to populate templates.

So am I going to be laughed out of the room if I just let a class have
eight instance attributes, or use a short name for a caught exception?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Classes in a class: how to access variables from one in another

[Seebs]

On 2010-10-18, Aahz  wrote:
> In article <4cbcca47$0$29979$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano   wrote:
>>[duplicate post]

> Maybe, but there's no reason for posting that ten times!  ;-)

I would guess that there is almost certainly a reason.  My first candidate
would be "buggy software", but you never know.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fastest way to detect a non-ASCII character in a list of strings.

[Seebs]

On 2010-10-17, Dun Peal  wrote:
> What's the fastest way to implement `all_ascii(L)`?

Start by defining it.

> 1. Match against a regexp with a character range: `[ -~]`

What about tabs and newlines?  For that matter, what about DEL and
BEL?  Seems to me that the entire 0-127 range are "ASCII characters".
Perhaps you mean "printable"?

> Any other ideas?  Which one do you think will be fastest?

I'd guess that a suitable regex (and see whether there's an
existing character class that already has the right semantics) will
be by far the fastest.  Just anchor it on both ends and nothing will
have to do any fancy evaluation to test it.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: EOF while scanning triple-quoted string literal

[Seebs]

On 2010-10-15, Grant Edwards  wrote:
> Yes, all of the Unix syscalls use NULL-terminated path parameters (AKA
> "C strings").  What I don't know is whether the underlying filesystem
> code also uses NULL-terminated strings for filenames or if they have
> explicit lengths.  If the latter, there might be some way to bypass
> the normal Unix syscalls and actually create a file with a NULL in its
> name -- a file that then couldn't be accessed via the normal Unix
> system calls.  My _guess_ is that the underlying filesystem code in
> most all Unices also uses NULL-terminated strings, but I haven't
> looked yet.

There's some dire magic there.  The classic V7 or so filesystem had 16-byte
file names which were null terminated unless they were 16 characters, in
which case they weren't but were still only 16 characters.  Apart from that,
though, so far as I know everything is always null terminated.

The weird special case is slashes; you can never have a slash in a file name,
but at least one NFS implementation was able to create file names containing
slashes, and if you had a Mac client (where slash was valid in file names),
it could then create files with names that you could never use on the Unix
side, because the path resolution code kept trying to find directories
instead.  This was, worse yet, common, because so many people used
"mm/dd/yy" in file names!  Later implementations changed to silently
translating between colons and slashes.  (I think this still happened under
the hood in at least some OS X, because the HFS filesystem really uses
colons somewhere down in there.)

... But so far as I know, there's never been a Unix-type system where it
was actually possible to get a null byte into a file name.  Spaces, newlines,
sure.  Slashes, under rare and buggy circumstances.  But I've never heard
of a null byte in a file name.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: EOF while scanning triple-quoted string literal

[Seebs]

On 2010-10-15, Grant Edwards  wrote:
> On 2010-10-15, Steven D'Aprano  wrote:
>> In the Unix world, which includes OS X, text tools tend to have 
>> difficulty with tabs. Or try naming a file with a newline or carriage
>> return in the file name, or a NULL byte.

> How do you create a file with a name that contains a NULL byte?

So far as I know, in canonical Unix, you don't -- the syscalls all work
with something like C strings under the hood, meaning that no matter what
path name you send, the first null byte actually terminates it.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what happens to Popen()'s parent-side file descriptors?

[Seebs]

On 2010-10-14, Roger Davis  wrote:
> Seebs, you are of course correct that the example I quoted (`cat |
> grep | whatever`) is best done internally with the re module and built-
> in language features, and in fact that has already been done wherever
> possible. I should have picked a better example, there are numerous
> cases where I am calling external programs whose functionality is not
> duplicated by Python features.

Fair enough.  It's just a common pitfall when moving from shell to basically
any other language.  My first attempts to code in C involved a lot of
building up of system() calls.  :P

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-14, Hallvard B Furuseth  wrote:
> A class which holds an OS resource like a file, should provide a context
> manager and/or a release function, the latter usually called in a
> 'finally:' block.  When the caller doesn't bother with either, the class
> often might as well depend on the destructor in 'file'.

That makes sense.

In this case, I'm pretty sure context managers aren't the right tool (even
apart from version questions), because they appear to be syntax-level
tools -- but it's a runtime decision how many files I have to open and
close.

> For long strings, another option is triple-quoting as you've seen in doc
> strings: print """foo
> bar""".

I assume that this inserts a newline, though, and in this case I don't
want that.

> I've written such code, but I suppose the proper way is to use a
> classmethod to set it, so you can see in the class how the copyright
> gets there.  SourceFile.() and self.() both
> get called with the class as 1st argument.

Oh, that makes more sense.

> def setup_copyright(cls, fname):
> cls.copyright = open(fname).read()
> setup_copyright = classmethod(setup_copyright)
> # In python >= 2.4 you can instead say @classmethod above the def.

I *think* I get to assume 2.4.

> SourceFile.__repr__() looks like it should be a __str__().  I haven't
> looked at how you use it though.  But __repr__ is supposed to
> look like a Python expression to create the instance: repr([2]) = '[2]',
> or a generic '': repr(id) = ''.

Ahh!  I didn't realize that.  I was using repr as the "expand on it enough
that you can see what it is" form -- more for debugging than for
something parsable.

> Python 2.0, found as follows:
> - Google python list comprehensions.
> - Check the PEP (Python Enhancement Proposal) which shows up.  PEPs
>   are the formal documents for info to the community, for the Python
>   development process, etc.  :
> Title:List Comprehensions
> Status:   Final
> Type: Standards Track
> Python-Version: 2.0

Ah-hah!  That's helpful.  Thanks -- now I know how to find out next time
I'm curious.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Does everyone keep getting recruiting emails from google?

[Seebs]

On 2010-10-14, Daniel Fetchinson  wrote:
> I keep getting recruiting emails from charlesngu...@google.com about
> working for google as an engineer.

I've gotten one of those, ever, and it named a specific person who had
referred me.

(It turns out to be a moot point, $DAYJOB has telecommuting, and telecommuting
beats pretty much every other possible consideration in a job for me.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what happens to Popen()'s parent-side file descriptors?

[Seebs]

On 2010-10-13, Roger Davis  wrote:
> Hi, I am new to this group, please forgive me if this is a repeat
> question. I am a new Python programmer but experienced in C/Unix. I am
> converting a shell script to Python which essentially loops
> infinitely, each pass through the loop running commands like
>
>   set output = `cat this | grep that | whatever ...`
>
> My understanding is that this functionality is best coded via
> subprocess.Popen().

Actually...

It's probably BEST coded, when possible, by doing the work internally.

So:
thisfile = open('this')
lines = []
for line in thisfile:
if re.match('that', line):
lines.append(line)
whatever(lines)

... or something like that.

(Which you can write as a oneliner list comprehension, but I don't know
that it's got clarity)

Basically, don't use popen() unless the thing you'd be calling is something
hard enough to do that you really, really, want to run an external program
for it.  This is not a shell script; it is not just there to be glue
around other programs.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-13, Ben Finney  wrote:
> Python borrows from C in that consecutive literal strings are
> concatenated in the bytecode::
>
> stderr.write(
> "WARNING:"
> " Pants on fire\n")

Hmm.  So I just indent stuff inside the ()s or whatever?  I can work with
that.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-13, Chris Torek  wrote:
> Unfortunately "with" is newish and this code currently has to
> support python 2.3 (if not even older versions).

I think it might be 2.4 and later.  I'm not sure.  Of course, this being
the real world, the chances that I'll be able to stick with "Python 2" and
not have to simultaneously also support Python 1 and Python 3 are probably
about 20%.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-13, Jonas H.  wrote:
> Not really. Files will be closed when the garbage collector collects the 
> file object, but you can't be sure the GC will run within the next N 
> seconds/instructions or something like that. So you should *always* make 
> sure to close files after using them. That's what context managers were 
> introduced for.

>  with open('foobar') as fileobject:
>  do_something_with(fileobject)

That makes sense.  I don't think it'd quite work in this case, because I
want to open several files all at once, do a ton of work that populates
them with files, and then close them all.

This is a nice idiom, though.  In C, I've been sort of missing that idiom,
which I first encountered in Ruby.  (I mean, spelled differently, but the
same basic thing.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-13, Jean-Michel Pichavant  wrote:
> If you wonder about some defects reported by such linters, you can then 
> ask in this list why something is not that good, because it may not be 
> always obvious.

> 'pylint' is one them, pretty effective.

Okay, several questions about stuff pylint found.

1.  If I have a message that I wish to print, it is quite possible
that message + indentation exceeds 80 lines.  What's the idiomatic way
to solve this?  Do I just break the string up into parts, or do I just
accept that some lines are over 80 characters, or what?
2.  It warns about **kw, both because the name is short and because of
the "** magic".  I was previously advised that the name "kw" is canonical
for that usage, in which case, why am I getting linted at?
3.  More generally, the usage of **kw is probably not really right, but I'm
not sure what to do.

The issue here is as follows:

In C, some functions have an optional argument with the curious trait that,
if present, it is always of the same type.  e.g., open(2).  In my wrappers,
I indicate this by declaring it as something like "...{mode_t mode}".  The
intent is that in a declaration, this will turn into:
foo(blah blah blah, ... /* mode_t mode */)
so there's an indication of why there's a "..." there.
But C comments don't nest.  And there's a couple of points where I want to
put the declaration in a comment.  So in those cases, I need to do something
other than /*...*/:
/* foo(blah blah blah, ... mode_t mode) */

The problem:  The determination of whether I wish to do this is at the level
of the "represent this function in the following way" (Function.comment()),
but the implementation is two layers down.  So right now, I am passing
down 'comment = True' from the top level through, and I'm doing it using
a **kw keyword argument.

The rationale is that I could just use
def decl(comment = False):
...
but then the invocation:
func.decl(True)
would be utterly opaque.  I want to name the thing I'm passing or otherwise
indicate what it is.

It could be that I am Doing This Wrong.  Is there a good idiom for labeling
optional arguments, and passing them on (if they exist)?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-13, Chris Rebert  wrote:
> For future reference, the significant majority of things in Python
> raise exceptions upon encountering errors rather than returning error
> values of some sort.

Yes.  I'm getting used to that -- it's a bit of a shift, because I'm
used to exceptions being *exceptional* -- as in, not a failure mode
you would expect to see happening.  So for instance, I wouldn't expect
to get an exception for EOF, because that's not exceptional, that's
virtually guaranteed to happen whenever you interact with files.  I am
gonna have to retrain a bit.

> Aside from APIs which explicitly provide a parameter to be returned as
> a default value in case of error (e.g. getattr(obj, name, default)),
> the only common exception* I can come up with off the top of my head
> is str.find()**, and even that has an exception-throwing cousin,
> str.index().

Interesting!  That may take me some getting used to.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-12, Hallvard B Furuseth  wrote:
>> list = map(lambda x: x.call(), self.args)
>> return ', '.join(list)
>
>   return ', '.join([x.call() for x in self.args])

I think I wrote that before I found out about list comprehensions.  How
new are list comprehensions?

I do like that, it's clearer.

>> self.type, self.name = None, None

> Actually you can write self.type = self.name = None,
> though assignment statements are more limited than in C.
> (And I think they're assigned left-to-right.)

Okay.

>>  match = re.match('(.*)\(\*([a-zA-Z0-9_]*)\)\((.*)\)', text)

> Make a habit of using r'' for strings with lots of backslashes,
> like regexps.

Hmm.  There's an interesting question -- does this work as-is?  I'm
assuming it must or it would have blown up on me pretty badly, so
presumably those backslashes are getting passed through untouched
already.  But if that's just coincidence (they happen not to be valid
\-sequences), I should definitely fix that.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-12, MRAB  wrote:
> The code does require Python 2 and the use of except ... as ... requires 
> at least version 2.6.

Whoops.

> Line 51

> The __init__ method should always return None. There's no need to be 
> explicit about it, just use a plain "return".

The real issue here is that I was assuming that open('nonexistent') returned
None rather than raising an exception.

> The error message says:

>  "Couldn't open %s to read a template."

> but it's opening the file for writing.

Ahh, my famed attention to detail strikes again. :)

> You can't really rely on the destructor __del__ being called.

Interesting.  Do I just rely on files getting closed?

> Line 333

> Shouldn't you be checking that the name of the attribute you're setting 
> doesn't clash with one of the existing attributes? Are you sure that a 
> dict wouldn't be a better idea?

Actually, not sure at all.  There's a sort of gradual evolution going on
here, in that I was trying to avoid having a separate dict that I had to
populate with a bunch of stuff -- thus the switch to a hand-written
__getitem__.  What I probably ought to do/have done is use a dict first,
and set things in the dict from here, then check the dict first, then
regular getattr, and so on.

> Line 447
>
> The form:
>
>  except ... as ...
>
> is in Python versions >= 2.6, but not earlier.

Oops.  Is there a way to interact with the caught exception in earlier
Python?

> This use of del just deletes the name from the namespace and won't 
> necessarily call the __del__ method of the 'source' object. It's better 
> to rely on something more explicit like a 'close' method. (If you can't 
> be sure which version of Python it'll use then context managers are 
> probably out anyway!)

Okay, good to know.  I'll fix that.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-12, Chris Rebert  wrote:
> 2.
> self.f = file(path, 'r')
> if not self.f:
> return None
>
> The "if" here is pointless; I'm reasonably sure files are always
> considered boolean true.

I actually seem to have done this wrong anyway -- I was thinking in
terms of the C-like idiom of returning NULL when a constructor-like thing
fails.  This ought to have been a raise of some sort to prevent the caller
from getting an object that didn't work out.

> Python's grammar has "not in" as an "operator" for just such occasions ==>

Ahh!

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My first Python program

[Seebs]

On 2010-10-12, Jonas H.  wrote:
> Just a few pointers, looks quite good to me for a newbie :)

Thanks!

> * Less action in __init__.

I'm a bit curious about this.  The __init__ functions in this are, at
least for now, pretty much doing only what's needed to create the objects
from their inputs.

> * Use `open` instead of `file` to open a file

Done.

> * Have a look at context managers for file handling (avoids doing 
> error-prune stuff like __del__)

Okay.  I wasn't at all sure the __del__ was needed.

> * Your `del` in line 464 is useless. A reference will be removed from 
> the object bound to the local variable 'source' anyway because of the 
> re-assignment.

Oh.  D'oh.  You can see the C programmer instinct there; that was the
sort of thing that would, in C, be:
for (i = 0; i < n; ++i)
free(array[i]);

But of course, that doesn't work.  I guess that leads to a general question:
Is it safe for me to assume that all my files will have been flushed and
closed?  I'd normally assume this, but I seem to recall that not every
language makes those guarantees.

> * according to common Python style guides you should not use underscores 
> in class names.

Makes sense.  I was finding "CArgument" hard to read, and couldn't think
of a better name.

> * no need for 'r' in `open` calls ('r' is the default mode)

'k.

> * `line == ''` can be written more pythonic as `not line`

'k.

> * `str.{r,l,}strip` removes '\n\t\r ' by default, no need for an 
> argument here (line 440 for example)

Ahh, good to know.

> * you might want to pre-compile regular expressions (`re.compile`)

Thought about it, but decided that it was probably more complexity than I
need -- this is not a performance-critical thing.  And even if it were, well,
I'm pretty sure it's I/O bound.  (And on my netbook, the time to run this
is under .2 seconds in Python, compared to 15 seconds in shell, so...)

> * raising `Exception` rather than a subclass of it is uncommon.

Okay.  I did that as a quick fix when, finally having hit one of them,
I found out that 'raise "Error message"' didn't work.  :)  I'm a bit unsure
as to how to pick the right subclass, though.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

My first Python program

[Seebs]

So, I'm new to Python, though I've got a bit of experience in a few other
languages.  My overall impressions are pretty mixed, but overall positive;
it's a reasonably expressive language which has a good mix between staying
out of my way and taking care of stuff I don't want to waste attention on.

My first project was to replace a shell script with a Python script.  The
context is a project ("pseudo") which does some really hairy stuff in C.
Part of what it does involves creating hundreds of stub functions.  The
existing shell script did this successfully, but wasn't particularly
fast, and was basically unmaintainable.  So I've redone it in Python.

The input is a list of C function declarations, such as:
int foo(char *s);
and the output is several files, which include lists of these functions,
declarations for wrappers for them, and so on.  So that would produce
something to the effect of:
int foo(char *s) {
   /* various magic */
   int rc = -1;
   /* stuff happens */
   rc = wrap_foo(s);
   /* more magic */
   return rc;
}

Where it gets complicated is that there are, of course, special cases;
for instance, the wrapper for 'int open(char *path, int mode, int flags)' has
to know that the flags argument is conditional, and not always provided, so
it declares open as "int open(char *path, int mode, ...)", then extracts
flags using a va_list.  Weird stuff ensues.  It's a pretty weird hunk of
code.

The source in its current form:

http://github.com/wrpseudo/pseudo/blob/master/makewrappers

The underlying task is fairly ugly, and it's my first Python project,
so the result isn't particularly pretty, but I'd be interested in
feedback on it.  However, I'm not at all sure whether it's appropriate for
this group to post 467 lines of code with no question beyond "how am
I screwing this up?"

At this point, it does everything I want it to do, so the question isn't
"how can I do this?", but "how should I have done this more idiomatically?"

There's a few quirks; one is that I have to run on whatever Python happens
to be installed on a variety of systems, from RHEL4 to Fedora 13 or so.
(It is, at least for now, completely unimportant whether I run on non-Linux
systems.)  I can't rely on packages or extensions which aren't going to
be in the base Python install.

Apart from that... I'm interested in feedback.  I'm not expecting that
this is good or idiomatic Python, but I'd like to learn to write Python
correctly and expressively, and there's nothing like criticism to improve
code.  And if people would prefer that I post the code here, I could,
I just figured that it was a bit large.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-11, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> ... but I wasn't aware that it had been deprecated, except in the sense of
>> being derided and dismissed as of no value.

> What more did you want? :)

Well, formal "deprecation" in the language standards sense, as in, "warning,
we will be removing this from future versions of this language".  There's a
difference between something like gets() or tempnam(), where some compilers
will refuse to link programs which call them, and something like scanf(),
where I've never heard of a compiler doing anything of the sort.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Testing for changes on a web page (was: how to find difference in number of characters)

[Seebs]

On 2010-10-09, harryos  wrote:
> What I meant by number of characters was the number of edits happened
> between the two versions..

Consider two strings:

Hello, world!

Yo, there.

What is the "number of edits happened between the two versions"?  It could
be:

* Zero.  I just typed them both from scratch, no editing occurred between
  them.
* Two.  Two words are different.
* Ten or so -- counting changed characters.
* Three.  Two words and a punctuation mark are different.

In other words, your problem here is that you haven't actually described
what you want.  Slow down.  Think!  Describe what you want clearly enough
that any other person who reads your description can always come up with
the same answer you would for a given set of inputs.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHON

[Seebs]

On 2010-10-08, k..  wrote:
> PLEASE LEARN ME PYTHON

Done!

Please be sure to drop by sometimes to let us know how it's going, now
that we've learned you Python.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list parameter of a recursive function

[Seebs]

On 2010-10-07, TP  wrote:
> Diez B. Roggisch wrote:
>> A safer alternative for these cases is using tuples, because they are
>> immutable.

> The problem with tuples is that it is not easy to modify them:

This is probably the best post-and-response I've seen in the last couple
of months.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-07, John Nagle  wrote:
> First, "scanf" was deprecated over five years ago.

It was?  I mean, people have been telling me not to use it since the 80s,
but I wasn't aware that it had been deprecated, except in the sense of being
derided and dismissed as of no value.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-06,   wrote:
> plz can u convert this cpp file into python i need that badly as soon as
> possible... I am new to python. I just wanna learn it

Having come to realize that this is a homework problem, I would of course
be glad to.

The original program:

#include

int main()
{
int a[100], n;
freopen("input.txt", "r", stdin);
scanf("%d", &n);
for(int i=1; i<=n; i++)
scanf("%d", &a[i]);
return 0;
}

So, let's convert this.

#!/usr/bin/python -w
import cstdio;

def main():
a = [random.randint(-2147483648,2147483647) for i in range(0,100)]
n = random.randint(-2147483648)
sys.stdin = open("input.txt", "r")
raise IndexError

I'm not sure how much good this will do you.  It seems to me that you
might get better results translating a program which was not obviously
incorrect.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-06, Diez B. Roggisch  wrote:
> From the look of it... he's just trying to get a freebie on a homework
> assignment. It certainly is no commercial/useful piece of code
> whatsoever... just CS-101 "read data from stdin and do stuff".

Ooh, I should go help, then.

I *love* to help people on homework.  Although I may not know Python
well enough.

I once responded to a request for a thing that, given a number, says
something like "The first digit is 3, the second digit is 2" with a program
that included a partial table of ln(x) for about 30 values between 0 and
900...  It worked, though!

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-06, Diez B. Roggisch  wrote:
> With an impressive amount of technological experience under his belt. So
> I'm a bit aghast to see him struggle with this rather simple
> problem. Thus my question...

It does seem a bit odd.

I mean, if I had a short time line to get something converted to Python,
I'd probably ask for help, but then, I wouldn't take a gig where I needed to
quickly move something into an unfamiliar language.  I'm happily puttering
away slowly at converting a couple of things to Python to get the hang of it,
carefully selecting things with no impending deadlines.

Thus far, I've converted a shell script to Python.  It was... well, shell
turned out to be a poor language for it, but I do note that the shell
script, including all the here documents, was quite a bit smaller than the
Python.  On the other hand, I think the Python script is a lot more
maintainable, and this despite me not really knowing the language particularly
well.  It's an interesting tradeoff.  Still getting used to the Python
way of doing things.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: suggestions please "what should i watch for/guard against' in a file upload situation?"

[Seebs]

On 2010-10-06, Diez B. Roggisch  wrote:
> Seebs  writes:
>> On 2010-10-06, geekbuntu  wrote:
>>> in general, what are things i would want to 'watch for/guard against'
>>> in a file upload situation?

>> This question has virtually nothing to do with Python, which means you
>> may not get very good answers.

> In contrast to "comp.super.web.experts"? There are quite a few people
> with web-experience here I'd say. 

Oh, certainly.  But in general, I try to ask questions in a group focused
on their domain, rather than merely a group likely to contain people who
would for other reasons have the relevant experience.  I'm sure that a great
number of Python programmers have experience with sex, that doesn't make
this a great newsgroup for sex tips.  (Well, maybe it does.)

> Given that most people are not computer savvy (always remember, the
> default for windows is to hide extensions..), using it client-side can
> be valuable to prevent long uploads that eventuall need to be rejected
> otherwise (no mom, you can't upload word-docs as profile pictures).

That's a good point.  On the other hand, there's a corollary; you may want
to look at the contents of the file in case they're not really what they're
supposed to be.

> Your strange focus on file-names that are pure meta information is a
> little bit concerning... 

If you're uploading files "into a directory", then it is quite likely that
you're getting file names from somewhere.  Untrusted file names are a much
more effective attack vector, in most cases, than EXIF information.

> Certainly advice. But that's less focussed on filenames or file-uploads, but
> on the whole subject of processing HTTP-requestst. Which would make a
> point for *not* using a home-grown framework.

Well, yeah.  I was assuming that the home-grown framework was mandatory for
some reason.  Possibly a very important reason, such as "otherwise we won't
have written it ourselves".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help!!!

[Seebs]

On 2010-10-06, Diez B. Roggisch  wrote:
> writes:
>> plz can u convert this cpp file into python i need that badly as soon as 
>> possible... I am new to python. I just wanna learn it

> For such an aspiring student of the art of computer programming, I have
> the strange feeling of lack-of-effort-showing here. Do I have to lose my
> faith in youth?

Never!

Just be sure you are having faith in them to, well, be youth.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: suggestions please "what should i watch for/guard against' in a file upload situation?"

[Seebs]

On 2010-10-06, geekbuntu  wrote:
> in general, what are things i would want to 'watch for/guard against'
> in a file upload situation?

This question has virtually nothing to do with Python, which means you
may not get very good answers.

> my checklist so far is basically to check the extension - ensure it
> has 3 places, ensure it's in the allowed list (like jpg gif etc...).

This strikes me as 100% irrelevant.  Who cares what the extension is?

> not sure what else i could do to guard against anything bad
> happening.  maybe the file name itself could cause greif?

Obvious things:

* File name causes files to get created outside some particular
  upload directory ("../foo")
* File name has spaces
* Crazy stuff like null bytes in file name
* File names which might break things if a user carelessly interacts
  with them, such as "foo.jpg /etc/passwd bar.jpg" (all one file name
  including two spaces).

Basically, the key question is, could a hostile user come up with
input to your script which could break something?

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I don't get why sys.exit(1) doesn't exit the while loop in the follow case

[Seebs]

On 2010-10-05, Lawrence D'Oliveiro  wrote:
> In message <87iq1hz6rc@benfinney.id.au>, Ben Finney wrote:
>> Don't ever use a bare ???except??? unless you know exactly why you're doing
>> so.

> In other news, don???t ever put a loaded gun in your mouth and pull the 
> trigger unless you know exactly why you???re doing so.

I don't think those are at all comparable, I've heard of people who had
plausible arguments for the gun.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get partition information of a hard disk with python

[Seebs]

On 2010-10-05, Lawrence D'Oliveiro  wrote:
> In message , Anssi Saari wrote:
>> Because for the common case it's simple and easy and one might learn
>> something interesting?

> You consider it ???interesting??? to reinvent stuff that others have already 
> done?

That isn't what the other poster said.  The claim was that you might learn
something interesting.

When I reinvent stuff others have already done, I usually do indeed learn
something interesting.  It may not be a good use of my time, but...

Here's the thing.  As a learning exercise, "reinvent something others have
already done" is excellent.  It means you have working code to study and
think about.  Once you already know everything, of course, it stops being
useful, and then there's no reason to ever duplicate existing code.

But I learned more from writing a roguelike game which was pretty much in
no way superior to existing roguelikes than I would have from trying to
invent a new kind of game when I didn't understand how to program in the
first place, I suspect.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SQLite is quite SQL compliant

[Seebs]

On 2010-10-03, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> sqlite is a source of joy, a small bright point of decent
>> and functional software in a world full of misbehaving crap.

> Have you learnt how to be selective in your downloads yet?

Sadly, as a side-effect of my day job, I am often obliged to work with
arbitrary software that someone somewhere specified as part of a requirement.

It is stunning how often you can guess which of two packages will be the
source of a bug just by seeing which one hurts more to look at.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sequence multiplied by -1

[Seebs]

On 2010-10-03, Steven D'Aprano  wrote:
> On Sat, 02 Oct 2010 12:50:02 -0700, Dennis Lee Bieber wrote:
>>  Well... We could maybe borrow from REXX... and 
>> use  ||  for concatenation.

>|| for concatenation? What's the connection between the pipe character 
> and concatenation?

That it's used for concatenation in at least two languages (REXX and SQL).

> It seems to 
> me that || was just plucked out of the air because it was unused.

That's quite possible in the past, but now it'd probably be done for
consistency with some other language that did it already.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SQLite is quite SQL compliant

[Seebs]

On 2010-10-02, Ravi  wrote:
> The documentation of the sqlite module at 
> http://docs.python.org/library/sqlite3.html
> says:

> "...allows accessing the database using a nonstandard variant of the
> SQL..."

> But if you see SQLite website they clearly say at 
> http://sqlite.org/omitted.html
> that only very few of the SQL is not implemented. I think docs should
> clarify on that. Many users might be scared of using SQLite just
> because of this.

I would agree that the word "nonstandard" seems to be a little strong and
discouraging.  sqlite is a source of joy, a small bright point of decent
and functional software in a world full of misbehaving crap.  While it
does omit a few bits of SQL functionality, I'd call it perhaps a "slightly
incomplete implementation" rather than a "nonstandard variant".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to find free resident memory in Linux using python

[Seebs]

On 2010-10-02, Sandy  wrote:
> I want to find how much free memory (RAM) is available in my system
> using python.

The question is essentially incoherent on modern systems.  You'd have to
define terms.  Consider that on a given system, it's quite possible that
gigabytes of space are being used to cache disk buffers.  Some of those
could be freed as soon as they get written; some could be freed simply by
dropping them, since they're just a read cache.  There may be data which
have been paged out, and will be paged back in as soon as possible -- meaning
that freeing up space wouldn't actually increase the number of available
pages of memory for long.

So basically, the question isn't all that well defined.  You can get all
sorts of numbers.  They may or may not mean anything.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, Pascal J. Bourguignon  wrote:
> Seebs  writes:
>> On 2010-10-01, Pascal J. Bourguignon  wrote:
>>> compiler passes wrong type  wrong resultfails at run-time
>>> (the programmer (with exception
>>> spends hoursexplaining this is
>>> finding the the wrong type)
>>> problem)
>
>> I have no clue what exact scenario you're talking about here.  I've never
>> seen a bug that could plausibly be described as "compiler passes wrong
>> type" which wasn't picked up quickly by running with more warnings enabled.

> This is the scenario discussed in this thread, a long is passed to
> maximum without a compiler warning.

The compiler didn't pass the wrong type, the user did.

>> And on the other end of things, it is not always obvious or straightforward
>> to figure out *why* the dynamic language has ended up with something of the
>> wrong type, or what's wrong with that type.

> It is on the contrary rather obvious or easily discoverable, looking at
> the backtrace, and inspecting the data structures referenced from it.

This is a fascinating assertion, but it is slightly marred by not actually
being generally true.  It's often the case that it's pretty obvious, but
sometimes it's not so obvious -- it can take quite a bit of doing to figure
out how or where some hunk of a data structure got set up wrong.  It's very
easy to find the call where a nil was passed to something expecting some kind
of integer; it's sometimes not so easy to find the completely unrelated hunk
of code which modified the data structure half an hour earlier.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, Steven D'Aprano  wrote:
> Now can we (by which I mean *you*) stop cross-posting C talk to multiple 
> newsgroups that don't have anything to do with C?

Fair enough.  The original thread does seem to have been crossposted in
an innovative way.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, RG  wrote:
> Again, you can't have it both ways.  Either a warning is a "compiler 
> error" according to the claim at issue (see below) or it is not.  If it 
> is, then this is a false positive.

No, it isn't.  It's a correctly identified type mismatch.

You keep moving the goal posts from the actual standard of a false positive
(the compiler warns that something is of the wrong type when it's not of
the wrong type) to a made-up standard (the compiler warns that something is
of the wrong type when it is indeed of the wrong type, but could be safely
converted to the right type).

It doesn't matter whether, in a given case, you *could* safely perform
the conversion.  If you don't perform the conversion, and the compiler points
this out, that's not a false positive.

>> Those goal posts are sorta red shifted at this point.

> At this point I would like to quote a wise man who once said:

>> May I suggest that, if you don't want to use words and terminology
>> precisely, perhaps computer programming is not for you?

> Red shifted?

Moving away fast enough that their color has visibly changed.

> The truth of this claim hinges on the definitions of "work", "never blow 
> up", "invalid", "call incorrectly" and "compile error."  Define these 
> however you like, the result will be that the claim is either false or 
> vacuous.

Not really.  If you use the most obvious and natural meanings *for a
statically typed language*, it is obvious that it is true.

And indeed, significantly so.  In the real world, programs written in
scripting languages with runtime typing are fairly likely to throw occasional
exceptions because something is of the wrong type.  In a statically typed
language, the of-the-wrong-type is something which can, by definition, be
caught at compile time.

The fundamental thing you seem to be getting stuck on is that you're assuming
that if a conversion could be made, that it should be and it should be
automatic and silent.  That, however, is at odds with discussion of a
statically typed language.  There's a reason we have the option of converting
things from one type to another.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, Pascal J. Bourguignon  wrote:
> static  dynamic
>
> compiler detects wrong type fail at compile fails at run-time
> (with exception
> explaining this is
> the wrong type)

Unless, of course, the "wrong type" happens to be compatible enough to
pass.  In which case, it's unclear whether it is the "wrong type" or not.

> compiler passes wrong type  wrong resultfails at run-time
> (the programmer (with exception
> spends hoursexplaining this is
> finding the the wrong type)
> problem)

I have no clue what exact scenario you're talking about here.  I've never
seen a bug that could plausibly be described as "compiler passes wrong
type" which wasn't picked up quickly by running with more warnings enabled.

And on the other end of things, it is not always obvious or straightforward
to figure out *why* the dynamic language has ended up with something of the
wrong type, or what's wrong with that type.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, Pascal J. Bourguignon  wrote:
> Seebs  writes:
>> The obvious simple maximum() in C will not raise an exception nor return
>> something which isn't an int in any program which is not on its face
>> invalid in the call.  This is by definite contrast with several of the
>> interpreted languages, 

> This has nothing to do with the fact that these languages have
> implementations using the interpreter pattern instead of a compiler.

True, but it's a good enough statistical correlation to serve in many
cases.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, TheFlyingDutchman  wrote:
>> > ? ? ? ? in C I can have a function maximum(int a, int b) that will always
>> > ? ? ? ? work. Never blow up, and never give an invalid answer. If someone
>> > ? ? ? ? tries to call it incorrectly it is a compile error.

>> I would agree that the third sentence is arguably wrong, simply
>> because there's no such thing (outside #error) of a mandate to stop
>> compiling. ?However, my understanding was that the dispute was over
>> the second sentence, and that's certainly correct.

> Why do you consider the term "compile error" a "mandate to stop
> compiling"?

Because that's what people normally mean -- compilation failed.

> What do you say to refer to the situation when you have a
> statement in your program that the compiler finds is an error? And is
> it really material whether the compiler flagged an error and stopped,
> or flagged an error and looked for additional errors???

It might be, because someone might argue that if the compiler will generate
code for a bad construct, it hasn't really produced a "compiler error", just
a warning.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-10-01, Don Geddis  wrote:
> in C I can have a function maximum(int a, int b) that will always
> work. Never blow up, and never give an invalid answer. If someone
> tries to call it incorrectly it is a compile error.

I would agree that the third sentence is arguably wrong, simply
because there's no such thing (outside #error) of a mandate to stop
compiling.  However, my understanding was that the dispute was over
the second sentence, and that's certainly correct.

The obvious simple maximum() in C will not raise an exception nor return
something which isn't an int in any program which is not on its face
invalid in the call.  This is by definite contrast with several of the
interpreted languages, where a function or subroutine like that cannot
specify that its argument must be some kind of integer.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, RG  wrote:
> I don't want to quibble over terminology.

May I suggest that, if you don't want to use words and terminology
precisely, perhaps computer programming is not for you?

> Whatever label you choose to 
> put on it ("false positive", "not being able to express some things 
> without special extra effort") I consider it a deficiency.

Oh, it definitely is a deficiency.

However, the deficiency is that you have to do extra work to get data
safely in, and you have to figure out for yourself how you want to
handle things if, say, you have a value which is not of the right type,
and you want to make it be of the right type, but it may not be possible
to do so.

It is, however, entirely possible to write a function which returns
the maximum of its two inputs, 100% reliably, in C.

> The costs are greater than the benefits.  Reasonable people can
> (and obviously do) disagree.

I tend to think it depends on what I'm trying to do, and why I'm trying
to do it.  There are plenty of tasks for which I prefer C's semantics to
those of most scripting languages -- and others for which I prefer scripting
language semantics.

In practice, I have dozens to hundreds of times more problems with
scripting languages where something ends up being of the wrong type (or more
precisely, not of any of the types which can be used in that context) than I
have, say, overflow problems in C.  On the other hand, it's usually much
easier to catch them and deal with them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, RG  wrote:
> That gives (what I would consider to be) false positives, e.g.:

> [...@mighty:~]$ cat foo.c

> void foo(long x) {}

> int main() { foo(1); }
> [...@mighty:~]$ gcc -Wconversion foo.c
> foo.c: In function ???main???:
> foo.c:4: warning: passing argument 1 of ???foo??? with different width due 
> to prototype

But it's *not* a false positive.  The compiler is not claiming that the
conversion couldn't be done -- it's just telling you that there is a
change of type going on.

If you don't want that message, it is certainly possible to write code
which won't get it, and which will reliably work everywhere.

> So you have to choose your compiler 
> (and flags) first, and then I get to construct my example.  If my 
> example has *either* an error that the compiler doesn't catch *or* a 
> non-error that it does catch then I win.

Those goal posts are sorta red shifted at this point.

You're redefining "error" and "non-error" so as to demand that a statically
typed language offer you the same semantics of errors and non-errors that
dynamically typed languages have.  That's cheating, though.  The claim
is about C, not about what people who are expecting a dynamically typed
language would like C to be like.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, Ian Collins  wrote:
> Which is why agile practices such as TDD have an edge.  If it compiles 
> *and* passes all its tests, it must be right.

So far as I know, that actually just means that the test suite is
insufficient.  :)

Based on my experience thus far, anyway, I am pretty sure it's essentially
not what happens that the tests and code are both correct, and it is usually
the case either that the tests fail or that there are not enough tests.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, Keith Thompson  wrote:
> Seebs  writes:
>> On 2010-09-30, Paul Rubin  wrote:
>>> int maximum(int a, int b);

>>> int foo() {
>>>   int (*barf)() = maximum;
>>>   return barf(3);
>>> }

> That first line declare barf as an object of type "pointer to
> function returning int", or more precisely, "pointer to function with
> an unspecified but fixed number and type of parameters returning int"
> (i.e., an old-style non-prototype declaration, still legal but
> deprecated in both C90 and C99).  It then initializes it to point
> to the "maximum" function.  I *think* the types are sufficiently
> "compatible" (not necessarily using that word the same way the
> standard does) for the initialization to be valid and well defined.
> I might check the standard later.

Hmm.  You have a point.  It's clearly a conversion from one type
to another.

> IMHO it's better to use prototypes consistently than to figure out the
> rules for interactions between prototyped vs. non-prototyped function
> declarations.

Yes.  It's clearly undefined behavior to call a function through a
pointer to a different type, or to call a function with the wrong number
of arguments.  I am pretty sure at least one compiler catches this.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list