Re: allow line break at operators
On 2011-08-10, Chris Angelico wrote:
> And if we require {} then truly free indentation should be OK too! But
> it wouldn't be Python any more.
Would it really not be Python at all?
I've seen bits of code in preprocessing-based "Python with {}" type things,
and they still look like Python to me, only they favor explicit over
implicit a little more strongly.
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-11, Steven D'Aprano wrote:
> Seebs wrote:
>> On 2011-08-10, Chris Angelico wrote:
>>> And if we require {} then truly free indentation should be OK too! But
>>> it wouldn't be Python any more.
>> Would it really not be Python at all?
> Of course it wouldn't be. Every function, class, if, while, for,
> try...except block etc. in existing Python code would be illegal if {} were
> required.
So?
Since there has never been an indentation-related problem in the history
of human endeavors, automatically adding the braces would be completely
trivial.
How much of the language *specification* would change?
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.
This is an interesting point. I guess I meant "look like" in a more abstract
sense; the basic idea of what it's like to read the code, and what you have
to keep in mind while doing so.
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-10, Ben Finney wrote:
> Seebs writes:
>> On 2011-08-10, Chris Angelico wrote:
>> > And if we require {} then truly free indentation should be OK too!
>> > But it wouldn't be Python any more.
>> Would it really not be Python at all?
> See the Python interpreter's response to ???from __future__ import braces???.
I'm aware of that. I have seen all the counterarguments, and what I've
mostly become convinced of is this:
1. Indentation as flow control was a bad idea.
2. People are subconsciously aware of this.
3. There is a HUGE degree of emotional investment in defending it.
The responses I have seen on this issue are highly emotional, full of insults,
full of blame-throwing, and utterly contrary to the basic engineering spirit
I usually see in programming communities. In other languages, and even in
Python on any issue but this one, I regularly see people acknowledge
shortcomings and explain either why they think the tradeoffs are good, or why
they are willing to put up with it anyway.
The characteristic vehemence and hostility this issue produces are the surest
sign of people who have a desperate need not to acknowledge the elephant in
the room.
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.
> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.
Yes, they can.
> In which case either the Python interpreter must guess the programmer's
> intent (very un-Pythonic), or it throws an error and the programmer must
> do busy-work to keep braces and indentation in agreement (also
> un-Pythonic).
The obvious answer would be:
* Braces win because they are explicit rather than implicit.
* Everyone would use things configured to throw a warning or error.
The thing is... This whole argument rests on the assumption that if there
are no braces, there is only one set of things, but if you have braces,
there are two.
This is untrue.
If there are no braces, there are two things describing flow control;
indentation and programmer intent. With braces, there's three.
The most common misalignment is between the code as interpreted by the
computer and the programmer's intent. Neither system prevents this, but
that's where all the real hassle comes from.
My expectation would be that the only times braces and indentation
would be "ambiguous" would be cases where the indentation got screwed up.
In these cases, I would MUCH prefer to get a fatal error than to have
things run in a way entirely unrelated to the intent I had when I wrote
the code.
> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.
I don't think so, any more than I think parentheses which happen to align
with the existing precendence rules are pointless.
In the real world, we are confronted constantly with tools which work
perfectly with every programming language but Python or very old FORTRAN,
but which mangle Python code sporadically and inexplicably. Mail servers
chew up whitespace like there's no tomorrow. Web pages find innovative new
explanations for why those leading spaces don't need to be displayed.
I like Python a lot in some ways, but I am really sick of the insistance that
this godawful wart is the sublime epitome of all perfection, never to be
improved on. It was a really interesting experiment. As sometimes happens,
the experiment discovered things that no one could have reasonably anticipated
without running the experiment.
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-11, Ben Finney wrote: > What evidence do you have of these? The latter, especially, seems to be > mere opinion unfounded in any measurement. Well, on new collection of data, I'm less convinced. The basic rule is: Engineers are nearly always aware of tradeoffs. If I suddenly encounter something where many engineers perceive a tradeoff, and a few deny that there is any tradeoff at all, that usually means that the latter category are not actually doing the engineering thing. > Again, I don't know where you've been observing that, but it's not what > I've seen. I've seen it some here, and in other Python discussion threads. I've also seen counterexamples, though, more now that I brought it up. > You're welcome to attempt to demonstrate the superiority of some other > Python-with-braces, but it will (a) be un-Pythonic, and (b) be unlikely > to gain the efforts of people who don't think what you're addressing is > a problem. I have noticed a tendency for "Pythonic" to produce fierce debates in which there is absolutely nothing measurable to point to. I'm not sold on it. I guess the thing is this: I am pretty sure Python is a pretty nice language. However, the indentation thing has screwed me a few times. Furthermore, I know people who like Python a great deal and acknowledge, without much difficulty, that the indentation thing has caused problems or incompatibilities for them. So when I see people deny that it is at all a problem, or that there are any possible shortcomings to it, I infer that they have some compelling reason to deny the existence of a thing which is reliably and easily observed. See, that's the thing. If you want to tell me that there are problems with braces, I'll *agree*. I am aware of those problems. I don't feel a need to deny that they exist. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-11, Steven D'Aprano wrote: > Seebs wrote: >> I have seen all the counterarguments, and what I've >> mostly become convinced of is this: >> 1. Indentation as flow control was a bad idea. > I'm not aware of any language where indentation is used for flow control. > Python is not one of those languages: it uses for, while, if, etc. for flow > control, just like most other languages. It does however use indentation > for grouping code into blocks -- a different concept. Agh! Point granted. Presumably you knew what I meant, but you're right that I said it wrong. > You are free to hold whatever opinions you like, but have you considered > that the reason people get emotional and angry when others insist that > indentation as flow control should be discarded is because they actually > believe that the "off-side rule" (as it is called) makes for a better > language and a better coding experience? Yes. And when I talk to people who are *able to admit that there exist problems*, and who argue that the benefits outweigh them, I believe that they are probably making a good point. It's the people who insist that there are no problems that worry me. > There are dozens, hundreds of brace languages, and 1-2 dozen using > indentation, including Python. If braces are so important to you, go use > one of those other languages, don't wreck the language we like by taking > away one of the best features of the language. If I had a choice, believe me, I'd do just that. > We're fully aware of the tradeoffs of significant indentation. You are. A couple of other people I've talked to are. Many others are not. > We believe > that brace languages get the trade-offs backwards: they optimise code for > environments which mangle source code. 99.999% of code will never pass > through a broken mail server that strips leading whitespace, or pasted into > broken web forum software that mangles indentation, or go through any other > broken tool that messes with indentation. Brace languages optimise for the > 0.001% case, Python optimised the 99.999% case. This is a really interesting analysis. My experience, though, puts it more at about 99% and 1%. And the thing is... > Because people simply don't like it when their code's indentation doesn't > match the actual semantics, people usually manually ensure that the two > match, braces or no braces. Editors still have commands to indent and > outdent blocks of code. There is no difference between (say) C or Pascal > and Python in that regard. Yes, there very much is. You can't outdent "a block" in Python unless it is already correctly indented. The underlying thing I've noticed is: Braces have problems more often, but the problems are *always* 100% machine-fixable and therefore trivial. It takes milliseconds to get a program fixed so it looks like what it means. Indentation has problems less often, but the problems are *never* machine-fixable. It takes minutes or hours to figure out what was supposed to be there. > There is nothing implicit about indentation. This false dichotomy between > so-called explicit braces and allegedly implicit indentation gets thrown > around all the time, but it is simply *wrong*. Indentation is not implicit. Hmm. Maybe "implicit" isn't quite the right word, but... The end of an indented block is not a thing, it's the lack-of-a-thing. foo bar How many unindents are there between "foo" and "bar"? If you can't answer this from looking between "foo" and "bar", but must instead look at previous lines and *INFER* the number of unindents, then it seems to me that there is something implicit going on here. > And ABC, Boo, BuddyScript, Cobra, CoffeeScript, Curry, F#, Genie, HAML, > Haskell, ISWIM, Miranda, Nemerle, Occam, PROMAL, Spin and XL, plus any > other languages with significant indentation. Point made. > No, most mail servers don't mangle whitespace in the body of the email, or > in attachments. Most don't, that's true. Part of my frustration comes from a 6-month period during which most of my email was sent through a mail server which, for reasons no one was able to determine, was dutifully converting any plain text it received into HTML, and stripping "irrelevant" spaces along the way. :) > Some mail clients do, usually because they default to using > HTML for text. So get a better mail client. I have tried occasionally. Mine does not default to use HTML, but it does sometimes mangle lines. Unfortunately, it's the closest to having other funcitonality I want I've ever seen. > Avoid pig-ignorant web forums > that think that source code can be reflowed or that remove l
Re: allow line break at operators
On 2011-08-11, Steven D'Aprano wrote: > Steven D'Aprano wrote: >> indentation as flow control > Gah! Of course, I meant indentation for blocks... after making the earlier > point that indentation is *not* used for flow control, this was a > particularly egregious error. > How embarrassment. My fault, I probably hypnotized you with my bad word choice. :) -s -- Copyright 2011, 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: allow line break at operators
Before I get to the rest of this: Thinking it through, I've been unreasonable and grumpy here, and I'm trying to figure this out a bit more. A general observation: There's no real data here, so far as I can tell. There is no pair of languages which are exactly identical except for whether they use whitespace or some kind of brace/bracket/thing to indicate blocks, such that we can compare results between them. Humans are *notoriously* unreliable at evaluating the ease with which they do things, how long it takes them, how many mistakes they're making, and so on... So really, this is probably in large part a matter of taste or preference. On 2011-08-11, Ethan Furman wrote: > The times that whitespace indentation has bitten me, it was still not > difficult to fix -- I just had to look and see which line(s) > should/should not be where they were. I've been thinking about this, and I just plain can't understand how this could, in general, be done. Given a bunch of lines of code with no indication of where the blocks were supposed to be, I can't figure how this could be "fixed" in a way that is not-difficult, at least in general. > Not so. If the braces do not match /intent/ (which is the problem I > care most about) then it cannot be fixed by machine. Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. I haven't. Now, I've only been using C for maybe 20-25 years, but in all that time, I have never, ever, not *once*, seen braces not match intent. I've seen indentation errors galore. I've seen nutjobs writing "}}}" on a line all by itself. I've seen people forget to add braces and do stuff like: else a(); b(); ... but I've never, ever, seen braces not match intent. It just hasn't ever happened in code I've seen. >> people who'd picked Python for some stuff I have to work for, point out the >> hostility of the Python community to newcomers whose workflows don't happen >> to have been preemptively built entirely around Python's design decisions, >> and suggest that maybe we use another language. Heck, since I've been >> encouraged so much to do so, I think I will. > Your choice, obviously -- seems a shame to me, though, to give up on > Python because of one or two ouchy areas on c.l.py. By and large it's a > very helpful and courteous community. I was thinking about this more, and I think the issue that's historically bugged me is this: Most of the people I know and talk to about programming languages regard preferences as a matter of personal taste. I've seen people say that they prefer the significant-indentation thing, and I've seen people say they dislike it. The Python community, as a whole, seems particularly dogmatic about the indentation thing. And coming here as someone who doesn't much like it, and has been bitten by it a few times... Imagine that I were taking care of a cat for the first time, and I came to a cat-owners newsgroup, and found the following: 1. Nearly everyone there hated dogs, utterly. 2. The people who hated dogs were snide and insulting about people who didn't hate dogs. ... oookay, then. So I post my question, about a cat peeing on a bed, and I get the following responses: 1. What kind of idiot are you to continue using a broken non-waterproof matress? You should be using a solid vinyl cover over your mattress to prevent it from geting cat pee. 2. Once you've had a cat for a while you'll find that overall cat pee is superior to a dry mattress. ... At this point, I'm not exactly going to feel like a welcome member of the community. :) Now, that analogy is a little extreme, perhaps, but... Programmers get attached to their editors. And having a bunch of people insist that it's crazy of me to use an editor which has worked perfectly for me in the other ten programming languages I use, with settings that are not merely tolerable but *mandatory* for at least one of them, is... well, it doesn't create the impression that people who don't happen to already have fallen in love with an editor that coexists well with the whitespace thing are welcome. And part of this really is personal taste. I *LIKE* having a matching outdent for everything. I like to look at code and see blah blah blah blah blah because then I know it's balanced. If one of them is missing, *something is wrong*. And I have to keep that instinct to stay functional in most of the other languages I know. I don't have the option of ceasing to use C, but if I used C and didn't watch for missing close-braces, I'd be pretty badly hosed. So I have this strong incentive to prefer an explicit thing that I can see. And in any event, I *do* prefer it. In other language communities, when I find things about the langu
Re: allow line break at operators
On 2011-08-12, Ben Finney wrote: > Seebs writes: >> I am pretty sure Python is a pretty nice language. However, the >> indentation thing has screwed me a few times. Furthermore, I know >> people who like Python a great deal and acknowledge, without much >> difficulty, that the indentation thing has caused problems or >> incompatibilities for them. > Yes. It's caused problems for me too, so I'm not going to deny that. > This is different from saying ???indentation as block structure??? is a > problem; that statement is what I disagree with, and what I think most > respondents who disagree with you are objecting to. See below; I think I agree with what I meant by it, and disagree with what you seem to interpret it as. Your interpretation makes as much sense as mine, so far as I can tell. > I don't see anyone making the denials you're referring to there. If I > did, you would have my support in considering those denials mistaken. I suspect, thinking about it more, that it's a communications problem. > Likewise, ???end of line as end of statement??? has caused me and many > others problems. I'd go so far as to say that any Python programmer for > whom that's not true has not done any significant Python programming. > That doesn't make ???end of line as end of statement??? a problem. True, although it does make it a thing which *has* at least one problem. > If a language feature is beneficial in far greater proportion to the > inconveniences of that feature, I'd say that feature *is not a problem* > for users of that language. I wouldn't. Lemme give a concrete example, from C, since that's the language I know best. There are sound technical reasons for which C lets you manipulate pointers. If you couldn't, it wouldn't be C, and you couldn't do the bulk of the stuff that makes C useful. But... Pointer manipulation leads to crashes. LOTS of crashes. I have never met a C programmer with over a day or two of experience who has not had a program crash due to some mishap involving a pointer. When people say that a language like, say, Java, is trying to solve the problems of C's pointer system, I think that's a reasonable thing to try to do. There are tradeoffs. But it would be, IMHO, silly to claim that there are no problems with pointers; there are just benefits which outweigh them *for the things the language is trying to do*. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Ben Finney wrote: > Seebs writes: >> Question for y'all: >> >> Has anyone here ever ACTUALLY encountered a case where braces -- not >> indentation -- did not match intent in a C-like language? I'm talking >> only about cases where braces are *actually present*. > What a strange limitation. Why are you not comparing apples with apples? I am trying to. I'm trying to compare C-like languages, with braces, to Python, with indentation. > The correct comparison would be ???getting the braces to match the > intended structure??? compared with ???getting the indentation to match the > intended structure???. Right. I have seen Python programs in which indentation, while it obviously matched what actually happened, did not match intent. It is (at least in principle) easier to debug because you can see that, but... I've seen people in C do stuff like: for (i = 0; i < N; ++i); a[i] = 0; This is clearly a case where indentation matches intent, but doesn't match functionality, because C allows indentation to not-match functionality; this is the famous problem Python is solving. However, I've never, ever, seen a problem like that *when people were using braces*. An apples-to-apples comparison between indentation and braces should be a comparison *to braces*, not to people who "cleverly" omit braces. (If you are looking for a debate on whether C's optional-braces are a good idea, I'm afraid you will have to look elsewhere; if it were up to me, I would totally approve a language change making them mandatory.) > As you say, the data is thin on the ground for this issue. Would you > accept the charge that you're being just as dogmatic about the > superiority of braces-as-block-syntax? I don't think so. > If not, what makes your position less dogmatic than ours? A couple of things. 1. I do assert that people who are happy with an editor and have been using it for twenty years ought to change their editor to accommodate a language which uses braces. 2. I will happily grant that braces, written legibly, cost you an extra line per block, and that this space cost can make it harder to see all the code at once. 3. I don't have a problem agreeing that there certainly appear to be people for whom the Python syntax is easier to read. I think #1 is the real point at which I think there's a dogmatism problem. Maybe editors shouldn't "helpfully" convert spaces to tabs, but that feature has been nearly entirely beneficial to me in everything else I've edited for a long time, and I don't *want* to learn a new editor just for one language. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Chris Angelico wrote: > On Fri, Aug 12, 2011 at 7:34 AM, Seebs wrote: >> If Python with braces wouldn't be Python at all, why on earth does the >> language even exist? > Every language has its philosophy. Yes. > Etcetera. These are the philosophical decisions made by GvR and the > Python community, and these define Python's syntax. If you go against > these, you could make something that compiles down to Python's byte > code; in fact, I'd say you could make something that produces a .pyc > file and then hands it to the regular Python interpreter for > execution. Is it Python? No, no more than NetREXX is Java just because > it can make a .class file. It's a different language. I would argue that any pure syntactic-sugar change which can be done entirely by a naive preprocessor does not constitute a significant shift in the language itself. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, rantingrick wrote: > What is with you guys and this need to have your hand held to read > code. Good question! Great to see that the helpful and welcoming community is living up to its reputation. My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. > Out-dents are noise and nothing more. Not for me. > When you're driving on a > two lane highway that becomes one lane, would you forget to merge > (OUTDENT) simply because the "merge sign" was missing? No, because the *LANE BOUNDARIES* would move. > If you did then > i would say you need to keep your eyes on the road (CODE) instead of > looking for signs on the side of the road. In other words; you need to > start acting like an intelligent agent instead of a zombie. Interesting theory. I propose we extend it to expression processing in general. Instead of writing a = (x + y) * z let's just write a = (x + y * z It's obvious that no one would have needed to introduce parentheses here unless they wanted to bind the + more closely than the *, so the ) is just noise and not needed. > Hmm, Python's exclusive use of indent/dedent for denoting blocks is > rather unique in a world of braces (barring a few other less known > languages). Removing that feature and replacing it with braces (or > tags or whatever) would change the language significantly! It would, but unless that's the only distinctive trait of the language, I don't think it would make the language cease to be Python. > Likewise allowing a directive like "use braces = True" would also be > detrimental to our code bases. A language must always strive to remove > ambiguities and multiplicity. Having more than one way to mark blocks > is insanity. You never want to induce more overhead than necessary > because such things are detrimental to work flow and language > evolution. Agreed. > This statement leads me to believe you have very little experience > with the Python language. Python has many wonderful attributes and > design philosophies. Significant indentation is just ONE of many. It was a reductio-ad-absurdum. > I don't understand this need for braces. You yearn so badly to be > dominated by them. Is this a psychological disorder, a Helsinki > syndrome that you cannot shake? There is life after braces my friend, > and the future is bright! Man, you really love pushing them buttons, don't you? You don't understand a thing. Therefore... there is no such thing, anyone who experiences life differently from you needs to be insulted? > As much as we love people getting on board we are not about to > sacrifice our strong beliefs in clean source code just so you and > other hardwired C programmers will come along. But you will happily insult people and call them names in order to keep them from having anything to listen to? > PS: I will admit that a few of our community members can be rather > acerbic at times. Yeah. And the thing is... This can't possibly lead to convincing people of your position, so presumably the purpose is that you don't want anyone who didn't start out agreeing with you to ever come to agree with you? Why's that? -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Chris Rebert wrote:
> One argument I've heard from braces fans is that sometimes they want
> their own structure, which does not match the actual block structure.
EWW!
> Example:
>
> FILE* f = fopen(...);
> // do stuff with f
> // at this indent level
> fclose(f);
> // back to normal
>
> But really this is just working around other limitations in the
> language (i.e. lack of a with-statement equivalent).
That's horrid.
FWIW, the C idiom is:
{
FILE *f = ...
...
fclose(f);
}
It isn't used all that widely, but it is a lot less horrible than
random indenting would be.
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-12, Chris Angelico wrote: > Why is left-to-right inherently more logical than > multiplication-before-addition? I'd say it's certainly "more Pythonic in a vacuum". Multiplication-before-addition, and all the related rules, require you to know a lot of special rules which are not visible in the code, and many of which have no real logical basis. Left-to-right is, if nothing else, the way the majority of us read. The problem is that since everyone's used precedence before, not using it violates the principle of least astonishment. ... Hmm. There is a thought; I think it may be useful to distinguish between "Pythonic" and "Pythonic in a vacuum". That is to say, there are things which would fit the basic philosophy of Python very well if previous programming languages and tools were not widespread, and there are other things which fit anyway. Using a simple left-to-right evaluation would probably be easier for people to understand, and more self-explanatory, *IF* there were no prior art. > Why is it more logical than > right-to-left? And why is changing people's expectations more logical > than fulfilling them? Well, playing devil's advocate's advocate here... You could argue that switching from braces to indentation might be "changing" peoples' expectations, or might be fulfilling them, depending on the people. I think there's certainly cases where it is probably better to say "that expectation proves to make it impossible to build a clean language, so we're going to ask you to do things this way", and cases where it is probably better to say "that expectation is very deeply established, and doesn't really hurt the language, so we'll adapt to you". > Python uses the + and - symbols to mean addition > and subtraction for good reason. Let's not alienate the mathematical > mind by violating this rule. It would be far safer to go the other way > and demand parentheses on everything. I wouldn't mind that. > Incidentally, in the original expression, it would be slightly more > sane to write it as: > > a = x + y) * z > > borrowing from the musical concept that a repeat sign with no > corresponding begin-repeat means to repeat from the beginning. But > both of these violate XKCD 859. Yes, yes they do. Huh. You know, that's why the outdents-without-symbols bug me; I have a thing with a colon on it introducing something, and then there's nothing ending it. I want that match so I can let the naive stack-depth-counter off somewhere in my brain do its thing without leaving me with a huge feeling of unclosed blocks. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, rantingrick wrote: > On Aug 12, 11:33?am, Seebs wrote: >> My brain has quirks. ?Some people call them defects, some don't, but it >> really doesn't matter; there are things about which my brain is just plain >> unreliable and I rely moderately heavily on extra visual cues to reduce >> the frequency with which I get things wrong when skimming. > I think that really boils down to you refusing to open your eyes up to > new ways of doing things. You think that, then? Okay. > You are clutching the past and it is taking > you down with it. I see. This is a brilliant new theory. I will further explore the notion that actually my brain is 100% normal with no limitations except that I have used languages with braces. Doubtless this will prove illuminating. >> No, because the *LANE BOUNDARIES* would move. > The "lane boundaries" will also move whilst reading code that uses the > indent/dedent paradigm. Are you honestly telling me that you will skip > over a four spaced dedent without seeing it however you can easily > spot a single closing brace and instantly "know" which corresponding > opener brace to which it referrers without looking, and counting, and > wasting time? Sorry, i just don't believe you. Nope, not telling you that. Here's my example: if foo: blah blah blah if bar: moreblah moreblah if quux: typingisboring typingisboring typingisboring moreblah moreblah if baz: somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah abitmoreblah It's not easy for me to be sure, looking at something roughly like that, what's being closed and what isn't. If I have braces, I can tell how many things are being closed. I like that. It makes me happy. >> I propose we extend it to expression processing in general. ?Instead >> of writing >> ? ? ? ? a = (x + y) * z >> let's just write >> ? ? ? ? a = (x + y * z > I'm glad you brought this up! How about this instead: > a = x + y * z > ...where the calculation is NOT subject to operator precedence? I > always hated using parenthesis in mathematical calculations. All math > should resolve in a linear fashion. 3+3*2 should always be 12 and NOT > 9! Doesn't matter. At some point, somewhere, it would become desireable to introduce precedence with (), at which point, it is quite possible that the trailing ) would be redundant, so why not omit it? > I am not trying to discredit you simply by disagreeing with you. No, but you're certainly being insulting. > I have offered facts as to why significant indention is far superior to > braces and yet you continue to use the same emotionally charged babble > in your defense. Facts: Pry your lips from Ritchie's left teet and stop slurping that "brace" milk; because it is polluting your mind! Emotionally charged babble: My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. > When you offer some real facts then i will give then > just consideration, until then i will "try" to enlighten you of the > merits of significant indentation. Well played! -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Chris Angelico wrote: > On Fri, Aug 12, 2011 at 5:33 PM, Seebs wrote: >> I've seen people in C do stuff like: >> ? ? ? ?for (i = 0; i < N; ++i); >> ? ? ? ? ? ? ? ?a[i] = 0; >> This is clearly a case where indentation matches intent, but doesn't match >> functionality, because C allows indentation to not-match functionality; this >> is the famous problem Python is solving. > There's several solutions to this. One is linting utilities that > detect unexpectedly-indented code, which is the concept that Python > took to the logical extent of syntactic errors. Another is (again > linting) to disallow a direct trailing semicolon; if you want an empty > body, you put whitespace before the semicolon. > > But that wasn't your point, I realise :) I think it sort of is. My current preference would be that C-like languages would simply absolutely eliminate optional-braces. Then the whole category of errors would partially-go-away. You could still have code which didn't do what you meant, but it would be reliably easy to see what it did, and so on. But it's interesting to note that there are many ways to address this. Most of the C I've done has been in circumstances where misindented code was in fact a thing that would fail reviews. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Steven D'Aprano wrote: > Please don't feed the troll. Responding to Rick's standard obnoxious posts > is like wrestling with a pig -- you get tired and filthy, you never > accomplish anything useful, and after a while, you realise that the pig is > enjoying it. Save yourself a lot of aggravation and kill-file him now. You know... I think I just realized where a big part of my misperception of the Python community was. Which is that until todayish, I had not realized that he was regarded as a troll by the rest of the community. But now that a couple of people have told me this, I am a lot more comfortable referring to the Python community in general as "welcoming". I sometimes enjoy trying to extract information from people like that, but I will respect the preferences of the actually-helpful people and drop that line of inquiry. :) -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-12, Steven D'Aprano wrote: > Seebs wrote: >> You know, that's why the outdents-without-symbols bug me; I have a >> thing with a colon on it introducing something, and then there's nothing >> ending it. > But there is something ending it: a change in indentation level. Hmm. Okay, here's what I'm not getting. Consider this: if foo: blah if bar: blah blah if baz: blah blah > Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream. What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. > They're just a change of state in indentation level, which is much more > easily seen without the need for counting braces. Python's parser may need > to count tokens, but for the human reader merely needs to use its intuitive > and highly accurate ability to notice when things line up. Well, that's the thing. In a case like: if foo: if bar: blah blah I notice that *NOTHING* lines up with "if bar:". And that affects me about the way unmatched brackets do. > (Aside: this is why I dislike two-space indents. That's narrow enough to > make the "does this line up" detector subject to too many false positives.) Yeah. >> I want that match so I can let the naive stack-depth-counter >> off somewhere in my brain do its thing without leaving me with a huge >> feeling of unclosed blocks. > Yet another reason to consider brace languages harmful: they spoil the > user's intuitive grasp of intuition as grouping. I assume you mean "indentation as grouping". I'm... not sold on this. It's not that I don't see indentation as a kind of grouping. It's just that I really, really, want groups to have ends. Consider the hypothetical array syntax: a = [ 1, 2 b = [ 3, 4 This *bugs* me. It's perfectly legible, and if you define it that way, it's unambiguous and everything, but... It bugs me. I want beginnings to have an actual corresponding end. > But the human brain is a funny thing: you can train > it to expect to do more work than is necessary, and it will complain when > you make its job easier. Easier varies somewhat from person to person. I need a LOT of parity checks (speaking metaphorically) because my brain is fantastically prone to dropping bits. But I'm really fast. So a thing with lots of parity checks is much easier for me to actually *successfully* use than a thing which omits all that extra stuff. I was overjoyed when I saw that Ruby would let me write 1_048_576. I can read that with fewer errors than I can read 1048576. (And yes, I could also write "1<<20".) -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-13, Terry Reedy wrote: > I have been indenting code neatly for at least 32 years whenever the > language I used allowed it. Just over 14 years ago, when Python was an > obscure little known or used languge, I adopted it *because* it dropped > all the redundant bracket noise and looked to me like 'executable > pseudocode', as I explained (with an unfortunate misspelling) in > https://groups.google.com/group/comp.lang.python/msg/cc25701a283a3f68 > Indentation is part of that. Python-with-brackets would, to me, be > something different -- sure, derived from Python, but not the same. Fair enough. > I do not need for you to adopt and use Python to validate my choice. If > you like it fine, welcome. If not, have fun with something else. If this were among my options, it's probably what I'd do. It is what I do for things where I get a choice of languages. FWIW, yes, I spec machines with ECC memory whenever I can. I am a big fan of "redundant" data that can detect likely errors. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-13, Ben Finney wrote: > Seebs writes: >> What's being pushed into the stream to indicate that the first outdent >> is two outdents and the second is one? > See http://docs.python.org/reference/lexical_analysis.html> for a > comprehensive discussion of the lexing done on Python source. Interesting, thanks. -s -- Copyright 2011, 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: Ten rules to becoming a Python community member.
On 2011-08-14, rantingrick wrote: > Follow these simply rules to become an accepted member of the Python > community. > 1. Bash rantingrick and Xah Lee every chance you get. ... If I'd known you were in the same category as him, I wouldn't have needed to wait until now to know to plonk you. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-14, Steven D'Aprano wrote: > Seebs wrote: >> I guess... The parser is explicitly pushing those tokens, but I can't >> *SEE* those tokens. If I am looking at the end of a really long >> thing, and I see: >> >> blah >> blah >> >> I only know what's happening if I have absolute confidence that the >> indentation is always by the same amount, etectera. > I believe this is a dubious argument. With only two lines of code in > isolation, understanding the indentation changes is the least of your > worries. Adding block delimiters doesn't give you any significant help -- > ESPECIALLY if the block delimiters don't align with the indentation! > blah > } > blah > } Interesting. I am sort of getting to an insight into this, which I am not sure I can articulate. FWIW, I've had to debug C (well, C++) much worse than that (... long story, but rest assured, the lulz justified the effort of reading the transcendantly awful code). I could still do it. :) > In isolation, you don't even know whether the above is syntactically valid, > since you have no way of knowing that either end brace is closing an open > brace or not. Ahh, but the computer can tell me that. I don't have to see it. > "Who would write such a horrible mis-aligned piece of code?" Good question. > If you're going to have style-guides that prohibit writing code like the > above, then what exactly do the braces give you? I think what they give me is... basically a parity bit. It's easy for people to screw up code, such that the code written does not reflect intent. Braces give me a likely red flag -- if they are screwed up, I know that this is a good palce to start looking. If they're not, then all they're costing me is a little vertical space. > Yes, yes, if you paste the code into a web forum the indentation may > disappear, and if your hard drive controller is faulty it may randomly > overwrite blocks with data belonging to other files. We all agree that > environments that destroy data are Bad. "Destroy data" is a sort of fungible concept. I was reading a comic book recently and it contained a URL for a poem which had been parodied. The URL had been hand-lettered... in block capitals. The actual URL had exactly one upper case letter in it. Whoops. In general, I don't think all data-loss is identical in severity. Outside of Python and Makefiles, I don't use anything where whitespace damage of the sort of "losing or changing leading spaces" is usually significant, so I *normally* regard it as a trivial change. > Do you get worried by books if the last page doesn't include the phrase "The > End"? These days, many movies include an extra clip following the credits. > When the clip finishes, and the screen goes dark, how long do you sit > waiting before you accept that the movie is over? > *wink* It's an actual thing I have been bitten by, especially because I often really enjoy those clips, and I've seen a movie that had two. > The above example bugs me too, because it is too close to what I'm used to > in Python. I see an open bracket, I wait for a close bracket. Perhaps this > would be better: > a = array > 1, > 2, > b = array > 3, > 4, > Not so bad now, I betcha. Interesting! For me this triggers the same "WHERE IS THE END MARKER???" reflex. These bug me like unmatched brackets. > but you still can't nest arrays. This potential syntax doesn't feel like a > unified whole, but like a bunch of unrelated fixes for problems. Sometimes > a literal START and END delimiter is the right answer. I think so. > Python's use of indentation to delimit blocks doesn't feel like that. Unlike > arrays, you can't use blocks in an expression, and I think that's the > factor which makes all the difference. Ruby folks may call the lack of > block expressions a problem with Python, but even if they're right, I don't > think it's a *big* problem. I actually really *like* that Ruby and Lua let pretty much everything just be an expression. I was utterly dumbfounded when I found out that "print" in Python is a kind of statement, not a function or something comparable. (This seems to have changed recentlyish.) > Either way, given the restriction that blocks > are statements, not expressions, the lack of an overt block markers is not > a problem for code (with the proviso that a rogue editor doesn't go making > arbitrary changes to your source code). Yeah. I suspect that if I'd never used something with braces, I might not
Re: allow line break at operators
On 2011-08-14, Chris Angelico wrote: > Yes. Not everything's an expression; a block of code is not an > expression that returns a code object, and variable assignment is a > statement. Some day, I'd like to play around with a language where > everything's an expression and yet it doesn't look like LISP - just > for the fun of it. It probably won't be any more useful for real world > coding, but it'd be fun to tinker with. Ruby and Lua are both pretty close. I'm not an expert in either, but I can't think of anything I can write in Ruby which isn't an expression. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-14, Steven D'Aprano wrote: > Seebs wrote: >> "Destroy data" is a sort of fungible concept. I was reading a comic book >> recently and it contained a URL for a poem which had been parodied. The >> URL had been hand-lettered... in block capitals. The actual URL had >> exactly one upper case letter in it. > Er, most URLs are case insensitive, at least the most common ones, including > HTTP and HTTPS. So I don't quite see why you think this was a Whoops. Sort of. Host names are case insensitive, so far as I can tell "always". Paths past that are distinctly NOT always case insensitive, and since the server in question happened to be doing what appear to be "straight path lookups", it mattered a great deal that you had to downcase all but one of the letters. (The obvious technique of downcasing them all failed.) > Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng. > But try that with your source code :) Eh, I'm a C programmer, what makes you think I had any vowels to begin with? > Yes, print as a statement was a mistake. But assignment as a statement, not > so much. Assignment as an expression in languages that have it tends to be > associated with frequent errors. It does. I'm not sure whether the errors are compensated for by the expressiveness. I *think* on the whole they are, but I am honestly not sure. I do like gcc's warning for assignment used as a truth value. > The way I see it, if something operates by side-effect, then it has no > business being treated as an expression. Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. >> Say I try to indent or outdent something and I grab the wrong set of >> lines. It's certainly possible for this to result in valid code... And I >> have no >> cue as to what happened. Even if I get a warning, I can't necessarily >> tell what happened. > Then don't do that. If not doing that were a realistic option for me, I'm guessing I'd have stopped making typos thirty years ago. > I'm not impressed by arguments based on "but if I do something stupid, like > select text with my eyes closed and reindent it without looking, I expect > the compiler to save my bacon". In my opinion, it's not the compiler's job > to protect you from errors caused by sheer carelessness at the keyboard. I don't know about "sheer carelessness". Typos happen. Typos are not something you can prevent from happening just by wanting it very much. > In any case, while reindenting an arbitrary set of lines may *possibly* > result in valid code that runs but does the wrong thing, the likelihood of > that happening is remote enough that I'm not going to lose any sleep over > it. Ahh, but what about the case where it results in invalid code? It's not necessarily obvious which lines need to be moved after that. >> foo.each do |bar| >> bar.do_a_thing >> do_something_with(bar) >> end >> next_thing >> something else >> I know immediately that it's wrong. > How? The "end" is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. > Unless I understand the intent of the code, how can I tell whether the END > token is in the right place or not? And if I understand the intent of the > code, then the END token is redundant. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. >> If I do something in my editor and end up with: >> if foo: >> bar.do_a_thing >> do_something_with(bar) >> next_thing >> something else >> I can't immediately see that I hit the wrong number key when telling >> the editor how many lines to adjust. >> Typos happen. I rely heavily on things that let me catch them in as many >> ways as possible. > I call that a poor user interface design. If you have to count the number of > lines before applying an edit, instead of selecting a range of text, then > you should stop using a tool that is stuck with a UI from the early 1980s. You keep telling me to stop using this editor. I have not seen a suggested improvement. (Hint: GUI editors are not an improvement for my purposes, as I do about 99.5% of my editing on machines that aren't in the same state that I am. No, the GUI editor cannot offer enough improvement in anything to justify the cost of copying files back and forth constan
Re: allow line break at operators
On 2011-08-14, Teemu Likonen wrote:
> I understand that Python philosophy does not value freedom of expression
> that much. It values a general Pythonic rule which must obeyed and is
> called "readability". Other languages give too little or too much
> freedom. :-)
There is an interesting tradeoff, there, because I tend to find stuff
like "variable = {fancy if expression}" to be much *more* readable, since
I immediately get the top-level information ("we're assigning variable")
and then I can look for details if I care.
-s
--
Copyright 2011, 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: pythonw.exe
On 2011-08-14, Chris Angelico wrote: > Just to confuse things even further, it's not unlikely that a Mac or > Linux or Windows computer will have DOSBox installed. Is *that* DOS? > Technically no, but practically yes. Depending on how you define "unlikely", I'd guess it is. Assume that "unlikely" means roughly the equivalent of "if I were optimizing, I'd use a compiler branch prediction hint at this point". :) -s -- Copyright 2011, 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: Ten rules to becoming a Python community member.
On 2011-08-15, Steven D'Aprano wrote: > And yet, here you are, engaging him in conversation and feeding him the > attention he craves :( Many cultures have a tradition of almsgiving. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-15, Steven D'Aprano wrote: >> Interesting! I tend to really like the ability to chain methods, >> depending >> on context. I find the side-effect/expression mix pretty normal, so I'm >> used to it. > As a rule, chaining method calls risks violating the Law of Demeter. Just > sayin'. "Risks violating" isn't the same thing as "violates". > But a good editor can minimise command typos. User interfaces matter. If > your car required you to reach over your left shoulder and pull a lever in > order to slow down, it would be a really bad design. It would join these > interfaces: Yeah. > If your editor doesn't help you minimise bad commands, then your editor > doesn't work for you, it works against you. Life is full of tradeoffs. The editor does a lot of things which very much improve my performance, with costs which are usually pretty easily mitigated. >> I don't know about "sheer carelessness". Typos happen. Typos are not >> something you can prevent from happening just by wanting it very much. > I sympathise, but don't care. That's your problem man, not Python's. Debatable. There's a sort of fuzzy boundary between "clearly this is a defect in the product" (see interfaces that kill), and "clearly this is a defect in the user". In fact, one of the major areas of interesting UI research involves interfaces that accommodate things which are generally regarded as defects in the user. Think about colorblindness. Obviously, it's the user's problem, not the editor's, but an editor which picks colors which most colorblind people can't distinguish for something important is going to get castigated for it. > I hope you can still be productive in Python, and it's not like anyone > *wants* you to stop using Python and use another language, but you have to > understand that Python wasn't designed for *your* needs precisely. That > doesn't make indentation as syntax a bad choice. I think it depends a lot on the goals. So far as I can tell, the primary goal of the policy was to eliminate a class of errors. It... well, it does this in a strictly technical sense, in that every error which occurs is no longer of that class. It does not seem to me that it's done very much to turn the kinds of things which used to result in that class of errors into non-errors; rather, it's turned them into different errors. > Are you talking about code you've moved from somewhere else and need to > reindent? Then if the code was working before, it will keep working if you > have the same relative indentation. (At least indentation-wise. It may > break due to other factors.) Revert your bad reindent and try again, more > carefully this time. The point is... I can't *TELL* what the boundaries of the bad-reindent are. Because there's no unambiguous point at which I can say "oh, look, here is the line where the indentation starts being wrong", unless there's a syntax error... and even then, the syntax error might be before or after the actual bounds of the bad indent. With properly-braced code in a brace language, any mis-indent you do can be unambiguously identified -- you have a 100% guarantee that you know what the first and last misindented lines are. In Python, you can usually guess within a couple of the lines, more easily if you're familiar with the code. > If you're making semantic changes to the code, not just a simple move, then > surely you understand what changes you're making and not just randomly > indenting and dedenting until it complies? Read the code and decide how to > fix it. The case that has historically bitten me is that I move N lines of code, and then I try to adjust the indentation of those N lines, and... SOMETHING happens. Maybe someone somewhere introduced tabs and adding four leading spaces doesn't do anything. Maybe I mis-counted N. > I get it that sometimes there will be code which is hard to follow and hard > to edit. But if that's the case, you've got more maintenance problems than > indentation, and indents are the least of your problems. Not if the only reason that it's hard to follow is that the indentation is screwed up. >> The "end" is misaligned. Therefore SOMETHING is wrong. I don't know >> what, but I can be confident that something went wrong. > Okay, now I'm confused... if indentation doesn't matter, how is the end > misaligned? Indentation doesn't affect the *compiler*, but we know the rules for indentation. It's a parity bit. If the indentation and the begin/end don't agree, then I *know something is wrong*. And I know on exactly which line it becomes wrong. That turns out to save me a fair bit of time if I have to look at code and try to figure out what's wrong. >> The question is not whether it's on the right line. No amount of >> indenting or >> outdenting can ever break that. The question is whether I've gotten the >> indentation screwed up. > But if indentation doesn't matter, you can't screw it up. Isn't that the > whole point of this discus
Re: allow line break at operators
On 2011-08-15, Chris Rebert wrote:
> On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
> wrote:
>> As a rule, chaining method calls risks violating the Law of Demeter. Just
>> sayin'.
> Not in the specific case of fluent interfaces[1] though, which could
> have been what Seebach had in mind.
They're the most obvious example, from my point of view.
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(", ")
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
", ".join(mapped_array)
(I am still not used to Python's attachment of join to strings rather
than to arrays. I don't really object to it, it's just not how I think
about join operations.)
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-15, Steven D'Aprano wrote:
> Seebs wrote:
>> I tend to write stuff like
>>
>> foo.array_of_things.sort.map { block }.join(", ")
>>
>> I like this a lot more than
>> array = foo.array_of_things
>> sorted_array = array.sort()
>> mapped_array = [block(x) for x in sorted_array]
>> ", ".join(mapped_array)
> If you insist on a one-liner for four separate operations, what's wrong with
> this?
> ", ".join([block(x) for x in sorted(foo.array_of_things)])
Nothing in particular; I was just contrasting two styles, not asserting
that Python couldn't do that.
In general, I don't like to do things that either involve making a lot of
variables that are assigned to once and then read from once, or making a
whole lot of x = foo(x) type assignments to one variable. It feels cluttered
to me.
> I think I would be less skeptical about fluent interfaces if they were
> written more like Unix shell script pipelines instead of using attribute
> access notation:
> foo.array_of_things | sort | map block | join ", "
Interesting! I think that's probably why I find them so comfortable;
shell was one of the first languages I got serious about.
-s
--
Copyright 2011, 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: allow line break at operators
On 2011-08-15, Roy Smith wrote:
> Demand, no, but sometimes it's a good idea. I've been writing computer
> programs for close to 40 years, and I still have no clue what most of
> the order of operations is. It's just not worth investing the brain
> cells to remember such trivia (especially since the details change from
> language to language). Beyond remembering the (apparently) universal
> rule that {*, /} bind tighter than {+, -}, I pretty much just punt on
> everything else and put in extra parens everywhere.
>
> It's not the most efficient way to write code, and probably doesn't even
> result in the prettiest code. But it sure does eliminate those
> face-palm moments at the end of a long debugging session when you
> realize that somebody got it wrong.
Wholehearted agreement. It is conceivable for me to misremember precedence.
I am pretty reliable at recognizing which things are in which parens.
So I use them even in obvious cases:
foo + (3 * 4)
Never regretted that. Yes, it's extra typing, a little, but it prevents a
whole category of bugs.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-15, Ethan Furman wrote: > Gerrat Rickert wrote: >> What sayest the Python community about having an explicit warning >> against such un-pythonic behaviour (re-assigning builtin names)? > What makes you think this behavior is unpythonic? Python is not about > hand-holding. It seems like something which is sufficiently likely to be a mistake might deserve a warning -- especially since, so far as I can tell, there's never going to be a program which can't easily be written to avoid the problematic behavior. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-16, Roy Smith wrote: > In article <4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: >> I'm reminded of this quote from John Baez: >> "The real numbers are the dependable breadwinner of the family, the complete >> ordered field we all rely on. The complex numbers are a slightly flashier >> but still respectable younger brother: not ordered, but algebraically >> complete. The quaternions, being noncommutative, are the eccentric cousin >> who is shunned at important family gatherings. But the octonions are the >> crazy old uncle nobody lets out of the attic: they are nonassociative." > Wow, at first glance, I mis-parsed that name as "Joan Baez". Had me > really confused for a moment. Would it have been that much weirder than Hedy Lamarr? -s -- Copyright 2011, 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: Ten rules to becoming a Python community member.
On 2011-08-16, Roy Smith wrote: > In article <9att9mf71...@mid.individual.net>, > Gregory Ewing wrote: > >> I don't mind people using e.g. and i.e. as long >> as they use them *correctly*. > > The only correct way to use i.e. is to use it to download a better > browser. Similarly: Boy, is there, e.g., on my face now! -s -- Copyright 2011, 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: Anyone here can do a comparation between Djang and RoR
On 2011-08-16, smith jack wrote: > what is the advantage of Django over RoR:) This question is pretty much... I mean, you're not gonna get useful answers. They're based on such different languages that I think any comparison past that is likely going to be uninteresting to a programmer, and I'm not sure any non-programmers are going to use either. I will say, the things I most value in Rails are pretty much contrary to conventional Python design philosophy. Python's stress on explicit over implicit is probably in contradiction with the Rails philosophy of convention over configuration. So for instance, if all you want of a class that maps to a database table in Rails is that it map the fields in the database, the class body is empty because that's the default. If you want to tell it that the database column foo_id represents the id of the foo object with which this record is associated, and you want to call that .foo, you write: belongs_to :foo and the rest is all implicit. This is really handy sometimes, but it's not very Pythonic... Mostly, I think you'd probably be better off asking in a completely different kind of forum, but even then, you're going to get mostly language advocacy. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Steven D'Aprano wrote: > On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote: >>> Why should built-ins be treated as more sacred than your own objects? >> Because built-ins are described in the official documentation as having a >> specific behavior, while my objects are not. > *My* objects certainly are, because I write documentation for my code. My > docs are no less official than Python's docs. Sure they are. I can't get yours from python.org. > You can shadow anything. Sometimes shadowing is safe, sometimes it isn't. I > don't see why we should necessarily fear safe shadowing of built-ins more > than we fear unsafe shadowing of non-built-ins. I think largely because anyone coming to your code will have expectations about the built-ins. For non-built-ins, they'll have to look around the code to see what they do, but for built-ins, they come to the table with an otherwise-reasonable expectation that they already know what that word means. > A warning that is off by default won't help the people who need it, because > they don't know enough to turn the warning on. A warning that is on by > default will be helpful to the newbie programmer for the first week or so, > and then will be nothing but an annoyance for the rest of their career. Will it? I am pretty sure that I'd keep it on and fix anything that triggered it, because shadowing built-ins strikes me as Asking For Trouble. > Protecting n00bs from their own errors is an admirable aim, but have you > considered that warnings for something which may be harmless could do more > harm than good? I would distinguish between "may not be causing bugs" and "may be harmless". I think code which shadows a built-in has a pretty real risk of being harmful at some unspecified future point when some maintainer who hasn't memorized every last line of the code makes the totally reasonable assumption that basic language features are still working and available. > Perhaps. But I'm not so sure it is worth the cost of extra code to detect > shadowing and raise a warning. After all, the average coder probably never > shadows anything, and for those that do, once they get bitten *once* they > either never do it again or learn how to shadow safely. I don't see it as a > problem. I would guess that it happens moderately often entirely by accident. Not a Python example, but I recently had a heck of a time with some JavaScript I was trying to maintain. Couldn't get it to work on a slightly older Firefox, and the diagnostics from Firebug came across as basically illucid. Problem: I was declaring an array named 'history'. My thoughts would be: 1. It's hard to avoid shadowing anything unless you know the entire language and never forget things. 2. In particular, Python likes to use clear, obvious, names for things. Meaning that your choice of a clear, obvious, name for a similar thing could be the name of a thing in the language. 3. I am not sure at all that shadowing can be "safe" in code which will some day be maintained. The chances of someone coming along and trying to write clean, idiomatic, Python which happens to blow up interestingly because their code runs in an environment where part of the standard language has been shadowed strike me as Too High. MHO, but speaking only for myself, I'd want that warning on and I'd not consider it harmless. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman wrote: > I think warnings should be reserved for language changes and such (like > DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible > programmer mistakes. I disagree, on the basis of the following: The quality of C code I have to deal with has increased dramatically as gcc's aggressive use of warnings has spread. > Python can be improved -- I don't see 'hand-holding' as an improvement. > IDEs and lints can do this. -W ignore -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman wrote: > What makes you think it's unintentional? Programming experience. People *often* do things unintentionally. > Seems to me the real issue is somebody using a builtin, such as str or > int, and that they somehow manage to do this without realizing, "wait a > sec', that's one of my variables!" I don't see that as a problem that > Python needs to solve. I think the word "my" prejudices the case. Imagine stepping into a large project that uses multiple frameworks and class libraries and so on. You know Python but you're new to the project. Under which circumstance will you have more problems? 1. There is not a single shadowed built-in in the entire project. 2. There are dozens of shadowed built-ins based on when the original programmer felt there wasn't going to be a need for a given built-in feature, or possibly just didn't know about it. Also, how easy or hard do you think it will be to debug those problems? What's your first response going to be if, on a screen which doesn't contain the word file at all, you try to use the file built-in and you get some cryptic error? Are you going to know to go looking for the shadow right away? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman wrote: > Seebs wrote: >> The quality of C code I have to deal with has increased dramatically as >> gcc's aggressive use of warnings has spread. > With gcc you pay the cost once, with Python you would pay it with every > run. A linter would be more along the lines of 'pay it once'. Huh! That is a really good point, which I had not considered. I still prefer to get warnings, but... Hmm. I wonder whether there's a way to mitigate the cost of these things by messing with -W settings, such that runtime that wants to be fast can omit the checks, but the default could still be to, well, prevent likely errors. -s -- Copyright 2011, 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: allow line break at operators
On 2011-08-16, Prasad, Ramit wrote: >What exactly is the downside to indentation as flow control? I think a lot of it is personal taste or differences in how peoples' brains work. I don't want "free form code", I don't want to write stuff that isn't correctly indented. I want a visual cue I can match up with the start of a loop so I know for sure what I meant, and a way to recover code in the event of Something Going Wrong. >I am not sure why people are so stuck on braces. I figured other >people would be like me and tired of having to do things like >figuring out where I missed an end brace. For me, if I've made an error of that category, the options are: 1. In C, finding out where I missed an end brace, because the compiler warned me, so I go look for an outdent without a brace. 2. In Python, having no clue at all what's wrong or why the program isn't running, and having no cue I can look to to see where the error occurred. Basically, it's parity bits. I love me some parity bits. :) I also recognize that this is a matter of taste; there are sound reasons for other people to have different preferences. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Terry Reedy wrote: > On 8/16/2011 2:56 PM, Seebs wrote: >> I wonder whether there's a way to mitigate the cost of these things by >> messing with -W settings, such that runtime that wants to be fast can >> omit the checks, but the default could still be to, well, prevent likely >> errors. > Warning messages have a cost even if suppressed. Yes, but is it a *significant* cost? My assumption is that the suppression would be of checking, not just of displaying messages. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico wrote: > On Wed, Aug 17, 2011 at 12:49 AM, Seebs wrote: >> Yes, but is it a *significant* cost? ?My assumption is that the suppression >> would be of checking, not just of displaying messages. > It mightn't be very significant, but there'd still be some cost. > However, IMHO the greatest cost is the spamminess; forcing the user to > deal with lines and lines of warnings is not a useful way to design a > language. Lines and lines? I'd say if it's to be allowed to shadow built-ins (and I'm not sure that's a good thing at all), you'd still be looking at one warning per shadowing, which shouldn't be too many. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Steven D'Aprano wrote: > Seebs wrote: >> On 2011-08-16, Steven D'Aprano >> wrote: >>> *My* objects certainly are, because I write documentation for my code. My >>> docs are no less official than Python's docs. >> Sure they are. I can't get yours from python.org. > And what makes that unofficial? > python.org is not the sole arbiter of official documentation in the world. But it is the sole arbiter of official *Python* documentation. If I am looking at code in Python, I reasonably expect the Python docs to be correct about that code. Incomplete, sure, but *correct*. >> I think code which shadows a built-in has a pretty real risk of being >> harmful at some unspecified future point when some maintainer who hasn't >> memorized every last line of the code makes the totally reasonable >> assumption that basic language features are still working and available. > Am I the only person who writes functions and methods any more? *wink* Yes. Everyone else converted to single giant blocks of code because they are easier to develop. :P > Modern languages, and by modern I mean most languages more than, oh, about > fifty years old, provide ways to limit the scope of variables. You don't > need to memorise "every last line of the code" to safely edit a function. Only the parts that are in scope, but... I seem to recall (and I'm pretty Python newbiesh, so I could be wrong) that Python classes create a scope in which bits of the class become visible, and some classes are sorta biggish. > def process(list, arg): > spam(list) > ham(arg) > cheese(list, arg) > The scope of parameter "list" is limited to within the function process > itself. Inside, it shadows the built-in list. Outside, it doesn't do squat. Yes. But what about the built-in spam? :) > Define the "entire language". Does that include the names of all the > plethora of exceptions? How about the standard library? I'd think "standard library" or close to it. > For what it's worth, I don't care about memorising all the built-ins. I > delegate that job to my editor, which has a syntax highlighter for Python. > It never forgets built-ins. (In fact, sometimes this is a nuisance. When > I'm editing Python 3 code, it still insists that apply and reduce are > built-ins.) Heh. I mostly don't use syntax highlighters; at best, they distract me, at worst, they distract me a lot. I also don't use one in English, although I am sure some people would love to have nouns in blue and punctuation in green. > Yes, and Python also encourages the use of scopes, so that the clear, > obvious name for something in one scope does not clash with the clear, > obvious, identical name for something completely different in another > scope. "Another" scope is normally a horizontal thing -- you're talking about a different scope such that you are *either* in this one *or* in that one. Built-ins are not in a scope you are never not in. > Oh there's no doubt that shadowing *can* be unsafe. But then, very few > things can't be abused. Yup. > As I see it, there are (at least) four stages related to shadowing. > (1) At first, you don't even know enough to be concerned by shadowing. You > blithely call variables "list" and "str" without a care in the world... > until something goes wrong. > (2) Second stage, you know enough to realise that shadowing can be bad. You > avoid shadowing everything. Your code is full of variables called "my_list" > and "astr" and "some_tuple". You call your functions things like "izip" > even though it is designed as a replacement for zip, because the caller > might use from itertools import * and accidentally replace the built-in zip > with my zip. > You even avoid using "string" as a variable name because it might shadow the > string module -- even though you haven't actually imported or used the > string module in the last four years. Heh. (I got advised by pylint not to grab something from it, but I no longer remember why; I seem to recall being totally unable to find a way to avoid that warning and still have the string processing I needed.) > (3) Eventually, you get frustrated writing doc strings like this: > > def function(astr, myint=0): > """function(astr [, myint]) -> list > > Arguments: > astr - string > myint - integer > > Do something tool-like to a string and optional integer... > """ > and begin writing them like this: > def function(astr, myint): > """f
Re: Wait for a keypress before continuing?
On 2011-08-17, John Doe wrote: > Using "does your code have a GUI" produces zero search results. > Maybe that works better in some other language. You shouldn't need a search engine to answer a question about your code. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? -s -- Copyright 2011, 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: Wait for a keypress before continuing?
On 2011-08-17, John Doe wrote: > Context is lost when you quote only one level. Not significantly. > I was not answering a question about my code. I was pointing out > the fact that my questioner's terminology is strange/corrupt. Well, that's the thing. There was a question there, with perfectly valid terminology. >> If you do, it suggests that perhaps one or more of the terms are >> unfamiliar to you? > Yes, even the common term "command line" is foreign to me. I do > some powerful stuff in Windows, without need for a command line. So apparently you *do* know the term. Normally, to say that a term is foreign to you is to say that you have no idea what it means, not that you know what it means but don't use it. > I realize it exists and that some people live by it, but it has > been nearly useless to me. In which case, you're not using a command line, and are using a GUI, and the other poster's question is answered. The Google results you cite to are uninteresting and frankly irrelevant. If someone asks me whether the ornamental fish in my 55-gallon tank is a koi, that Google has no hits for "ornamental fish in your 55-gallon tank is a koi" does not mean that the terminology is "strange" or "corrupt". The terminology was fine. -s -- Copyright 2011, 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: Wait for a keypress before continuing?
On 2011-08-17, peter wrote: > Is there an equivalent to msvcrt for Linux users? I haven't found > one, and have resorted to some very clumsy code which turns off > keyboard excho then reads stdin. Seems such an obvious thing to want > to do I am surprised there is not a standard library module for it. Or > have I missed someting (wouldn't be the first time!) There's no direct equivalent to the whole of msvcrt. The Unixy way to do stuff like that on the command line is usually curses. But to make a long story short: Unix evolved in a setting where there was often not a user at *THE* console, and users were often on devices such that it made sense to have all the line editing happen on the remote end, with the remote end sending a completed line once the user was done with all that stuff like backspaces. Unix programs that do stuff like this for tty input do exist, of course, but for the most part, they use an entire API designed for creating such utilities, rather than one or two specialized functions. (Another part of the reason for this: The Unix solution scales nicely to the case where the five people using your program will be doing so on physically different hardware terminals which don't use the same escape sequences for cursor movement.) Usually when people omit something obvious from a design, it's because of other constraints or history to the design which make it less obvious. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico wrote: > def foo(list): >"""Foo's the list provided and returns True on success or False on > failure.""" > > def bar(list): > """Counts the number of bars in the list, assuming it to be made > of music.""" > if not foo(list): return > You call foo() once and bar() twice. How many shadowings have there > been? How many warnings do you get? I'd say two, one when def foo... is parsed, one when def bar... is parsed. > A simple implementation would give five warnings for this case - once > for each invocation that shadows a builtin. Another simple > implementation would give two warnings, at the time that the def > statements are executed; this is preferred, but it's still two > warnings, and if you have a huge set of functions that do this, that > can easily be "lines and lines" of warnings. Or should it set a flag > and say "I've already warned this session about shadowing 'list', so > suppress all others"? That seems confusing. I guess I don't object to multiple warnings if I do the same thing multiple times. I was just thinking in terms of a single parse-time warning for the actual point at which something is shadowed, rather than, say, a warning every time a name is hit during execution of statements and refers to a shadow. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Steven D'Aprano wrote: > On Wed, 17 Aug 2011 01:17 pm Seebs wrote: > [...] >> "Another" scope is normally a horizontal thing -- you're talking about >> a different scope such that you are *either* in this one *or* in that >> one. >> Built-ins are not in a scope you are never not in. > That's technically incorrect. Built-ins are a scope you are never in, if > by "in" you mean "code is executed in this scope". No, by "in" I mean "lookups from your code will reach this scope if they don't find something sooner". >> Hmm. See, I've never reached that, in Python or any other language. I >> figure it creates a new potential for confusion, and that I would rather >> avoid any ambiguity. I don't *like* ambiguity in code. > Ah, well you see the thing is, this is Python. As soon as you call any > function you don't control, you no longer know what your environment is > with any certainty. For all you know, the harmless-looking function is > monkey-patching builtins like there's no tomorrow. Speaking broadly, > perhaps too broadly, we're incredibly proud of the ability to modify nearly > everything at runtime. Heh. > Fortunately, while we are proud of having that ability, actually *using* it > is considered a mortal sin. We're not Ruby developers -- if you actually > monkey-patch something, especially built-ins, you can expect to be taken > outside and slapped around with a fish if you get caught. Okay, so. Here's what I don't get. If it's such a bad thing, *why is it allowed*? Why are you proud of the ability to do something that you are never socially-allowed to do? I have mixed feelings about Ruby's general tolerance for monkey-patching, although I've seen it do some pretty awesome things, so I am somewhat inclined to accept that it may be worth it. But it's clearly a feature which is used intentionally. It sounds to me like Python is very proud of having a feature which no one would ever use. ... Why? > Sure. But they can't have that certainty regardless of whether you shadow > something, because how do they know whether you've shadowed it or not? Well, they could trust me. :) > In theory, anything could be anything at any time, and you have no > protection. In practice, I worry more about being eaten by > genetically-engineered flying piranhas than about rogue monkey-patching > code. I do too, if I know that people don't shadow built-ins. If I know that people are shadowing built-ins, then some of the time, when I'm editing other peoples' code, they HAVE effectively monkey-patched it. -s -- Copyright 2011, 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: Wait for a keypress before continuing?
On 2011-08-17, Steven D'Aprano wrote: > I shouldn't need to say this to anyone over the age of four, but being > obnoxious to people trying to help does not encourage others to answer your > question. You don't win points for insulting people who are trying to solve > your problems. The frustrating part, of course, is that the people who do this are doing it for reasons such that the explanation seems only proof that they are even more right than they had previously expected. Pathological narcissism is scary. If you ever find yourself going longer than usual without being wrong, start checking your work more carefully. :) -s -- Copyright 2011, 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: Wait for a keypress before continuing?
On 2011-08-17, Terry Reedy wrote: > The difference is between "Hit to continue" (which we can do in > portable Python) versus "Hit any key to continue" (which we cannot, and > which also leads to the joke about people searching for the 'any' key > ;-). And more importantly, frustration and confusion when people pick control or shift. > The equivalent contrast for GUIs is "Click OK to continue" versus > "Click anywhere to continue" If having to click a specific area is okay > for GUIs, having to hit a specific key for TUIs should be also. In general I agree. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Ethan Furman wrote: > Seebs wrote: >> On 2011-08-17, Steven D'Aprano wrote: >>> Ah, well you see the thing is, this is Python. As soon as you call any >>> function you don't control, you no longer know what your environment is >>> with any certainty. For all you know, the harmless-looking function is >>> monkey-patching builtins like there's no tomorrow. Speaking broadly, >>> perhaps too broadly, we're incredibly proud of the ability to modify nearly >>> everything at runtime. >>> Fortunately, while we are proud of having that ability, actually *using* it >>> is considered a mortal sin. We're not Ruby developers -- if you actually >>> monkey-patch something, especially built-ins, you can expect to be taken >>> outside and slapped around with a fish if you get caught. >> Here's what I don't get. >> If it's such a bad thing, *why is it allowed*? Why are you proud of the >> ability to do something that you are never socially-allowed to do? > Monkey-patching built-ins would be something along the lines of > import sys > sys.modules['__builtin__'].str = my_super_string > and is what stands you in jeopardy of being fish-slapped. ;) > Merely shadowing a built-in, or stdlib, or whatever, isn't monkey-patching. Oh, I know. I was just noticing that Steven's post is specifically talking about how Python users are proud of having the ability to monkey-patch. If monkey-patching like that is a mortal sin, leads to fish-slapping, and so on.. Why is it possible? Why not just reject such things as invalid code? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico wrote: > On Wed, Aug 17, 2011 at 5:33 PM, Seebs wrote: >> If it's such a bad thing, *why is it allowed*? ?Why are you proud of the >> ability to do something that you are never socially-allowed to do? > Going back to my original three examples: I may have been unclear about jumping topics; that comment was about monkey-patching, not about shadowing. > I greatly prefer this to the alternative, which is another 133 > reserved words (based on Python 3.2 for Windows). You have a point there. I guess I'm just used to the assumption that the confusion caused by shadowing names outweighs the benefits of using them -- the world is rich with plausible names. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Ethan Furman wrote: > Part of the fun of Python is experimentation. And how much fun is it to > be told over and over, "No, you can't do that"? Okay, I buy that. Actually, this sort of fits with my experience of how (sane) people do it in Ruby. And I'm really the wrong person to criticize people for monkey-patching: http://www.yoctoproject.org/projects/pseudo (In which I monkeypatch *the entire Unix filesystem API*. On Linux and OS X. For C programs.) I guess maybe my question shouldn't have been "why is it allowed", but "and why is it bad to use it?" It just seemed like "you should never do this, it's horrible" and "we're proud of being able to do this" were not entirely compatible. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: List spam
On 2011-08-18, Prasad, Ramit wrote: >>> Or 'Enter a Python keyword (search the tutorial if you do not know any) >>> ' >> >>Sounds good, but now you've trained the spammer who is without a doubt >>watching this list. > > Teach them Python before they can post, I like it! I don't. If I want to get started in a language, I might well want to read about it a bit, and maybe ask questions like "what is a good book for me to start with?" If I have to know the language to do that, well... -s -- Copyright 2011, 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: Word Perfect integration
On 2011-08-18, Ethan Furman wrote: > Yes, we still use Word Perfect, and will as long as it is available. > The ability to see the codes in use (bold, margins, columns, etc) has so > far been unequaled in anything else I have looked at. I have used other software that had this functionality, but not so much lately. (Although it appears that PageStream still does this, which is totally of relevance to someone, I'm sure.) But yeah, that was an AMAZING feature, and not having it is one of the reasons I'm so often unable to get things done in MS Word. Sadly, Corel dropped Mac and Linux support, and I don't do real work on Windows, so WP has been off my list for a long time now. :( -s -- Copyright 2011, 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: try... except with unknown error types
On 2011-08-19, Steven D'Aprano wrote: > Even if you don't think it's the ethical thing to do, consider that someday > you might be maintaining code written by the OP :) A common further conclusion people reach is "but then I will be able to get a job fixing it!" Trust me, this is NOT where you want to go. :) -s -- Copyright 2011, 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: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
On 2011-08-21, Andreas L?scher wrote: > Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith: >> In article , >> Christian Heimes wrote: >> > I don't think that's the reason. Modern compiles turn a switch statement >> > into a jump or branch table rather than a linear search like chained >> > elif statements. >> This is true even for very small values of "modern". I remember the >> Unix v6 C compiler (circa 1977) was able to do this. > What is the difference in speed between a jump table that is searched > from top to bottom A jump table isn't searched, it's jumped into. You don't look through the table for a matching element, you grab the Nth element of the table. -s -- Copyright 2011, 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: is there any principle when writing python function
On 2011-08-23, smith jack wrote: > i have heard that function invocation in python is expensive, but make > lots of functions are a good design habit in many other languages, so > is there any principle when writing python function? Lots of them. None of them have to do with performance. > for example, how many lines should form a function? Between zero (which has to be written "pass") and a few hundred. Usually closer to the lower end of that range. Occasionally outside it. Which is to say: This is the wrong question. Let us give you the two laws of software optimization. Law #1: Don't do it. If you try to optimize stuff, you will waste a ton of time doing things that, it turns out, are unimportant. Law #2: (Experts only.) Don't do it yet. You don't know enough to "optimize" this yet. Write something that does what it is supposed to do and which you understand clearly. See how it looks. If it looks like it is running well enough, STOP. You are done. Now, if it is too slow, and you are running it on real data, NOW it is time to think about why it is slow. And the solution there is not to read abstract theories about your language, but to profile it -- actually time execution and find out where the time goes. I've been writing code, and making it faster, for some longish period of time. I have not yet ever in any language found cause to worry about function call overhead. -s -- Copyright 2011, 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: truncating strings
On 2011-08-23, Roy Smith wrote:
> I want to log a string but only the first bunch of it, and add "..."
> to the end if it got truncated. This certainly works:
> logger.error("FAILED: '%s{50}', '%s', %s, %s" % (message,
> route, params, e.code))
> does anything like this exist?
%.50s
-s
--
Copyright 2011, 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: truncating strings
On 2011-08-23, Ethan Furman wrote:
> Seebs wrote:
>> On 2011-08-23, Roy Smith wrote:
>>> logger.error("FAILED: '%s{50}', '%s', %s, %s" % (message,
>>> route, params, e.code))
>>> does anything like this exist?
>> %.50s
> That's not working in 2.7 or 3.2.
Huh.
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print "%.5s" % ("hello there, truncate me!")
hello
-s
--
Copyright 2011, 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: truncating strings
On 2011-08-23, Ethan Furman wrote: > Ah -- that's only part of it -- the OP wants '...' to print as well. :) O. Hmm. That's harder. I can't think of a pretty way, so I think I'd probably write a "prettytrunc(string, len)" or something similar. -s -- Copyright 2011, 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: A tale of yak shaving
On 2011-08-29, Steven D'Aprano wrote: > This is not exactly fresh (it was written back in March), but it's the first > time I saw it and I thought I'd share. Barry Warsaw, one of the lead Python > developers, describes one of his most ... interesting ... debugging > experiences. That is a truly excellent debugging story. I also like the term "yak shaving", and I suspect I'll be using that for future such endeavors. Of which there are a fair number in my line of work. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-31, Chris Torek wrote: > (I realize this thread is old. I have been away for a few weeks. > I read through the whole thread, though, and did not see anyone > bring up this one particular point: there is already a linting > script that handles this.) Yes. I've found pylint... A weird mix of "very helpful, thanks" and "oh, come off it". A thread about pylint is where I got my example of the natural Python way to express a parabola: theValueRepresentingTheYAxisLocationOfThePoint = theValueRepresentingTheXAxisLocationOfThe Point * theValueRepresentingTheXAxisLocationOfThe Point I still say that there are times when short names are natural and idiomatic, and much clearer than long names. :P But I do think that, given the basic assumption that pylint is a core tool for vetting code, it is probably adequate for it to provide the warnings. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't threading.join() return a value?
On 2011-09-02, Steven D'Aprano wrote: > Roy Smith wrote: >> I have a function I want to run in a thread and return a value. It >> seems like the most obvious way to do this is to have my target >> function return the value, the Thread object stash that someplace, and >> return it as the return value for join(). >> Yes, I know there's other ways for a thread to return values (pass the >> target a queue, for example), but making the return value of the >> target function available would have been the most convenient. I'm >> curious why threading wasn't implemented this way. > Because then the code launching the thread would have to block, waiting > until the thread is completed, so it will have a result to return. Isn't "waiting until the thread is completed" sort of the point of join()? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: What was your strategy?
On 2010-11-14, Jorge Biquez wrote: > I was wondering if you can share what was the strategy you followed > to master Python (Yes I know I have to work hard study and practice a > lot). I mean did you use special books, special sites, a plan to > learn each subject in a special way. I would like to know, if > possible, comments specially from some of you who in the past had > other languages, frameworks and platforms and left (almost) all of > them and stayed with Python. I've been learning Python the same way I learn any language; get a book, read it over lunch for a few days, start typing, ask people how to improve my code once I have some. This information is almost certainly useless to you, though, unless you've already learned at least six or seven programming languages. -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: C interpreter in Lisp/scheme/python
On 2010-07-15, bolega wrote: > This makes some sense. He replied on the newsgroup in a lengthy post > that there are sufficient resources out there giving hint that no one > need help me out. Then I was called "lazy" in one email and tersely > given JUST the last name of an author who has many books each many > 100s pages, when I asked for a relevant book, as if i am a scholar in > the field, although he did spend lots of words on irrelevant and > unbeneficial things which diminished my enthusiasm. If you found those "irrelevant and unbeneficial", then while I agree that he may have been wasting his time, he would have been wasting it even worse trying to walk you through the technical material when you're clearly not currently at a stage where you are ready to learn anyway. > Now, I find out > from you that he has/had a business concern or interest in a company > that is writing/wrote lisp interpreter in C. Correct me if I am making > an error. I dont want to think deprecatingly of any good soul but this > is what i experienced. If you are trying to imply that he was acting in some unethical way, you have further cemented the notion that trying to talk to you is a waste of anyone's time. *plonk* -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! -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-18, Steven D'Aprano wrote: > On Fri, 17 Sep 2010 16:01:54 -0400, Andreas Waldenburger wrote: >> On Thu, 16 Sep 2010 16:20:33 -0400 AK 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 2010-09-18, AK 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 2010-09-19, AK 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 2010-09-19, AK 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 War&Peace"; - 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 2010-09-19, Steven D'Aprano 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 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 2010-09-19, AK 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 2010-09-19, AK 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 else ", 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 time: I am no
Re: Too much code - slicing
On 2010-09-19, MRAB wrote: > On 19/09/2010 22:32, Seebs wrote: >> On 2010-09-19, AK 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 "ifelse", 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: if else The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when 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 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
On 2010-09-20, alex23 wrote: > AK 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
On 2010-09-20, John Bokma 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: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Steven D'Aprano wrote: > On Sun, 19 Sep 2010 06:16:49 -0700, Aahz wrote: >> Please don't use tinyurl -- it's opaque and provides zero help to anyone >> who might later want to look it up (and also no accessibility if tinyurl >> ever goes down). At the very least, include the original URL for >> reference. > Do you have something against tinyurl in particular, or would any URL > shortener service also get your ire? I'd assume all of them have the same essential problems: * No hint as to what site you'll be getting redirected to. * No cues from URL as to what the link is to. * If the service ever goes away, the links become pure noise. -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-20, John Bokma 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: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Tim Harig wrote: > On 2010-09-20, Seebs wrote: >> * No hint as to what site you'll be getting redirected to. > Tinyurl, in particular, allows you to preview the url if you choose to do > so. Other URL shortning services have a similar feature. I have no idea how. If I see a "tinyurl" URL, and I paste it into a browser, last I tried it, I ended up on whatever page it redirected to. >> * No cues from URL as to what the link is to. > Same point as above. Same solution. I'm not reading news in a web browser. I don't want to have to cut and paste and go look at a page in order to determine whether I want to switch to my browser. >> * If the service ever goes away, the links become pure noise. > This happens a lot on the web anyway. True. > Do you have any idea how many > pieces of free software are first hosted on university servers to > disappear when the author graduates/moves to another school or free > shared host servers that have to be moved due to lack of scalability? > Sourceforge solved much of this problem; but, then if sourceforge should > ever disappear, all of its links will be pure noise as well. This is true. But two points of failure strikes me as worse than one. :) > The simple fact is that the Internet changes. It changed before URL > shortening services came into the mainstream and it will be true long > after they have left. Oh, certainly. I'm not particularly convinced that these are *significant* complaints about URL-shorteners. But I will say, of the last couple hundred links I've followed from Usenet posts, precisely zero of them were through URL redirectors. If I can't at least look at the URL to get some initial impression of what it's a link to, I'm not going to the trouble of swapping to a web browser to find out. -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: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Tim Harig wrote: > 1. Don't bother to manually paste when you can use something like urlview > to lauch directly. I don't know that this would actually be better than what I currently do, which is grab text and middle-click in another window. > If you want this behavior by default, you can easily wrap urlview > to automatically add the prefix. True, but since my news reading is not on the machine my web browser is on, it seems like it might get annoying. > I question first whether most tinyurl links are really of such an > intransient nature that they need to be long lasting. I personally use > them most when writing paper notes. They only need to last long enough > for me, or whoever I made the note for, to get back to them. By default, I assume that Usenet posts are for the longer term, and a Usenet post which relies for its content on tinyurl is thus somewhat more vulnerable than one which doesn't. In particular, consider things like archive.org; they may well be able to find a long-dead web page, but not a long-dead tinyurl link. > This is academic as tinyurl addresses cannot be changed; but, it > does point out that simple logic such as two points of failure must be > worse then one isn't always correct. Not always correct, but I think it is in this case. > But why should the rest of us be penalized because you make the choice > not to use (or not take full advantage of) all of the tools that are > available to you? For about the same reason that I should be penalized because someone else wanted things done differently. Which is to say, it's a tradeoff, the right choice to make depends on what your goals are. If you want a piece of information to have maximal longevity, something like tinyurl is probably a bad way to transmit it. If you want something small that survives line wrapping, it's probably a good way. FWIW, the browsers I use automatically Do The Right Thing if you paste in a multiline URL. -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] Speed-reading [was Re: Too much code - slicing]
On 2010-09-20, Steven D'Aprano 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 wrote:
> On Sun, 19 Sep 2010 07:36:11 +0000, 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
Re: Down with tinyurl! (was Re: importing excel data into a python matrix?)
On 2010-09-20, Tim Harig wrote: > You could simply place the filter in slrn; then, any urls that you see in > your reader would already be shown with the preview prefix suitable for cut > and paste mechanisms. If you wanted, you can even have your script > download the preview and automatically convert it back to the full > origional URL. This would require me to do a lot more work. :) > I assume just the opposite. Once the post has been removed from the > server, it is gone to me. I am not fond of the various archives that are > otherwise available on the web. Huh. I find the old usenet archives amusing, at the very least, and often very informative. > No, I tend to think is is much better that posts simply expire by > their use by date. I prefer data to be around as long as possible, since it at least potentially reduces effort. > If this was something that was forced upon you, then I might have some > sympathy; however, I see it as the poster's right to do what he thinks will > make his post more effective. I agree. On the other hand, many people are simply unaware of some of the reasons for which tinyurl and the like can make their message less effective to at least some users, so mentioning this to them may be useful. In theory, you have the right to indent your Python code however you want. In practice, if you don't use four spaces, you'll run into various problems interoperating with other people. Telling people this if they don't know it or are ignoring it is probably useful, even though ultimately the decision remains up to them... -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-20, Antoon Pardon 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 2010-09-21, 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. 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: Down with tinyurl! (was Re: importing excel data into a pythonmatrix?)
On 2010-09-21, geremy condra wrote: > I use them when I want to conceal the target of the link. Usually here > that just means its a letmegooglethatforyou.com link, which I find > more amusing than is probably healthy. I thought the idea was funny at first. Then I posted a question on an IRC channel. I had done a ton of searching already, and I started by explaining the top three near-solutions I'd found and why each of them wasn't actually a solution to my problem. And someone handed me a URL... which was to lmgtfy on the first search terms I tried. And this caused me to realize just how amazingly insulting that can be when done to someone who *did* already do the research. While certainly there's plenty of people who didn't do their own searching, there's also a fair number who are asking a question because they DID try searching and there was some problem with one or more of the answers. -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: Down with tinyurl! (was Re: importing excel data into a pythonmatrix?)
On 2010-09-21, Steven D'Aprano wrote: > On Tue, 21 Sep 2010 03:01:53 +0000, Seebs wrote: >> On 2010-09-21, geremy condra wrote: >> Then I posted a question on an IRC channel. I had done a ton of >> searching already, and I started by explaining the top three >> near-solutions I'd found and why each of them wasn't actually a solution >> to my problem. And someone handed me a URL... which was to lmgtfy on >> the first search terms I tried. > Yes, although in fairness people aren't mind readers. If you (generic > you) don't give any indication of doing the research, you can expect to > be ignored or told to RTFM. Google is just the new FM. See above -- "I started by explaining..." > Although sometimes people genuinely don't know what search terms they > should be using, or if they're too generic. Yes. A few of my friends periodically ask me to search for something because somehow my pick of search terms tends to work better than theirs. We're not actually sure why. -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: Down with tinyurl! (was Re: importing excel data into a pythonmatrix?)
On 2010-09-21, Steven D'Aprano wrote: > Yes, I know that. I sympathized with your experience and explicitly said > I was talking about "generic you". Hah! Then it was *I* who wasn't reading carefully enough! I bet you didn't expect *THAT*! -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too much code - slicing
On 2010-09-23, Steven D'Aprano 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 2010-09-23, Steven D'Aprano wrote: > On Thu, 23 Sep 2010 01:49:44 +0000, 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
On 2010-09-23, John Bokma wrote: > Seebs 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: Check whether file is being written to
On 2010-09-23, loial wrote: > How can I check whether a file is being written to by another process > before I access it? You mean "written to" or "open for possible writing"? It may be possible (with sufficient privileges) to determine that a file has been opened for writing. I don't think you can detect being-written-to. More importantly, though, the question is irrelevant, because even if you absolutely, conclusively, prove that a file is not open nor being written to, before your next machine instruction loads, the file could be opened and rewritten multiple times by whole new processes that weren't even running when you checked. I suggest you look into advisory locks. -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-23, Andreas Waldenburger wrote: > On 23 Sep 2010 03:54:52 GMT Seebs 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: sequence multiplied by -1
On 2010-09-26, Steven D'Aprano wrote:
> On Sat, 25 Sep 2010 23:46:57 -0700, Paul Rubin wrote:
>> I think the idea is you should not be able to do mathematical operations
>> on strings, and if you try to do one, Python should raise an exception,
>> rather than using hokey analogies to guess at what you were trying to
>> do. If you want to replicate a sequence, introduce a function with a
>> name like "replicate", rather than overloading an arithmetic operator.
> But * isn't a mathematical operation on sequences. It's a repetition
> operator.
I think Paul's point is that "*" is in general a mathematical operation,
and discovering that for some types of objects, it's been given a
fundamentally unrelated meaning can certainly be a bit of a surprise.
I actually sort of like that perl has a separate repetition operator.
And really, when you find yourself saying something nice about perl's
syntax or punctuation, that's always scary territory to be in.
> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",
> and the fact that it doesn't do the same thing as int("spam")*3 is a
> foolish argument.
The languages in which it's surprising are mostly things like perl, where
there's a certain amount of implicit coercion going on, so it's ambiguous
whether "3"*3 ought to mean "333" or 9. (Except it isn't, because repetition
is a separate operator, written "3" x 3 rather than "3" * 3...) People
coming from that kind of background may be expecting * to stay an
arithmetic operator, rather than having it change form when applied to
non-arithmetic objects.
I'm not sure either way. I think on the whole, I like the notion of
a repetition operator which is distinct from multiplication, but I also
definitely prefer the lack of implicit coercion, and without implicit
coercion, there's a lot less underlying ambiguity to worry about.
>From the top, I guess my analysis is:
* It seems clear that, given two sequences x and y, "x + y" ought to
be the concatenation of these sequences.
* Thus, "x + x" should be x concatenated to itself.
* Idiomatically, it is not unreasonable to assert that "x * 2" and "x + x"
could be the same value.
* It thus makes some sense for * to indicate
repetition of the sequence.
* Since a string is a kind of a sequence, it also makes sense for
* to indicate repetition.
So I think I'm pretty much convinced that Python's behavior makes sense,
but it makes sense only because I'm going into this expecting operators
to be defined by types, so I don't expect every '*' to mean 'multiplication'.
Helps, perhaps, that I got exposed to group theory early enough to be used
to redefining + and * to be any two operations which have interesting
properties*.
-s
[*] What's purple and commutes? An abelian grape.
--
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: toy list processing problem: collect similar terms
On 2010-09-26, Xah Lee wrote: > On Sep 25, 11:17??pm, Paul Rubin wrote: >> Python solution follows (earlier one with an error cancelled). ??All >> crossposting removed since crossposting is a standard trolling tactic. > btw, i disagree about your remark on crossposting. You're wrong. Crossposting is indeed a standard trolling tactic. This does not prove that all crossposters are trolls, nor does it assert that all crossposters are trolls, but it is absolutely factually correct that it's a standard trolling tactic. -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: toy list processing problem: collect similar terms
On 2010-09-26, J?rgen Exner wrote: > It was livibetter who without any motivation or reasoning posted Python > code in CLPM. Not exactly; he posted it in a crossposted thread, which happened to include CLPM and other groups, including comp.lang.python. It is quite possible that he didn't know about the crossposting. However, while I would agree that this would constitute a form of ignorance, I'd think that, especially with how well some newsreading interfaces hide that detail, I don't think it's really worth getting angry over. -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: toy list processing problem: collect similar terms
On 2010-09-28, John Bokma wrote: > Seebs writes: >> On 2010-09-26, J?rgen Exner wrote: >>> It was livibetter who without any motivation or reasoning posted Python >>> code in CLPM. >> Not exactly; he posted it in a crossposted thread, which happened to include >> CLPM and other groups, including comp.lang.python. >> It is quite possible that he didn't know about the crossposting. > Oh, he does. It has been Xah's game for years. But did "livibetter" know about it? I wasn't defending Xah, who is indeed at the very least clueless and disruptive. But I was sort of defending the poster who was accused of posting Python code in CLPM, because that poster may not have understood the game. -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: function decorators
On 2010-09-28, Nick Donohue wrote: > why would I use these? wouldn't it be more flexible to not write the > decorator before the function definition, so I could choose to wrap it > or not? The utility is that it lets you modify all calls to a function at once, without changing all the instances in a ton of source code. -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: partial sums problem
On 2010-09-28, Gary Herron wrote: > Python does have "s+=t" as a statement, and it does have list > comprehensions [... for ...] as expressions, but you cannot put a > statement inside an expression. I've inferred that, in Python, all assignments are by definition statements, rather than expressions, so they can't be arbitrarily substituted in for expressions. It's interesting to see the two ways in which people seem to go from C's middle ground of expressions and statements; some languages go to making statements into expressions, others go for even further narrowing the set of "expressions". I'm not yet sure which I prefer; both have some appeal in avoiding some of the occasional-complexity that can make C hard for people to learn. (Meaning, complexity which is only sometimes at issue, so you have to know about it, but you can't just use it all the time, so you can't assume it's how things work.) -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
