Re: Too much code - slicing
On Thu, Sep 23, 2010 at 12:23:22AM +, Steven D'Aprano wrote: On Tue, 21 Sep 2010 16:17:48 +0200, Antoon Pardon wrote: On Tue, Sep 21, 2010 at 12:07:07AM +, Steven D'Aprano wrote: On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. If he did, then he must have changed his mind, because there is nothing ugly about the ternary operator we ended up with. That is a question of taste Yes, it certainly is. Describing it as an ugly format is also a matter of taste -- taste which in my opinion simply isn't justified by anything other than familiarity. There is the facts that it broke familiarity with a common pattern. This form only ranked fourth (or maybe third), with the first three all wanting ar structure with the elelement is this order: condition, true case, false case Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. That's sheer and unadulterated nonsense. The fact is that Guido changed his mind about ternary if after discovering that the work-around true-clause and condition or false-clause is buggy -- it gives the wrong answer if true-clause happens to be a false value like [], 0 or None. If I recall correctly, the bug bit Guido himself. Nonsense. That the work around was buggy was known years before the ternary operator was finally introduced. But people kept forgetting it, and it bit the right person one time too many. So? That it took years between the knowledge that the work-around failed and a ternary operator finally appearing is still a fact. Which casts doubts that is was this knowledge that made him change his mind. The introduction of list comprehension made a ternary operator that more usefull but every time it came up the supporters of Guido, told us we just had to define a function if we wanted the items to depend on a condition. A function can't do the job, because it isn't lazy: def ifte(condition, x, y): if condition: return x else: return y n = 0 ifte(n != 0, 100/n, -1) will fail. This was perhaps *the* killer argument for a ternary-if operator. You really don't seem to remember what happened then. Someone would come with a problem that we can now solve as follows. ls = [ el / 2 if el % 2 == 0 else 3 * el + 1 for el in ls ] and the respons would be that we just needed to write is as follows: def f(el): if el % 2 == 0: return el / 2 else: return 3 * el + 1 ls = [ f(el) for el in ls ] -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Thu, 23 Sep 2010 11:42:25 -0400, Andreas Waldenburger wrote: On Wed, 22 Sep 2010 20:45:55 -0500 John Bokma j...@castleamber.com wrote: What surprises me is that this is still discussed. It's like argueing about significant whitespace. :-) Which is evil! Iagreethatsignioficantwhitespaceisevil.Pythonshouldbelikeearlyver sionsofFortran,whichhadnosignificantwhitespace.Muchbetter,inmyopi nion. *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 23 Sep 2010 03:54:52 GMT Seebs usenet-nos...@seebs.net wrote: On 2010-09-23, Steven D'Aprano steve-remove-t...@cybersource.com.au wrote: [snip] I don't see anyone bitching about: for x in seq: if x: f(x) vs [f(x) for x in seq if x] In my case, that's because I only ran into that syntax about an hour and a half ago. I have the same basic objection to it. If it were: [for x in seq: if x: f(x)] I'd find it substantially easier to understand. I don't generally like constructs where important structural information comes late in the construct. [snip] I think that is precisely the reason that the elements of the list come *first* in the list comprehension expression. The foremost idea of list comprehensions is build a list, while the idea of a for-loop is iterate over something. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 23 Sep 2010 00:33:28 GMT Steven D'Aprano steve-remove-t...@cybersource.com.au wrote: On Tue, 21 Sep 2010 12:26:29 -0400, Andreas Waldenburger wrote: On Sat, 18 Sep 2010 19:09:33 -0700 (PDT) Carl Banks pavlovevide...@gmail.com wrote: On Sep 17, 1:01 pm, Andreas Waldenburger use...@geekmail.invalid wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. I don't know if it'll ever look good, per se, but it looks better when it's used in rule-exception sort of case: something = rule if condition else exception Spot on. I (more or less) like it when used that way, too. But it seems to invite crackers like the example above, and that irks me. I don't see that one of these is more of a cracker than the other: code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)] code = side == 'l' if dir[int(num):] else dir[:-1*int(num)] code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] If you ask me, the *least* hard to read is the last. I agree again. I wasn't really talking about the specific order of the ternary operator but rather about the whole idea. It invites messiness. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Wed, 22 Sep 2010 20:45:55 -0500 John Bokma j...@castleamber.com wrote: What surprises me is that this is still discussed. It's like argueing about significant whitespace. :-) Which is evil! /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-23, Andreas Waldenburger use...@geekmail.invalid wrote: On 23 Sep 2010 03:54:52 GMT Seebs usenet-nos...@seebs.net wrote: I don't generally like constructs where important structural information comes late in the construct. [snip] I think that is precisely the reason that the elements of the list come *first* in the list comprehension expression. The foremost idea of list comprehensions is build a list, while the idea of a for-loop is iterate over something. Interesting! I tend to think of building a list as more like a for loop than like a data item with a qualifier. If the first word inside the [] were for, that would tell me that the list was going to have some kind of looping or generating going on, while if it's an expression, especially a complicated expression, I don't know that right away. But I can see it making sense either way for the loop, just because of the similarity to mathematical notation. -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: Too much code - slicing
On Tue, 21 Sep 2010 08:17:00 +, Duncan Booth wrote: I guess you have worked hard to forget the and-or hack. It was actually: condition and true-clause or false-clause so its not quite the same pattern. So I did. Oops. Thanks for the correction. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Tue, 21 Sep 2010 16:17:48 +0200, Antoon Pardon wrote: On Tue, Sep 21, 2010 at 12:07:07AM +, Steven D'Aprano wrote: On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. If he did, then he must have changed his mind, because there is nothing ugly about the ternary operator we ended up with. That is a question of taste Yes, it certainly is. Describing it as an ugly format is also a matter of taste -- taste which in my opinion simply isn't justified by anything other than familiarity. and the poll and discussion earlier made it clear that this was not the preferred way to have a ternary operator. Not preferred != ugly This form only ranked fourth (or maybe third), with the first three all wanting ar structure with the elelement is this order: condition, true case, false case Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. That's sheer and unadulterated nonsense. The fact is that Guido changed his mind about ternary if after discovering that the work-around true-clause and condition or false-clause is buggy -- it gives the wrong answer if true-clause happens to be a false value like [], 0 or None. If I recall correctly, the bug bit Guido himself. Nonsense. That the work around was buggy was known years before the ternary operator was finally introduced. But people kept forgetting it, and it bit the right person one time too many. The introduction of list comprehension made a ternary operator that more usefull but every time it came up the supporters of Guido, told us we just had to define a function if we wanted the items to depend on a condition. A function can't do the job, because it isn't lazy: def ifte(condition, x, y): if condition: return x else: return y n = 0 ifte(n != 0, 100/n, -1) will fail. This was perhaps *the* killer argument for a ternary-if operator. [...] It seems that what changed is your memory and not the collective mind of the python community. Fair call. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Tue, 21 Sep 2010 12:26:29 -0400, Andreas Waldenburger wrote: On Sat, 18 Sep 2010 19:09:33 -0700 (PDT) Carl Banks pavlovevide...@gmail.com wrote: On Sep 17, 1:01 pm, Andreas Waldenburger use...@geekmail.invalid wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. I don't know if it'll ever look good, per se, but it looks better when it's used in rule-exception sort of case: something = rule if condition else exception Spot on. I (more or less) like it when used that way, too. But it seems to invite crackers like the example above, and that irks me. I don't see that one of these is more of a cracker than the other: code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)] code = side == 'l' if dir[int(num):] else dir[:-1*int(num)] code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] If you ask me, the *least* hard to read is the last. Unary and binary operators are natural in a language which is parsed in a single dimension (left-to-right in the case of English). There is no entirely natural way to parse a ternary operator, because you need to fit three operands into two slots. That's why mathematicians often use two dimensions when they need a ternary operator, like sum: ∞ ∑ expr i=0 -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
Steven D'Aprano steve-remove-t...@cybersource.com.au writes: For completeness sake: code = side == 'l' ? dir[int(num):] : dir[:-1*int(num)] code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)] code = side == 'l' if dir[int(num):] else dir[:-1*int(num)] code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] If you ask me, the *least* hard to read is the last. For me the (newly added) first one, because it has (for me) less noise. But I can certainly live with the last one. Or all for that matter. Or maybe: since the results are already somewhat complex (or noisy) I probably would use a normal if else. What surprises me is that this is still discussed. It's like argueing about significant whitespace. :-) -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-23, Steven D'Aprano steve-remove-t...@cybersource.com.au wrote: Yes, it certainly is. Describing it as an ugly format is also a matter of taste -- taste which in my opinion simply isn't justified by anything other than familiarity. It may not be convincing to other people, but the logical inversion strikes me as a taste issue which goes beyond mere familiarity. It is not unreasonable to continue to dislike something which breaks a general principle even after long familiarity. So I think there is a real issue. There are arguments going the other way, and while they don't fit my sense of aesthetics, I guess they aren't strictly required to. But I do think it's unfair to dismiss it as purely a matter of baby duck syndrome. Consistency in ordering of corresponding idioms seems a reasonable goal. -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: Too much code - slicing
On Thu, 23 Sep 2010 01:49:44 +, Seebs wrote: But I do think it's unfair to dismiss it as purely a matter of baby duck syndrome. Consistency in ordering of corresponding idioms seems a reasonable goal. I don't see anyone bitching about: for x in seq: if x: f(x) vs [f(x) for x in seq if x] -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-23, Steven D'Aprano steve-remove-t...@cybersource.com.au wrote: On Thu, 23 Sep 2010 01:49:44 +, Seebs wrote: But I do think it's unfair to dismiss it as purely a matter of baby duck syndrome. Consistency in ordering of corresponding idioms seems a reasonable goal. I don't see anyone bitching about: for x in seq: if x: f(x) vs [f(x) for x in seq if x] In my case, that's because I only ran into that syntax about an hour and a half ago. I have the same basic objection to it. If it were: [for x in seq: if x: f(x)] I'd find it substantially easier to understand. I don't generally like constructs where important structural information comes late in the construct. In the trivial case, I don't suppose it makes a huge difference, but think about the case where seq starts with a ( and x ends with one: [f(x) for x in (1, 2, 3) if foo(x)] As the expressions get complicated, that gets harder to see. IMHO. I dunno. I like the next if /^$/ idiom, but anything more complicated for either the condition or the thing conditionalized and I tend to prefer to jump back to an explicit if statement. -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: Too much code - slicing
Seebs usenet-nos...@seebs.net writes: I dunno. I like the next if /^$/ idiom, I don't (as a Perl programmer), I prefer: $line =~ /^$/ and next; Or: $line ne '' or next; which I read as: line must not be empty -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-23, John Bokma j...@castleamber.com wrote: Seebs usenet-nos...@seebs.net writes: I dunno. I like the next if /^$/ idiom, I don't (as a Perl programmer), I prefer: Huh, those are actually nicer. I didn't know that was possible; it wouldn't have occurred to me to try to put next (which I think of as a statement) into an expression. Basically, I can live with a postfix if as long as everything involved is trivial. Past that... I'd rather see the condition up front. -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: Syntax highlighting [was Re: Too much code - slicing]
On Sep 20, 1:29 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: To my eyes, the feature of syntax highlighting that alone makes it worthwhile, its killer feature, is that I can set comments and docstrings to grey. When I'm scanning code, being able to slide my eyes over greyed- out comments and docstrings and ignore them with essentially zero effort is a huge help. That's the thing I most miss, more than anything else, when using a dumb editor. Well dumb editors use syntax highlighting also... specifically the ones that default to bright (attention grabbing!) colors for comments and/or docstrings... like the color RED! Gawd i hate that! Never should a comment be a bright color, and RED is the worst choice of all! Grey for comments, orange for keywords, purple for builtins, and green for strings is pure bliss. Save red for scary things like global variables and such. That way you know where the hemorrhaging is coming from! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
Steven D'Aprano st...@remove-this-cybersource.com.au wrote: That's sheer and unadulterated nonsense. The fact is that Guido changed his mind about ternary if after discovering that the work-around true-clause and condition or false-clause is buggy -- it gives the wrong answer if true-clause happens to be a false value like [], 0 or None. If I recall correctly, the bug bit Guido himself. The and-or hack, which was *very* common in Python code for many years and many versions, follows the same pattern as ternary if: true-clause if condition else false-clause I guess you have worked hard to forget the and-or hack. It was actually: condition and true-clause or false-clause so its not quite the same pattern. Of course there's also the bug fixed version which I suspect was so ugly it was the real trigger for getting a real ternary operator: (condition and [true-clause] or [false-clause])[0] -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Tue, Sep 21, 2010 at 12:07:07AM +, Steven D'Aprano wrote: On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. If he did, then he must have changed his mind, because there is nothing ugly about the ternary operator we ended up with. That is a question of taste and the poll and discussion earlier made it clear that this was not the preferred way to have a ternary operator. This form only ranked fourth (or maybe third), with the first three all wanting ar structure with the elelement is this order: condition, true case, false case Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. That's sheer and unadulterated nonsense. The fact is that Guido changed his mind about ternary if after discovering that the work-around true-clause and condition or false-clause is buggy -- it gives the wrong answer if true-clause happens to be a false value like [], 0 or None. If I recall correctly, the bug bit Guido himself. Nonsense. That the work around was buggy was known years before the ternary operator was finally introduced. The introduction of list comprehension made a ternary operator that more usefull but every time it came up the supporters of Guido, told us we just had to define a function if we wanted the items to depend on a condition. And we knew about the problem, that is why we discussed bug-free alternatives like: condition and [true-expr] or [false-expr][0] or condition and (lambda: true-expr) or (lambda: false-expr)() The and-or hack, which was *very* common in Python code for many years and many versions, follows the same pattern as ternary if: true-clause if condition else false-clause No it doesn't. the and-or-hack follows the same pattern as the if statement. condition, true clause, else clause It astounds me how the Python community changed it's collective mind from admiration of the elegance and simplicity of the expression when it was a buggy hack, to despising it when it became a bug-free language feature. It seems that what changed is your memory and not the collective mind of the python community. We had an if statement and a (buggy) hack that followed the same pattern. An earlier discussion and poll had revealed that people n general preferredr to keep that pattern in a conditional expression. So why should you be surprised when people express that they would have preferred a conditional expression with a different pattern than we have now. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sat, 18 Sep 2010 19:09:33 -0700 (PDT) Carl Banks pavlovevide...@gmail.com wrote: On Sep 17, 1:01 pm, Andreas Waldenburger use...@geekmail.invalid wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. I don't know if it'll ever look good, per se, but it looks better when it's used in rule-exception sort of case: something = rule if condition else exception Spot on. I (more or less) like it when used that way, too. But it seems to invite crackers like the example above, and that irks me. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
[OT] Speed-reading [was Re: Too much code - slicing]
On Sun, 19 Sep 2010 10:29:10 -0400, AK wrote: On 09/18/2010 11:28 PM, Steven D'Aprano wrote: [...] My wife can read scarily fast. It's very something to watch her reading pages as fast as she can turn them, and a few years ago she read the entire Harry Potter series (to date) in one afternoon, and could gives a blow-by-blow account of the plots, including a detailed critique of the writing style and characters. But then, she feels that reading the Potter series is a chore to be completed as fast as possible, rather than a pleasure to be savored. She'll sometimes drag a new Terry Pratchett or Stephen King novel out for as much as two days. That's pretty impressive. I used to get somewhat close to that speed when, years ago, I'd read a lot of trashy scifi. [...] In other spots, I'd be able to scan a few words at the top of page, a few in the middle and at the bottom and I'd know what's going on, generally. I don't know about how other people speed-read, but I can assure you that when my wife speed-reads, she's not just scanning a few words and interpolating between them. She can give you a detailed summary of what *actually* happened, not just a good guess. Including pointing out any spelling or grammatical errors and clumsy writing. *Especially* the spelling errors, they have about the same effect on her reading speed as a tree trunk lying across a Formula 1 race track. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[OT] Syntax highlighting [was Re: Too much code - slicing]
On Sun, 19 Sep 2010 07:36:11 +, Seebs wrote:
On 2010-09-19, Steven D'Aprano st...@remove-this-cybersource.com.au
wrote:
I'm not entirely sure I agree with you here... you can't ignore syntax
in order to understand the meaning of code.
No, but the syntax should be invisible. When I read English, I don't
have to think about nouns and verbs and such unless something is very
badly written.
That's almost certainly because you've been listening to, speaking,
reading and writing English since you were a small child, and the syntax
and grammar of English is buried deep in your brain.
And you certainly do think about nouns and verbs, you just don't
*consciously* think about them. If I write:
Susan blooged the mobblet.
you will probably recognise bloog as the verb and mobblet as the
noun, even though you've almost certainly never seen those words before
and have no idea what they mean. But if I write this:
Susan is mobblet the blooged.
you'll probably give a double-take. The words don't look right for
English grammar and syntax.
I've been reading, writing and thinking in Python for well over a decade.
The syntax and grammar is almost entirely invisible to me too. No
surprise there -- they are relatively close to that of the human
languages I'm used to (English). But if I were a native Chinese or Arabic
speaker, I'd probably find Python much less natural and *would* need to
explicitly think about the syntax more.
[...]
The term syntax highlighting for what editors I've seen do is
actually misleading -- they don't highlight *syntax*, they try to
highlight *semantics*.
I've never seen this. I've seen things highlight comments and keywords
and operators and constants and identifiers differently.
Exactly. Things are highlighted because of *what* they are, not because
of the syntax they use or because of the grammatical role they play.
In a Python expression like:
y = none or None
an editor might colour None green because it's a known keyword, but
none black because it's a variable. If you change the syntax:
y = None if [none][0] is None else {None: none}[None]
the colours remain the same. None is coloured green not because of
*where* it is in the syntax tree, but because of *what* it is. Calling
this syntax highlighting is misleading, or at least incomplete.
When your editor highlights the function len() in the expression x =
len(y) + spam(z) but not the function spam(), you know it has nothing
to do with syntax. len() is singled out because of its semantics,
namely the fact that it's a built-in.
Eww. (I had not yet gotten to the point of finding out that whether
something was built-in or not substantially affected its semantics.)
In some languages, built-in functions truly are special, e.g. they are
reserved words. That's not the case for Python. Nevertheless, the editors
I've used treat built-ins as pseudo-reserved words and colourise them.
In English, the meaning of the some sentences do benefit by syntax
highlighting, and in fact that's partly what punctuation is for:
English partly uses punctuation marks as tags to break the sentence
structure into sub-sentences, clauses and terms (particularly when the
sentence would otherwise be ambiguous).
Punctuation is very different from highlighting, IMHO. That said, I
find punctuation very effective at being small and discrete, clearly not
words, and easy to pick out. Color cues are not nearly as good at being
inobtrusive but automatically parsed.
Well that surely depends on the colour scheme you have. My editor is
fairly restrained -- it uses a handful of colours (although of course you
can customize it and go nuts), and I've made it even more subtle.
To my eyes, the feature of syntax highlighting that alone makes it
worthwhile, its killer feature, is that I can set comments and docstrings
to grey. When I'm scanning code, being able to slide my eyes over greyed-
out comments and docstrings and ignore them with essentially zero effort
is a huge help. That's the thing I most miss, more than anything else,
when using a dumb editor.
Woman shoots man with crossbow
Was it the man armed with a crossbow, or the woman? If we could somehow
group the clause with crossbow with woman or man by something
*other* than proximity, we could remove the ambiguity.
Yes. But syntax highlighting won't help you here -- at least, I've
never yet seen any editor that showed precedence relations or anything
similar in its coloring.
Just because nobody has done it yet doesn't mean that some sufficiently
intelligent software in the future couldn't do it :)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Speed-reading [was Re: Too much code - slicing]
On 2010-09-20, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: I don't know about how other people speed-read, but I can assure you that when my wife speed-reads, she's not just scanning a few words and interpolating between them. She can give you a detailed summary of what *actually* happened, not just a good guess. Including pointing out any spelling or grammatical errors and clumsy writing. *Especially* the spelling errors, they have about the same effect on her reading speed as a tree trunk lying across a Formula 1 race track. Yeah. I think it's because the entire trick is to have a nice smooth pipeline, and the error-checking mechanism has to be pretty alert for that to work -- you have to know if something went wrong. And a spelling error in the text is initially indistinguishable from a reading error in the eye... -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: [OT] Syntax highlighting [was Re: Too much code - slicing]
On 2010-09-20, Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
On Sun, 19 Sep 2010 07:36:11 +, Seebs wrote:
No, but the syntax should be invisible. When I read English, I don't
have to think about nouns and verbs and such unless something is very
badly written.
That's almost certainly because you've been listening to, speaking,
reading and writing English since you were a small child, and the syntax
and grammar of English is buried deep in your brain.
Yes. But I've been programming long enough that I seem to get similar
results in most languages pretty quickly.
And you certainly do think about nouns and verbs, you just don't
*consciously* think about them.
Well, yes. But it's conscious think time that's the limiting resource
for the most part -- so if I can avoid things that require conscious
thought, that frees up more for thinking about the problem.
you will probably recognise bloog as the verb and mobblet as the
noun, even though you've almost certainly never seen those words before
and have no idea what they mean. But if I write this:
Susan is mobblet the blooged.
you'll probably give a double-take. The words don't look right for
English grammar and syntax.
Well, actually, at that point I just assume you missed the capital
m on what is apparently a proper noun. :)
I've been reading, writing and thinking in Python for well over a decade.
The syntax and grammar is almost entirely invisible to me too. No
surprise there -- they are relatively close to that of the human
languages I'm used to (English). But if I were a native Chinese or Arabic
speaker, I'd probably find Python much less natural and *would* need to
explicitly think about the syntax more.
That's a fascinating question. I don't think that would be the case, though.
Or at least. If you've used more than a couple of programming languages that
much, I wouldn't expect it to be the case. I'm not a native speaker of
Chinese, but after a year in China, I stopped perceiving grammar and just
heard sentences. (Sadly, I've mostly since lost the vocabulary, leaving
me with the annoyance of a language I can think in grammatically but can't
express much of anything in.)
I've never seen this. I've seen things highlight comments and keywords
and operators and constants and identifiers differently.
Exactly. Things are highlighted because of *what* they are, not because
of the syntax they use or because of the grammatical role they play.
Hmm, interesting point. e.g., a function name is likely to be highlighted
the same whether I'm calling it or referring to it as an object. (I'm
very new to Python, so I'm not 100% sure functions are a kind of an object,
but I seem to recall they were.)
I guess that's a point; syntax coloring is perhaps not the right word
either for what they do.
In a Python expression like:
y = none or None
an editor might colour None green because it's a known keyword, but
none black because it's a variable. If you change the syntax:
y = None if [none][0] is None else {None: none}[None]
the colours remain the same. None is coloured green not because of
*where* it is in the syntax tree, but because of *what* it is. Calling
this syntax highlighting is misleading, or at least incomplete.
This strikes me as correct. But it's not exactly semantics, either.
It's... I dunno what to call it.
Eww. (I had not yet gotten to the point of finding out that whether
something was built-in or not substantially affected its semantics.)
In some languages, built-in functions truly are special, e.g. they are
reserved words. That's not the case for Python. Nevertheless, the editors
I've used treat built-ins as pseudo-reserved words and colourise them.
Interesting. I wonder why. I guess just because if you meant to name
a variable with one of those words, maybe you'd want the reminder.
Punctuation is very different from highlighting, IMHO. That said, I
find punctuation very effective at being small and discrete, clearly not
words, and easy to pick out. Color cues are not nearly as good at being
inobtrusive but automatically parsed.
Well that surely depends on the colour scheme you have.
Only partially. The big thing, I think, is that punctuation is separate
things next to words, not attributes of words. Come to think of it,
that may be why I sometimes like to see keywords and other times punctuation.
I like {} better than do/end, for the same reason I prefer parentheticals
in English to something like:
And this is a digression contrived end digression example.
I much prefer:
And this is a (contrived) example.
To my eyes, the feature of syntax highlighting that alone makes it
worthwhile, its killer feature, is that I can set comments and docstrings
to grey. When I'm scanning code, being able to slide my eyes over greyed-
out comments and docstrings and ignore them with essentially zero effort
is a huge help. That's the
Re: Too much code - slicing
Seebs usenet-nos...@seebs.net writes: On 2010-09-20, John Bokma j...@castleamber.com wrote: I didn't mean that there are spoilers in the first 70 pages, just that to me the excercise would spoil the book, so, I wouldn't do it. I consider a book like a meal, I wouldn't gobble down food, regurgitate it, and eat it again at a slower pace. Books, movies, family, walks are the things I prefer to do at a normal mudane pace, or even slower, if I can bring myself to it. My favourite books I try to read slow, and enjoy. ;-). Too much of my life is already in overdrive. Now that you explain it like this, that makes a fair bit of sense. I often wonder whether reading slowly would be more pleasant. I have no idea how to do it, so the question remains theoretical. By practicing ;-). I have it worse with movies, but in my case, for several reasons, it's really important (to me) that I watch the movie at it's normal pace and try to enjoy it at that speed. Talking about reading: if you have any suggestions, feel free to email me (since this is already way off topic). I read mostly in my second language, English, and live in a country where English books are hard to find, so browsing in bookshops is not much of an option :-(. And most of my (online) friends don't read much, if at all. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sun, Sep 19, 2010 at 11:30:32PM +, Seebs wrote: On 2010-09-19, MRAB pyt...@mrabarnett.plus.com wrote: On 19/09/2010 22:32, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes ifcondition true-clause elsefalse-clause, then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes if condition true-clause else false-clause, and sometimes true-clause if condition else false-clause, that's a source of extra complexity. [snip] Have you read PEP 308? There was a lot of discussion about it. Interesting, in the historical section we see: The original version of this PEP proposed the following syntax: expression1 if condition else expression2 The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when expression1 is long, it's easy to miss the conditional while skimming. But apparently those objections were either unknown or disregarded when the syntax was later adopted. Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 10:32 PM, John Bokma wrote: the spoiler. Do you fast forward movies as well? I sometimes watch movies (or parts thereof) on 1.5x, especially if it has a lot of 'filler' scenes. But only when my wife is not watching, as she hates it. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. If true, that is an *awesome* etymology for a hunk of a programming 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: Too much code - slicing
On Mon, Sep 20, 2010 at 11:28 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. If that was indeed the intention, then it worked, at least in my case. Hmm, perhaps we should also add goto to the language, but we'll call it something cumbersome like slitherto and give it the side effect of reformatting the hard drive. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 20/09/2010 18:28, Antoon Pardon wrote: On Sun, Sep 19, 2010 at 11:30:32PM +, Seebs wrote: On 2010-09-19, MRABpyt...@mrabarnett.plus.com wrote: On 19/09/2010 22:32, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes ifcondition true-clause elsefalse-clause, then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes if condition true-clause else false-clause, and sometimes true-clause if condition else false-clause, that's a source of extra complexity. [snip] Have you read PEP 308? There was a lot of discussion about it. Interesting, in the historical section we see: The original version of this PEP proposed the following syntax: expression1 ifcondition elseexpression2 The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when expression1 is long, it's easy to miss the conditional while skimming. But apparently those objections were either unknown or disregarded when the syntax was later adopted. Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. I very much like the format of the Python ternary operator, but I've never actually used it myself :) Cheers Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. If he did, then he must have changed his mind, because there is nothing ugly about the ternary operator we ended up with. Guido has alwasys been against a ternary operator but the requests kept coming. So eventually he introduced one. But the impression is that he chose an ugly format in the hope of discouraging people to use it. That's sheer and unadulterated nonsense. The fact is that Guido changed his mind about ternary if after discovering that the work-around true-clause and condition or false-clause is buggy -- it gives the wrong answer if true-clause happens to be a false value like [], 0 or None. If I recall correctly, the bug bit Guido himself. The and-or hack, which was *very* common in Python code for many years and many versions, follows the same pattern as ternary if: true-clause if condition else false-clause It astounds me how the Python community changed it's collective mind from admiration of the elegance and simplicity of the expression when it was a buggy hack, to despising it when it became a bug-free language feature. Go figure. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK wrote: One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, If there was that much doubt, I would give up long before reaching the 70 page mark, regardless of reading speed. If I'm not hooked by the first page, things are unlikely to get better later. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-21, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote: Not necessarily. Some of us have the impression that Guido deliberatly chose an ugly format for the ternary operator. If he did, then he must have changed his mind, because there is nothing ugly about the ternary operator we ended up with. Empirically, looking at the commentary on the PEP, there is something about it which a large number of participants found awkward or dislikeable. I'm not sure I'd say ugly, but I would say that the net result is that it is likely more error-prone than an arrangement which put the conditions and clauses in the order they're in for other conditionals. It astounds me how the Python community changed it's collective mind from admiration of the elegance and simplicity of the expression when it was a buggy hack, to despising it when it became a bug-free language feature. Go figure. Well, if I had to point at an explanation, I'd guess it's the inversion. That, and things of the general form x or y are found in several other scripting languages, so it's a more familiar idiom. But I suspect some of it is just that, well, a number of people as of the original PEP discussion on the conditional operator disliked the new proposal of x if y else z, and if they still dislike it, they'll find the conditional operator unpleasant even if it's bug-free. This may come as a total shock, but in modern scripting languages, people are often substantially concerned with style, not just with whether or not something works. :) I would probably tend to avoid the Python conditional as it currently exists because I know that a fair number of people will find it mildly confusing. Not that they won't be able to parse it, but... It's like phrasing tests negatively. It adds one chunk to the cognitive load of reading something. It increases the likelihood of the user making mistakes -- and no amount of polish and debugging of the engine can prevent users from making mistakes. The implementation in the language engine may be bug-free, but I'd be less optimistic about code which used the construct. -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: Too much code - slicing
Terry Reedy tjre...@udel.edu writes: On 09/19/2010 10:32 PM, John Bokma wrote: the spoiler. Do you fast forward movies as well? I sometimes watch movies (or parts thereof) on 1.5x, especially if it has a lot of 'filler' scenes. But only when my wife is not watching, as she hates it. Heh, my question was somewhat rhetorical. I watch movies to slow myself down, so 1.5x is not an option. Same reason I read books slow (well, at a normal pace). If I don't I end up not being able to sleep and things go downhill from there. Also, I notice that if I want to run everything on 1.5x (or more) that I become quite annoying to the rest of my family and I want to enjoy them now, when I can. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/10 17:31, Seebs wrote: Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. Seems like you've got a much more complicated parser than I do. You can read code from top-down, bottom-left; doing that would require keeping a mental stack of the contexts of code all the time; that's something I can't do. What I normally do when reading code is to first scan the overall structure first, then zoom in to the interesting parts until I get to an atomic structure (something I can understand in a quick glance). I'd then agglutinate some of the atoms into bigger chunks that I don't read in detail anymore. Reading code left-right is too difficult for me since then, you'd have to keep a stack that tracks how many logical parentheses (i.e. how deep in the code structure) you've seen and their types. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Define unbalanced. I'm not sure that's the word I'd use. I'm not even sure what it would mean here. Putting aside the over-use of punctuation, The C syntax feels unbalanced to me. You have: condition IF true-clause ELSE false-clause so both clauses follow the test, that is, they're on the same side: ?-- Yes. Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. So I like that form because it matches what I'd write if I were writing things out more verbosely for some reason. But the Python syntax looks balanced to me: true-clause IF condition ELSE false-clause which is not only plain English, but perfectly balanced, with a clause on either side of the test: -?- It may be balanced, but it requires you to reevaluate what you're reading after you've already read something that seemed to have a clear meaning. Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. It's even more confusing if I'm familiar with the postfix-if as seen in, say, perl or ruby. Python's ternary-if puts the emphasis on the true-clause, while C's ternary-if puts the emphasis on the test. I'm not convinced that this is necessarily a better choice than Python's. It's a *valid* choice, but better? I don't think so, but I accept that at least partially boils down to subjective factors. I would usually think it better, just because most often, the *fact* of there being a test is the first thing you have to know about the expression to make sense of it. If I am given the right framework first, and the information to fill into it second, I don't have to throw away parsing I'd already done. If I'm given information, then later retroactively told to move it into a slot in a framework I didn't even know I was going to need, I have to do a lot of reworking. Consider the following lovely hypothetical syntax: foo bar baz if condition else: blah blah blah And there, at least you have some cue that you're about to see something happen. -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: Too much code - slicing
On 2010-09-19, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: I'm not entirely sure I agree with you here... you can't ignore syntax in order to understand the meaning of code. No, but the syntax should be invisible. When I read English, I don't have to think about nouns and verbs and such unless something is very badly written. The syntax is handled automatically at a lower level without conscious intervention, as it should be. Calling my conscious attention to it is disruptive. The term syntax highlighting for what editors I've seen do is actually misleading -- they don't highlight *syntax*, they try to highlight *semantics*. I've never seen this. I've seen things highlight comments and keywords and operators and constants and identifiers differently. When your editor highlights the function len() in the expression x = len(y) + spam(z) but not the function spam(), you know it has nothing to do with syntax. len() is singled out because of its semantics, namely the fact that it's a built-in. Eww. (I had not yet gotten to the point of finding out that whether something was built-in or not substantially affected its semantics.) In English, the meaning of the some sentences do benefit by syntax highlighting, and in fact that's partly what punctuation is for: English partly uses punctuation marks as tags to break the sentence structure into sub-sentences, clauses and terms (particularly when the sentence would otherwise be ambiguous). Punctuation is very different from highlighting, IMHO. That said, I find punctuation very effective at being small and discrete, clearly not words, and easy to pick out. Color cues are not nearly as good at being inobtrusive but automatically parsed. Woman shoots man with crossbow Was it the man armed with a crossbow, or the woman? If we could somehow group the clause with crossbow with woman or man by something *other* than proximity, we could remove the ambiguity. Yes. But syntax highlighting won't help you here -- at least, I've never yet seen any editor that showed precedence relations or anything similar in its coloring. Bringing it back to Python, that's why punctuation like : are useful. They're syntax highlighting. I don't think they are, though. I think punctuation is fundamentally different in intent and purpose from colorizing things based on whether they're, say, constants or identifiers or comments or keywords. The punctuation is *itself* part of the syntax -- it's not being highlighted. Syntax highlighting is putting all the punctuation in green so you know it's punctuation. -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: Too much code - slicing
On 09/18/2010 11:28 PM, Steven D'Aprano wrote: On Sat, 18 Sep 2010 21:58:58 -0400, AK wrote: I don't understand this. So far as I know, the phrase speed reading refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. Woody Allen joke: I learned speed reading and read WarPeace; - it involves Russia. My wife can read scarily fast. It's very something to watch her reading pages as fast as she can turn them, and a few years ago she read the entire Harry Potter series (to date) in one afternoon, and could gives a blow-by-blow account of the plots, including a detailed critique of the writing style and characters. But then, she feels that reading the Potter series is a chore to be completed as fast as possible, rather than a pleasure to be savored. She'll sometimes drag a new Terry Pratchett or Stephen King novel out for as much as two days. That's pretty impressive. I used to get somewhat close to that speed when, years ago, I'd read a lot of trashy scifi. The way it would work is that I'd sense in advance that there's a passage where the hero with his team is going through a desert area and I'd know that a 30-40 page section will be punctuated by two battles and one friendly encounter. I would be able to read at different speeds depending on what's going on, slowing down a bit where a twist is presented or a crucial plot point is revealed, both would be telegraphed well in advance. In other spots, I'd be able to scan a few words at the top of page, a few in the middle and at the bottom and I'd know what's going on, generally. I would also be able to give a detailed account of the plot and writing style and characters but this would be entirely due to predictability of writing and following tropes. Interestingly, I've also read LoTR in the same way when I was younger because I was interested in battles and skipped the dull parts. I tried a few times to read Potter book 3 but couldn't bear it.. spoiled too much by Barrie and Grahame. When I was reading The book of the new sun, though, I could stop and read a single sentence a few times over and reflect on it for a minute. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 03:31 AM, Seebs wrote: On 2010-09-19, Steven D'Apranost...@remove-this-cybersource.com.au wrote: Define unbalanced. I'm not sure that's the word I'd use. I'm not even sure what it would mean here. Putting aside the over-use of punctuation, The C syntax feels unbalanced to me. You have: condition IF true-clause ELSE false-clause so both clauses follow the test, that is, they're on the same side: ?-- Yes. Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. To me, the problem with C ternary is, why is true condition first and false second? It could just as well be the other way around. With if and else, the meaning is direct, x if y else z, or if y: x; else: z. It may be balanced, but it requires you to reevaluate what you're reading after you've already read something that seemed to have a clear meaning. Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. That's absolutely not how I read code. For example, if you have a line like: x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# Do you read it as ok, assignment.. x is x + 1.. whoa, what the hell is this?. I would read it like there's something wrong at the end of line, before I even see it as an assignment. That's where syntax highlighting comes in, as well. What I see, at the same time (i.e. not in sequence): .. = .. if .. else .. The second thing I see is what variable is being assigned to. Of couse, this might change if I'm looking for that particular variable, then I might see: x or x = Consider the following lovely hypothetical syntax: foo bar baz if condition else: blah blah blah And there, at least you have some cue that you're about to see something happen. After some time getting used to it, I'd end up seeing this as: . . . if .. else: . . . at first and then processing everything else. Again, syntax highlighting would help here. The only issue is that it'd be hard to separate the beginning from other code, for me that'd be the primary reason why this is not a good construct. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 03:36 AM, Seebs wrote: On 2010-09-19, Steven D'Apranost...@remove-this-cybersource.com.au wrote: I'm not entirely sure I agree with you here... you can't ignore syntax in order to understand the meaning of code. No, but the syntax should be invisible. When I read English, I don't have to think about nouns and verbs and such unless something is very badly written. The syntax is handled automatically at a lower level without conscious intervention, as it should be. Calling my conscious attention to it is disruptive. The interesting thing is that syntax highlight for me *is* handled at a lower level. What you're describing is exactly the same as when I try a highlight scheme with colours that are too strong, or have a background. I would rather use no highlighting at all than a theme with garish colours. When I read code, I filter out colours when I don't need them and filter out non-coloured text when I'm looking for a particular structure. So, with x = y if a else z, I might see . = . if . else . and then immediately see x . y . a . z, already with knowledge of what is the structure surrounding vars. Punctuation is very different from highlighting, IMHO. That said, I find punctuation very effective at being small and discrete, clearly not words, and easy to pick out. Color cues are not nearly as good at being inobtrusive but automatically parsed. Seems like the difference of how you process colours vs. how I do, for me they work precisely in the same way as punctuation might, but adding an additional layer which may be used but never gets in the way. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK andrei@gmail.com wrote: On 09/19/2010 03:31 AM, Seebs wrote: Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. To me, the problem with C ternary is, why is true condition first and false second? It could just as well be the other way around. Again, look at the long-form if/else above; it's always if a then b otherwise c. With if and else, the meaning is direct, x if y else z, or if y: x; else: z. The latter still has condition, true, false. Basically, think of what happens as I read each symbol: x = x + 1 if condition else x - 1 Up through the '1', I have a perfectly ordinary assignment of a value. The, suddenly, it retroactively turns out that I have misunderstood everything I've been reading. I am actually reading a conditional, and the things I've been seeing which looked like they were definitely part of the flow of evaluation may in fact be completely skipped. That's absolutely not how I read code. For example, if you have a line like: x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# Do you read it as ok, assignment.. x is x + 1.. whoa, what the hell is this?. Not for something that big and visible. But the if/else stuff is just ordinary blocks of text. That's where syntax highlighting comes in, as well. So basically, if we use syntax highlighting to make up for the legibility problems of a given syntax, then the syntax is okay, but people who don't use syntax highlighting to make up for its legibility problems are wrong. I see. This does seem self-contained; you like syntax highlighting because you like constructs which are hard to read without it. You like those constructs because they let you show off syntax highlighting. After some time getting used to it, I'd end up seeing this as: . . . if .. else: . . . at first and then processing everything else. Assuming that the if/else was on the same page. :) Again, syntax highlighting would help here. The only issue is that it'd be hard to separate the beginning from other code, for me that'd be the primary reason why this is not a good construct. No matter how long I'd been using that construct, I'd still have the problem that, mechanically, I'm going to see the opening few lines first, and that means that those lines are going to get parsed first. I read largely in order. I do have some lookahead, but no matter how much I use the lookahead, I'm already parsing the first things I see, and that's top-down-left-right. -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: Too much code - slicing
On 09/19/2010 02:21 PM, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: On 09/19/2010 03:31 AM, Seebs wrote: Just like: if condition: foo else: bar The condition is the primary, the clauses are secondary to it. To me, the problem with C ternary is, why is true condition first and false second? It could just as well be the other way around. Again, look at the long-form if/else above; it's always if a then b otherwise c. Because that's what 'if' and 'else' mean. I have no problem with '?' separating condition from possible outcomes.. The most natural reading of that construct is that depending on condition, there are two possible outcomes, separated by a ':' and you have to remember that first outcome corresponds to true condition. x = y if a else z is much more pythonic because 'else' is explicitly saying what happens on false condition. Explicit is better than implicit. That's absolutely not how I read code. For example, if you have a line like: x = x + 1 a...@#$!@$asfa...@#$!@$#adfas...@# Do you read it as ok, assignment.. x is x + 1.. whoa, what the hell is this?. Not for something that big and visible. But the if/else stuff is just ordinary blocks of text. Not with syntax highlighting they're not ;) Seriously though, my guess is even without syntax highlighting I'd still prefer it because I do enough look-ahead and in 95% of cases the first 'if' is close enough to the beginning of the line. In fact, most often plain assignments will be much shorter than this construct so you can figure it out by combination of line length and the 'if' keyword. It still has the advantage over the more verbose version that I mentioned before: you can see immediately that there's an assignment to a single variable, and the logic flows like a single sentence in a natural language. That's where syntax highlighting comes in, as well. So basically, if we use syntax highlighting to make up for the legibility problems of a given syntax, then the syntax is okay, but people who don't use syntax highlighting to make up for its legibility problems are wrong. That's not really true, it merely makes a given syntax easier to read even when it's already a preferable syntax. It's like this, if someone gives you five dollars for nothing, and then later gives you three dollars, you don't complain that the latter amount is less than former :). I see. This does seem self-contained; you like syntax highlighting because you like constructs which are hard to read without it. You like those constructs because they let you show off syntax highlighting. Well, you're exaggerating this out of all proportion just to prove a point. I like syntax highlighting in all of python and, in fact, in all languages I've used. Even in crontab files! This is a single construct I can think of, which, being already very readable, explicit, and succinct, *on top of that*, gains even more in readability due to syntax highlight. So, as you can see, I'd like syntax highlight just fine if this construct was not present in Python, and in fact I did. Conversely, I'd prefer it to the longer version if there was no syntax highlight at all. After some time getting used to it, I'd end up seeing this as: . . . if .. else: . . . at first and then processing everything else. Assuming that the if/else was on the same page. :) I'll concede you one point in this case: if the statement 'x = .. if .. else .. ' is split over two pages, I would at least seriously consider the 'if: .. else: ' version. ;) -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK andrei@gmail.com wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes if condition true-clause else false-clause, then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes if condition true-clause else false-clause, and sometimes true-clause if condition else false-clause, that's a source of extra complexity. I have no problem with '?' separating condition from possible outcomes.. The most natural reading of that construct is that depending on condition, there are two possible outcomes, separated by a ':' and you have to remember that first outcome corresponds to true condition. Exactly as it ALWAYS does. That's the point. x = y if a else z is much more pythonic because 'else' is explicitly saying what happens on false condition. Explicit is better than implicit. Is it more pythonic to shuffle the orders of clauses in precisely analagous constructs? I'm not arguing against the use of the *words* if and else. I'm arguing that the shuffling of the orders of the clauses creates confusion. It still has the advantage over the more verbose version that I mentioned before: you can see immediately that there's an assignment to a single variable, and the logic flows like a single sentence in a natural language. I'm getting frustrated here because I really felt my point was pretty clearly expressed, and yet, every time you respond, you respond to things TOTALLY DIFFERENT from what I am saying. The syntax I like for this kind of thing is: x = if condition then true-clause else false-clause This is because it follows the same *ordering* as the multi-line if/else, so it preserves the logical flow. Condition, then true clause, then false clause. Always. The only way in which this is more verbose than the inverted one is the then, and you don't even need that if you stick with a python-style colon: x = if condition: true-clause else false-clause But this is *always* easier to follow because it follows the same logical structure. Leave poetic inversion to the poets. That's not really true, it merely makes a given syntax easier to read even when it's already a preferable syntax. Except that it's *NOT PREFERABLE* to me, because it is BACKWARDS. Have I somehow failed to express this? Is there some magical rule that it is not pythonic for you to react in any way to the actual comparison I'm making, rather than to totally unrelated comparisons? I gave the example of what an if/else statement looks like, not because I think it is always better to use statements and blocks instead of expressions, but to point out the LOGICAL ORDER. You were asking why I preferred the condition to come first. My answer is, because the condition comes first in an if/else statement normally, and I like to preserve the logical flow. Instead, you're off ranting about how that's too long. But that's not my point. My point was *only* that the logical flow is consistent between if/else and the way various languages have done if/else expressions: Condition first, then true clause, then false clause. Doesn't matter whether it's ruby or C or lua or even bourne shell, in every other language I use that lets me use an if/else as part of an expression, it follows the SAME logical flow as the regular if/else statement. In Python, it's inverted. You were arguing that this inversion is better and more intuitive, and that there is no reason to expect the condition to come first. But there is! The condition comes first in regular if/else statements. This establishes a pattern -- if/else things are introduced by their condition, then you get the true clause and then you get the false clause. Well, you're exaggerating this out of all proportion just to prove a point. No, I'm not. This is a single construct I can think of, which, being already very readable, explicit, and succinct, *on top of that*, gains even more in readability due to syntax highlight. But it's *not readable to me*. Because it's backwards. So, as you can see, I'd like syntax highlight just fine if this construct was not present in Python, and in fact I did. Conversely, I'd prefer it to the longer version if there was no syntax highlight at all. And again, NO ONE HAS SUGGESTED THE LONGER VERSION. AT ALL. EVER. I don't understand why you keep contrasting this with the longer version when the only reason that was brought up was to COMPARE it in terms of *logical flow*. I pointed out the *PARALLELS* between conditional expressions and conditional statements. I did not suggest that the longer version should be preferred in all cases, or even in all that many. I'll concede you one point in this case: if the statement 'x = .. if .. else .. ' is split over two pages, I would at least seriously consider the 'if: .. else: ' version. ;) Okay, one more
Re: Too much code - slicing
On 19/09/2010 22:32, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes ifcondition true-clause elsefalse-clause, then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes if condition true-clause else false-clause, and sometimes true-clause if condition else false-clause, that's a source of extra complexity. [snip] Have you read PEP 308? There was a lot of discussion about it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, MRAB pyt...@mrabarnett.plus.com wrote: On 19/09/2010 22:32, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: Because that's what 'if' and 'else' mean. My point is, I don't want the order of the clauses in if/else to change. If it is sometimes ifcondition true-clause elsefalse-clause, then it should *ALWAYS WITHOUT EXCEPTION* be condition first, then true clause, then false clause. If it's sometimes if condition true-clause else false-clause, and sometimes true-clause if condition else false-clause, that's a source of extra complexity. [snip] Have you read PEP 308? There was a lot of discussion about it. Interesting, in the historical section we see: The original version of this PEP proposed the following syntax: expression1 if condition else expression2 The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when expression1 is long, it's easy to miss the conditional while skimming. But apparently those objections were either unknown or disregarded when the syntax was later adopted. -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: Too much code - slicing
On 2010-09-19, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. I get pleasure from the story, not from the time spent. Reading faster means I get more stories. Same thing, to some extent, with programming. I could easily spend much more time writing some programs by switching to a language ill-suited to them (say, using C for heavy string manipulation, or PHP for anything), but that wouldn't mean I had more fun, it would mean my fun was spread out over a longer period of time, and might well cross over to no-longer-fun. -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: Too much code - slicing
AK andrei@gmail.com wrote: When I was reading The book of the new sun, though, I could stop and read a single sentence a few times over and reflect on it for a minute. Totally understandable, Wolfe is a far, far greater writer than Rowling :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Unfortunately, beginning of a novel is where I have to read at the slowest rate because I'm not used to author's style and pacing yet and I don't want to miss something crucial. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, alex23 wuwe...@gmail.com wrote: AK andrei@gmail.com wrote: When I was reading The book of the new sun, though, I could stop and read a single sentence a few times over and reflect on it for a minute. Totally understandable, Wolfe is a far, far greater writer than Rowling :) Certainly true. On the other hand, I found it frustrating when I *had* to re-read a passage a couple of times to figure out what had just happened. :) ... Not that rereading books is necessarily a bad 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: Too much code - slicing
AK andrei@gmail.com writes: On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. Do you fast forward movies as well? I do speed read but not the books I read for pleasure. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, John Bokma j...@castleamber.com wrote: Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. I rarely encounter substantive spoilers in the first 70 pages or so of a book. That said, I'm pretty much immune to spoilers; while I'm reading, I'm usually ignoring anything I might have previously known about a story, so it all works even if I've read it before. Do you fast forward movies as well? Amusingly, I can't generally watch movies at normal speed. They're too boring. Luckily, computers are finally advancing to a point where 1.2x faster, but no chipmunks is an available setting in some software. -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: Too much code - slicing
On Mon, 20 Sep 2010 11:18:57 +1200, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. Or reduce the pain by 90%, depending on the book... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/19/2010 10:32 PM, John Bokma wrote: AKandrei@gmail.com writes: On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. Do you fast forward movies as well? I honestly doubt it would be a spoiler if it's a good book. Generally I find that poor books rely on twists and turns while better ones rely on the fabric of story-telling. Aside from that, though, it's a very interesting question - I'll try to think of good books and see if they'd be spoiled by peeking in the first 70 pages.. Starting with children's books, Peter Pan and Wind in the Willows, I think, would not be. Don quixote would not be. Crime and punishment - maybe if you get as far as the murder? Same author's the Devils, I would say you can read the last 70 pages and it'd be just as good :). -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
AK andrei@gmail.com writes: On 09/19/2010 10:32 PM, John Bokma wrote: AKandrei@gmail.com writes: On 09/19/2010 07:18 PM, Gregory Ewing wrote: AK wrote: Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. I've never understood why anyone would *want* to read a novel that fast, though. For me at least, reading a novel is something done for pleasure, so reading it at ten times normal speed would waste 90% of the benefit. One definite advantage would be that if, say, it takes you 70 pages of a given novel to figure out whether you like it enough to continue, you'd want to read those pages in 2 minutes rather than an hour. Heh, to me speed reading those 70 pages in a very short while, concluding that it's a good book, and start over again would be quite the spoiler. Do you fast forward movies as well? I honestly doubt it would be a spoiler if it's a good book. Generally I find that poor books rely on twists and turns while better ones rely on the fabric of story-telling. Aside from that, though, it's a very interesting question - I'll try to think of good books and see if they'd be spoiled by peeking in the first 70 pages.. Starting with children's books, Peter Pan and Wind in the Willows, I think, would not be. Don quixote would not be. Crime and punishment - maybe if you get as far as the murder? Same author's the Devils, I would say you can read the last 70 pages and it'd be just as good :). -ak I didn't mean that there are spoilers in the first 70 pages, just that to me the excercise would spoil the book, so, I wouldn't do it. I consider a book like a meal, I wouldn't gobble down food, regurgitate it, and eat it again at a slower pace. Books, movies, family, walks are the things I prefer to do at a normal mudane pace, or even slower, if I can bring myself to it. My favourite books I try to read slow, and enjoy. ;-). Too much of my life is already in overdrive. -- John Bokma j3b Blog: http://johnbokma.com/Facebook: http://www.facebook.com/j.j.j.bokma Freelance Perl Python Development: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, John Bokma j...@castleamber.com wrote: I didn't mean that there are spoilers in the first 70 pages, just that to me the excercise would spoil the book, so, I wouldn't do it. I consider a book like a meal, I wouldn't gobble down food, regurgitate it, and eat it again at a slower pace. Books, movies, family, walks are the things I prefer to do at a normal mudane pace, or even slower, if I can bring myself to it. My favourite books I try to read slow, and enjoy. ;-). Too much of my life is already in overdrive. Now that you explain it like this, that makes a fair bit of sense. I often wonder whether reading slowly would be more pleasant. I have no idea how to do it, so the question remains theoretical. -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: Too much code - slicing
On 2010-09-18, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Fri, 17 Sep 2010 16:01:54 -0400, Andreas Waldenburger wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. It looks good to me. It follows a common English idiom: What are you doing tonight? I'll be going to the movies, if I finish work early, otherwise I'll stay home and watch a DVD. I hate that idiom in English, too. If you're going to give me a forking conditional, I want to know about it early. Basically, I can handle do x if y pretty well, but do x if y else z always breaks my parser. So in English, I might say I'll go to the store if I have time, but I'd rarely use I'll go to the store if I have time, otherwise I'll send the house elf; instead, I'd say If I have time, I'll go to the store, otherwise I'll send the house elf. -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: Too much code - slicing
On 09/18/2010 06:56 PM, Seebs wrote: On 2010-09-18, Steven D'Apranost...@remove-this-cybersource.com.au wrote: On Fri, 17 Sep 2010 16:01:54 -0400, Andreas Waldenburger wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AKandrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. It looks good to me. It follows a common English idiom: What are you doing tonight? I'll be going to the movies, if I finish work early, otherwise I'll stay home and watch a DVD. I hate that idiom in English, too. If you're going to give me a forking conditional, I want to know about it early. Basically, I can handle do x if y pretty well, but do x if y else z always breaks my parser. So in English, I might say I'll go to the store if I have time, but I'd rarely use I'll go to the store if I have time, otherwise I'll send the house elf; instead, I'd say If I have time, I'll go to the store, otherwise I'll send the house elf. -s I actually find the shorter version slightly more readable than full version. I think in English you'd say it in one sentence and that to me feels like it should vaguely correspond to one line in code (perhaps split over more than one line but that'd be due to long var names or complex operations, not inherently). The longer version may be like saying I'll go to the store. If I have time. If I don't have time. I will send the house elf. It's a bit more readable to me because I can tell at a glance that a single variable gets assigned a value based on a condition. With a longer version it looks like something more complicated it going on, and the eye has to look at all four lines and jump to another ident level. By the way, it also looks far more readable in an editor where if and else would be highlighted vs. all in plain colour. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-18, AK andrei@gmail.com wrote: On 09/18/2010 06:56 PM, Seebs wrote: Basically, I can handle do x if y pretty well, but do x if y else z always breaks my parser. So in English, I might say I'll go to the store if I have time, but I'd rarely use I'll go to the store if I have time, otherwise I'll send the house elf; instead, I'd say If I have time, I'll go to the store, otherwise I'll send the house elf. I actually find the shorter version slightly more readable than full version. I think in English you'd say it in one sentence and that to me feels like it should vaguely correspond to one line in code (perhaps split over more than one line but that'd be due to long var names or complex operations, not inherently). I dunno, it always breaks my parser. The condition ends up between the two dependents, and that doesn't work for me. I can have conditions which are leading or trailing, but not infix. It's a bit more readable to me because I can tell at a glance that a single variable gets assigned a value based on a condition. With a longer version it looks like something more complicated it going on, and the eye has to look at all four lines and jump to another ident level. Ahh! I see. There's several variants that could be discussed. if condition: x = y else: x = z x = y if condition else z And then the one I'm used to from other languages: x = if condition then y else z The other thing, from my point of view, is an ambiguity with a common idiom I'm used to, again from other languages: x = y if condition If !condition, then nothing happens to x. So far as I can tell, that's a syntax error in Python -- I can't use postfix if to modify a sentence, because it's an expression thing. By the way, it also looks far more readable in an editor where if and else would be highlighted vs. all in plain colour. I use syntax coloring in programming languages precisely as often, and for precisely the same reasons, that I use it when writing in English. Which is to say, if such a feature exists, I turn it off immediately because it consistently distracts me from following the actual meaning of code. Syntax is the least part of the meaning of code; giving extra weight to syntax is pretty disruptive, IMHO. -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: Too much code - slicing
On 09/18/2010 07:38 PM, Seebs wrote: On 2010-09-18, AKandrei@gmail.com wrote: On 09/18/2010 06:56 PM, Seebs wrote: Basically, I can handle do x if y pretty well, but do x if y else z always breaks my parser. So in English, I might say I'll go to the store if I have time, but I'd rarely use I'll go to the store if I have time, otherwise I'll send the house elf; instead, I'd say If I have time, I'll go to the store, otherwise I'll send the house elf. I actually find the shorter version slightly more readable than full version. I think in English you'd say it in one sentence and that to me feels like it should vaguely correspond to one line in code (perhaps split over more than one line but that'd be due to long var names or complex operations, not inherently). I dunno, it always breaks my parser. The condition ends up between the two dependents, and that doesn't work for me. I can have conditions which are leading or trailing, but not infix. It's a bit more readable to me because I can tell at a glance that a single variable gets assigned a value based on a condition. With a longer version it looks like something more complicated it going on, and the eye has to look at all four lines and jump to another ident level. Ahh! I see. There's several variants that could be discussed. if condition: x = y else: x = z x = y if condition else z And then the one I'm used to from other languages: x = if condition then y else z The other thing, from my point of view, is an ambiguity with a common idiom I'm used to, again from other languages: x = y if condition If !condition, then nothing happens to x. So far as I can tell, that's a syntax error in Python -- I can't use postfix if to modify a sentence, because it's an expression thing. By the way, it also looks far more readable in an editor where if and else would be highlighted vs. all in plain colour. I use syntax coloring in programming languages precisely as often, and for precisely the same reasons, that I use it when writing in English. Which is to say, if such a feature exists, I turn it off immediately because it consistently distracts me from following the actual meaning of code. Syntax is the least part of the meaning of code; giving extra weight to syntax is pretty disruptive, IMHO. Funny that you should say that, because I thought quite a few times that it would be really awesome if some texts in English had syntax highlighting. Obviously, not Brothers Karamazov, but something like a tutorial, or a manual, or an online article. If key words were highlighted, I'd be able to quickly glance over parts that are not useful to me at the time, and find the interesting bits. For instance, in the above paragraph I'd highlight 'awesome', 'English', 'syntax highlighting', 'tutorial', 'manual', 'online article', 'quickly glance over', 'not useful', 'find', 'interesting bits'. It'd be like speed reading, except real! -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK andrei@gmail.com wrote: Funny that you should say that, because I thought quite a few times that it would be really awesome if some texts in English had syntax highlighting. Obviously, not Brothers Karamazov, but something like a tutorial, or a manual, or an online article. If key words were highlighted, I'd be able to quickly glance over parts that are not useful to me at the time, and find the interesting bits. That wouldn't be *syntax* highlighting, that'd be *semantic* highlighting. Which people often do -- notice that I did it twice in that paragraph. But that's the point -- you need to know what it *means* to make sensible decisions about what to highlight. Syntax highlighting is precisely the opposite, highlighting things for reasons that have nothing to do with their semantic content. It distracts from the actual meaning of the code. In short, syntax highlighting would be like writing: FUNNY *that* _you_ *should* /say/ *that*. It'd be like speed reading, except real! I don't understand this. So far as I know, the phrase speed reading refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. -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: Too much code - slicing
On 09/18/2010 08:35 PM, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: Funny that you should say that, because I thought quite a few times that it would be really awesome if some texts in English had syntax highlighting. Obviously, not Brothers Karamazov, but something like a tutorial, or a manual, or an online article. If key words were highlighted, I'd be able to quickly glance over parts that are not useful to me at the time, and find the interesting bits. That wouldn't be *syntax* highlighting, that'd be *semantic* highlighting. In case of programming, the effect is similar. I find that it allows me to look quickly through code, scanning for something specific, e.g. the next function, the next if/else block. If I'm looking for a print statement, for example, I can quickly scan a whole screenful, looking for a first highlighted long word (all the other highlighted keywords will usually be if, else, and for). On the other hand, if I know I'm looking for a variable, my eyes will filter out all the highlighted text - strings and keywords. English is of course much less formal so you have to understand the text to do useful highlighting. Anyway, I find it very odd that anyone would not find it extremely useful (in code)! Which people often do -- notice that I did it twice in that paragraph. But that's the point -- you need to know what it *means* to make sensible decisions about what to highlight. Syntax highlighting is precisely the opposite, highlighting things for reasons that have nothing to do with their semantic content. It distracts from the actual meaning of the code. I'm not always looking for meaning *immediately*. If I know there's a single print statement in a function, I don't need to understand its meaning to know that's the one print statement I need. (Or, if there's two, I might know that I need the first one or at least I'll have 2 lines to look at instead of 75). In short, syntax highlighting would be like writing: FUNNY *that* _you_ *should* /say/ *that*. It'd be like speed reading, except real! I don't understand this. So far as I know, the phrase speed reading refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. Woody Allen joke: I learned speed reading and read WarPeace; - it involves Russia. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/18/2010 09:08 PM, Dennis Lee Bieber wrote: On Sat, 18 Sep 2010 20:00:32 -0400, AKandrei@gmail.com declaimed the following in gmane.comp.python.general: Funny that you should say that, because I thought quite a few times that it would be really awesome if some texts in English had syntax highlighting. Obviously, not Brothers Karamazov, but something like a tutorial, or a manual, or an online article. If key words were highlighted, I'd be able to quickly glance over parts that are not useful to me at the time, and find the interesting bits. For instance, in the above paragraph I'd highlight 'awesome', 'English', 'syntax highlighting', 'tutorial', 'manual', 'online article', 'quickly glance over', 'not useful', 'find', 'interesting bits'. Syntax highlighting is more likely to identify: be, if, had, but, like, or, were, are, not, and. That is, the (relatively) fixed connectors between arbitrary nouns and concepts. something besomething ifsomething hadsomething.something notsomething, butsomething likesomething, orsomething. If something weresomething are notsomething, andsomething Yes, I didn't mean that it's exactly the same, of course. Python being much more formal than English means automatic syntax highlight can be useful, as obviously many people find it; although this gave me an interesting idea: if you had a long text that you wished to read quickly, it might be more efficient to do syntax highlight of all verbs, quickly scan through the text, then syntax highlight of all nouns, do another quick scan, and then turn off syntax highlight and concentrate on the parts that you did not understand while scanning. Is there a program that'd do something like that? -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sep 17, 1:01 pm, Andreas Waldenburger use...@geekmail.invalid wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. I don't know if it'll ever look good, per se, but it looks better when it's used in rule-exception sort of case: something = rule if condition else exception Then the tacked-on feel the if condition else exception part works because it is actually tacked on. Apart from occasions like this and throwaway one-liners I use regular if-then statements. If Python had added the C-like a ? b : c, then I'd use it a lot more, since that version is not inherently unbalanced. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-19, AK andrei@gmail.com wrote: On 09/18/2010 08:35 PM, Seebs wrote: That wouldn't be *syntax* highlighting, that'd be *semantic* highlighting. In case of programming, the effect is similar. I have not found that to be the case. It's been exactly the same as syntax highlighting in English would be -- it's wasting bandwidth telling me things I already know, which slows down my perception of the things I'm trying to find out. Hmm. Actually, one thing -- I think I sometimes find it useful for a couple of days on a new language I don't know yet. It's helpful then, but once I've got my parser trained, it's a distraction. Anyway, I find it very odd that anyone would not find it extremely useful (in code)! Yes, and I find it inexplicable that people find it useful. News flash: Not all people think the same way. Film at 11. :) I've tried to use syntax coloring editors, and I've always found that they end up making me slower and less accurate at reading things, because what they're highlighting isn't waht what I need to know. I don't understand this. So far as I know, the phrase speed reading refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. Woody Allen joke: I learned speed reading and read WarPeace; - it involves Russia. I dunno about that speed, but as I recall, my default reading speed for English is about the range that people advertise in speed reading courses, and I end up understanding text about as well as other people 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
Re: Too much code - slicing
On 09/18/2010 10:12 PM, Seebs wrote: On 2010-09-19, AKandrei@gmail.com wrote: On 09/18/2010 08:35 PM, Seebs wrote: News flash: Not all people think the same way. Film at 11. :) I've tried to use syntax coloring editors, and I've always found that they end up making me slower and less accurate at reading things, because what they're highlighting isn't waht what I need to know. The way I see it, it's not meant to tell you something, it's punctuation, it's as if you'd argue against periods and spaces at the end of sentencesBecause the next sentence is capitalized anyway, so you already know the last sentence ended. In the same way, in many cases other punctuation is not absolutely necessary for understanding. The other thing is of course that it helps you not to name your variables using keywords and spot misspelled keywords. -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sat, 18 Sep 2010 19:09:33 -0700, Carl Banks wrote: Apart from occasions like this and throwaway one-liners I use regular if-then statements. If Python had added the C-like a ? b : c, then I'd use it a lot more, since that version is not inherently unbalanced. Define unbalanced. Putting aside the over-use of punctuation, The C syntax feels unbalanced to me. You have: condition IF true-clause ELSE false-clause so both clauses follow the test, that is, they're on the same side: ?-- This looks unbalanced to me. And it reads like something Yoda would say, or Forth code. But the Python syntax looks balanced to me: true-clause IF condition ELSE false-clause which is not only plain English, but perfectly balanced, with a clause on either side of the test: -?- Python's ternary-if puts the emphasis on the true-clause, while C's ternary-if puts the emphasis on the test. I'm not convinced that this is necessarily a better choice than Python's. It's a *valid* choice, but better? I don't think so, but I accept that at least partially boils down to subjective factors. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sat, 18 Sep 2010 21:58:58 -0400, AK wrote: I don't understand this. So far as I know, the phrase speed reading refers to various methods of reading much faster than most people read, and is real but not exceptionally interesting. Afaik the idea is that you can read a novel at the speed of half a page a second or so and understand it to the same extent as people who'd read at a normal rate. Woody Allen joke: I learned speed reading and read WarPeace; - it involves Russia. My wife can read scarily fast. It's very something to watch her reading pages as fast as she can turn them, and a few years ago she read the entire Harry Potter series (to date) in one afternoon, and could gives a blow-by-blow account of the plots, including a detailed critique of the writing style and characters. But then, she feels that reading the Potter series is a chore to be completed as fast as possible, rather than a pleasure to be savored. She'll sometimes drag a new Terry Pratchett or Stephen King novel out for as much as two days. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sun, 19 Sep 2010 00:35:14 +, Seebs wrote: On 2010-09-19, AK andrei@gmail.com wrote: Funny that you should say that, because I thought quite a few times that it would be really awesome if some texts in English had syntax highlighting. Obviously, not Brothers Karamazov, but something like a tutorial, or a manual, or an online article. If key words were highlighted, I'd be able to quickly glance over parts that are not useful to me at the time, and find the interesting bits. That wouldn't be *syntax* highlighting, that'd be *semantic* highlighting. Which people often do -- notice that I did it twice in that paragraph. But that's the point -- you need to know what it *means* to make sensible decisions about what to highlight. Syntax highlighting is precisely the opposite, highlighting things for reasons that have nothing to do with their semantic content. It distracts from the actual meaning of the code. I'm not entirely sure I agree with you here... you can't ignore syntax in order to understand the meaning of code. Unless you understand the syntax, even a simple line like: x = y is impossible to understand. Is it an assignment? If so, which way (does it assign the value of x to the variable y, or y to x)? Or is it a comparison? The term syntax highlighting for what editors I've seen do is actually misleading -- they don't highlight *syntax*, they try to highlight *semantics*. When your editor highlights the function len() in the expression x = len(y) + spam(z) but not the function spam(), you know it has nothing to do with syntax. len() is singled out because of its semantics, namely the fact that it's a built-in. In English, the meaning of the some sentences do benefit by syntax highlighting, and in fact that's partly what punctuation is for: English partly uses punctuation marks as tags to break the sentence structure into sub-sentences, clauses and terms (particularly when the sentence would otherwise be ambiguous). An extreme example is the infamous buffalo sentence, which is grammatically valid and semantically meaningful but rather difficult to decipher: http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo Of course this is an extreme example, but English is often ambiguous, and some sort of syntax highlighting could potentially be useful: Woman shoots man with crossbow Was it the man armed with a crossbow, or the woman? If we could somehow group the clause with crossbow with woman or man by something *other* than proximity, we could remove the ambiguity. In ordinary English, not only does punctuation sometimes play the role of syntax highlighting, but so do otherwise meaningless words like the, a, which, that, also, and so forth. Bringing it back to Python, that's why punctuation like : are useful. They're syntax highlighting. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sep 17, 10:01 pm, Andreas Waldenburger use...@geekmail.invalid
wrote:
On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote:
I also like this construct that works, I think, since 2.6:
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]
I wonder when this construct will finally start to look good.
Using IFs is just plain ugly. Why not go for the much more pythonic
code = (lambda s:dir[slice(*(s*int(num),None)[::s])])(cmp('o',side))
Much easier on the eyes and no code duplication ... ;)
Bas
--
http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Fri, 17 Sep 2010 16:01:54 -0400, Andreas Waldenburger wrote: On Thu, 16 Sep 2010 16:20:33 -0400 AK andrei@gmail.com wrote: I also like this construct that works, I think, since 2.6: code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] I wonder when this construct will finally start to look good. It looks good to me. It follows a common English idiom: What are you doing tonight? I'll be going to the movies, if I finish work early, otherwise I'll stay home and watch a DVD. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Thu, Sep 16, 2010 at 3:35 PM, DataSmash r...@new.rr.com wrote:
I need to create a simple utility to remove characters from either the
right or left side of directories.
This works, but there has to be a better way. I tried to use a
variable inside the brackets but I can't get
that to work. Can anyone think of a way to do this with less code?
Thanks!
import os
dirs = filter(os.path.isdir, os.listdir(''))
for dir in dirs:
# Left side
snip long if chain
The int() type will convert a string to an int for you. So all you
need to do is check the side and slice accordingly.
if side=='l':
code = dir[int(num):]
else :
code = dir[:-1*int(num)]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 09/16/2010 03:47 PM, Benjamin Kaplan wrote:
On Thu, Sep 16, 2010 at 3:35 PM, DataSmashr...@new.rr.com wrote:
I need to create a simple utility to remove characters from either the
right or left side of directories.
This works, but there has to be a better way. I tried to use a
variable inside the brackets but I can't get
that to work. Can anyone think of a way to do this with less code?
Thanks!
import os
dirs = filter(os.path.isdir, os.listdir(''))
for dir in dirs:
# Left side
snip long if chain
The int() type will convert a string to an int for you. So all you
need to do is check the side and slice accordingly.
if side=='l':
code = dir[int(num):]
else :
code = dir[:-1*int(num)]
I also like this construct that works, I think, since 2.6:
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]
-ak
--
http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On Sep 16, 2:47 pm, Benjamin Kaplan benjamin.kap...@case.edu wrote:
On Thu, Sep 16, 2010 at 3:35 PM, DataSmash r...@new.rr.com wrote:
I need to create a simple utility to remove characters from either the
right or left side of directories.
This works, but there has to be a better way. I tried to use a
variable inside the brackets but I can't get
that to work. Can anyone think of a way to do this with less code?
Thanks!
import os
dirs = filter(os.path.isdir, os.listdir(''))
for dir in dirs:
# Left side
snip long if chain
The int() type will convert a string to an int for you. So all you
need to do is check the side and slice accordingly.
if side=='l':
code = dir[int(num):]
else :
code = dir[:-1*int(num)]
Much appreciated!
I thought I tried every combination, guess I didn't try this as it
works great.
Thanks again.
--
http://mail.python.org/mailman/listinfo/python-list
