Re: allow line break at operators
On Sep 3, 11:50 am, Stephen Hansen me+list/pyt...@ixokai.io wrote: Freedom is not and never has been, IMHO, a virtue or goal or even desire in Python. Exactly! Where it occurs, it is at best a happy coincidence, Exactly! and even if that happy coincidence happens often, it is not a design feature, IMHO. Exactly! Actually i believe Python allows TOO many freedoms and indulges TOO many excesses to the detriment of our code bases. Take the fact that both tabs AND spaces are legal in Python source. We should have choose one over the other! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sep 4, 10:22 am, ron3200 ron3...@gmail.com wrote: I think this is one of those areas where computers and people differ, but it may also depend on the persons native language as to what works better for them. Yes but what works better for them is not always a better way of doing things! People do foolish things all the time just from pure habit. A foolish consistency is a foolish consistency my friend. I mean, look at the folks who popped their cherry writing Basic code; talk about dysfunctional! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 16, 2:37 pm, rantingrick rantingr...@gmail.com wrote: The reading proceeds naturally from right to left. Well, naturally if you're coding in Hebrew or Japanese perhaps :) -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 16, 1:49 am, alex23 wuwe...@gmail.com wrote:
On Aug 16, 2:37 pm, rantingrick rantingr...@gmail.com wrote:
The reading proceeds naturally from right to left.
Well, naturally if you're coding in Hebrew or Japanese perhaps :)
Yes :). I typo-ed that one. It was getting late when i sent that
reply. I did consider posting an edit however i decided not to and
instead, wait and see who would notice.
The map feels much better too as a consequence:
rb [3,100,-20].map{|x| x.to_f}
[3.0, 100.0, -20.0]
And you can can induce some logic without a clunky lambda.
rb[3,100,-20].map{|x| if x 99 then x.to_f else x end}
[3.0, 100.0, -20.0]
in Python you'd have to create a def for that (i know bad specific
example but the need is there)
It feels just like a Python list comprehension though:
py [float(x) for x in [3,100,-20]]
Even though it reads in a non-linear way, you could argue that the
most important part (float(x)). is front-and-center. Of course i like
the compactness of python's map function:
py map(float, [3,100,-20])
But all too often the map function is insufficient AND you cannot use
map in a chain! If only we could find a happy medium between Python
and Ruby oh what a bliss that would be. We could cut off all of
Pythons warts and destroy all of Rubys multiplicity and singular
paridigm-ness.
* Forced indention (exactly one tab, and one tab only!)
* No multiplicity!
* Nice linear expressions!
* Name spaces!
* Implicit modules!
* Only truly heterogeneous built-in functions allowed!
* Enough freedom to be expressive, but not enough to allow sloppy-
ness.
--
http://mail.python.org/mailman/listinfo/python-list
RE: allow line break at operators
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. What exactly is the downside to indentation as flow control? I am a fairly new programmer to Python, but the more I use it, the more I think it has the Right idea (for me at least). I find braces in Java/c[#,++] to be less than helpful in comparison to how people rave over. It allows for free form code sure, but half the time I was using indentation to figure out where conditional branching/loops started and stopped anyway! I will admit it was super useful in helping Eclipse to reformat with a more readable indentation. The only difference is that now it forces me to make more readable code instead of allowing me the freedom to make hard to read code. I suppose as an American I should be insulted at the lack of freedom. Hell, I own Apple products; I must be getting indoctrinated into a lack of freedom. :-P I am not being vehement or hostile. At least I am attempting to be neither. I do not really feel emotionally invested in either because honestly, I will do whatever I have to for what I am trying to get done. If that requires me coding while only wearing hot pink or using braces I will do it. I am far more concerned with ease of coding, ability to do what I want, and occasionally (fairly rarely) if the running code will be fast enough. 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. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
RE: allow line break at operators
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? Rantingrick: Do answer his question, please. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Tue, Aug 16, 2011 at 8:26 PM, Prasad, Ramit
ramit.pra...@jpmorgan.com wrote:
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.
I'm one of the fans of braces, but search the list archives and you'll
find plenty of arguments on both sides. I like braces because they
allow me to separate the syntax from the layout; I can choose to
indent things based on logical structure, even when that doesn't
correspond to the compiler's notion of the structure. Here's an
example from C++:
struct _blah
{
int x;
int y;
char **z;
//etc etc etc
}; struct blah: public _blah {
char padding[1024-sizeof(_blah)];
};
The inheritance isn't significant to the overall concept of the object
(the idea was that it should have a size of exactly 1024, as this had
to interface with some lower-level systems), but it's significant to
the compiler's understanding of the object. The braces, therefore,
follow the compiler's requirements, but the indentation follows the
programmer's. (And yes, there were comments explaining things, and
much better element names.)
Another idiom I often use in C or C++ is the conditional for loop:
for (x=getfirst();x;x=getnext()) if (x%3)
{
blah
blah
}
The equivalent in Python:
for x in blah: if x%3:
blah
blah
is not legal, and must be written with an extra indentation:
for x in blah:
if x%3:
blah
blah
I'm sure I could sort something out with a filtering generator, but it
seems ridiculous to write:
def condition(gen,func):
for elem in gen:
if func(elem): yield elem
for x in condition(blah,lambda x: x%3):
blah
blah
There are very good reasons for Python's system, and I don't object to
it *in Python*. But I do not see indentation-as-structure as the
ultimate and perfect system, and I desire and intend to preserve the
freedom to choose languages with different systems.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Prasad, Ramit ramit.pra...@jpmorgan.com 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: allow line break at operators
On 8/15/2011 12:28 AM, Seebs wrote: To repeat again: you are free to put in explicit dedent markers that will let you re-indent code should all indents be removed. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 5:28 AM, Seebs usenet-nos...@seebs.net wrote:
Character stream: tab tab tab foo newline tab bar. This is, as you
say, *usually* two dedents, but it could be one.
I see your point, though I cannot imagine anyone who would use tab
tab as an indent level. But if you go from 16 spaces down to 8, it's
possible that the script uses eight space indents, or four.
On Mon, Aug 15, 2011 at 8:31 AM, Terry Reedy tjre...@udel.edu wrote:
To repeat again: you are free to put in explicit dedent markers that will
let you re-indent code should all indents be removed.
This would be a solution to the above, but it has the feeling of
syntactic salt. (I don't believe that braces are, because they afford
a different form of flexibility.) But sure, if you configure your
editor to do it for you.
I type: if (blah):
It puts:
if (blah):
|
# if
with the cursor at the | marker. I never really got used to editors
doing this for me, though. It didn't feel right. I prefer an editor
that deals with my indentation but lets me do the rest; when I hit
enter, it autoindents to either the current indent level or one
greater, depending on whether it looks like there ought to be an
indent (which mainly happens when I put a loose { on a line).
Similarly, when I put a } into the file, it removes an indent level
automatically.
Still, it wouldn't be hard to make an editor put those dedent comments
in, if you want them.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 14, 2011 3:24 PM, Seebs usenet-nos...@seebs.net wrote: ... 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. If you have valid code caused by improper indentation, shouldn't that be caught by a good set of unit tests? -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 08/14/2011 11:28 PM, 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 like the one-liner, this is readily written as
, .join(block(x) for x in sorted(foo.array_of_things))
Modulo your gripes about string.join(), this is about as succinct
(and more readable, IMHO) as your initial example. I've got
piles of these sorts of things in my ETL code.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico ros...@gmail.com writes: Why is left-to-right inherently more logical than multiplication-before-addition? Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? 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'm a clearly a fool for allowing myself to be drawn into this thread, but I've been playing a lot recently with the APL-derivative language J, which uses a right-to-left operator precendence rule. Pragmatically, this is because J defines roughly a bajillion operators, and it would be impossible to remember the precendence of them all, but it makes sense in its own way. If you read 3 * 10 + 7, using right-to-left, you get three times something. Then you read more and you get three times (ten plus something). And finally, you get 3*(10+7). The prefix gives the continuation for the rest of the calculation; no matter what you substitute for X in 3*X, you will always just evaluate X, then multply it by 3. Likewise, for 3*10+X, no matter what X is, you know you'll add 10 and multiply by 3. This took me a while to get used to, but it's definitely a nice property. Not much to do with python, but I do like the syntax enough that I've implemented my own toy evaluator for J-like expressions in python, to get around the verbosity of some bits of numpy. Regards, Johann -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
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)])
Or if you prefer map:
, .join(map(block, sorted(foo.array_of_things))
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 ,
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.2233.1313179799.1164.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Python uses the + and - symbols to mean addition
and subtraction for good reason. Let's not alienate the mathematical
mind by violating this rule.
Computer programming languages follow math conventions only in the most
vague ways. For example, standard math usage dictates that addition is
commutative. While this is true for adding integers, it's certainly not
true for adding strings (in any language which supports string addition).
Where to draw the line between math and programming languages is not an
easy question.
It would be far safer to go the other way
and demand parentheses on everything.
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 2:41 PM, Roy Smith r...@panix.com 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.
Understandable. I go the other way, though, and keep an operator
precedence table for each language handy; often, what I'm after is not
which one binds more tightly, but what's the symbol for modulo,
which is also (usually) on that same table. Or: Blasted PHP, which
operators have precedence between || and or? which is easy to forget.
And you're right about the details changing from language to language,
hence the operators table *for each language*. But most languages
follow fairly sane rules, and tend to come up with pretty much the
same ordering.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Roy Smith wrote: Computer programming languages follow math conventions only in the most vague ways. For example, standard math usage dictates that addition is commutative. While this is true for adding integers, it's certainly not true for adding strings (in any language which supports string addition). Not quite true for maths either, at least in principle. I'm not aware of any number types where addition is non-commutative, but subtraction is noncommutative even for integers, and noncommutative multiplication is quite common (e.g. matrix multiplication). And of course, once you start using floating point numbers, you can't assume commutativity: 0.1 + 0.7 + 0.3 == 0.3 + 0.7 + 0.1 False 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. (And don't even ask about the sedenions...) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 3:28 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
And of course, once you start using floating point numbers, you can't assume
commutativity:
0.1 + 0.7 + 0.3 == 0.3 + 0.7 + 0.1
False
This isn't because programming languages fail to follow mathematics;
it's because floating point numbers do not represent real numbers.
Python doesn't support substring removal using the subtraction
operator, but I'd have to say that floats more closely parallel
strings and other high level objects than they do mathematical reals.
If Python treated __sub__(str,str) as str.replace(str,) then:
hello world + asdfqwer - d
hello worlasfqwer
hello world - d + asdfqwer
hello worlasdfqwer
Nobody would expect strings to behave mathematically with subtraction,
because negatives don't make sense. Even sets don't quite work,
although they're closer:
set(asdf)-set(test)
{'a', 'd', 'f'}
There's no way, in a set, to show a negative reference to 't' and 'e'.
In theory you could do this with dictionaries or collections.Counter,
but subtracting a Counter from a Counter doesn't produce negative
numbers either. No, these constructs do not subtract algebraically,
and I do not think it would be any improvement to the language if they
did.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 r...@panix.com 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: allow line break at operators
On Aug 15, 2:31 am, Terry Reedy tjre...@udel.edu wrote: On 8/15/2011 12:28 AM, Seebs wrote: To repeat again: you are free to put in explicit dedent markers that will let you re-indent code should all indents be removed. As Terry has been trying to say for a while now, use the following methods to quell your eye pain. Use pass statement: if foo: if bar: baz else: pass else: quux Use comments: if foo: if bar: baz #else bar (or endif or whatever you like) else: quux Use road signs: :-) # [Warning: Curves Ahead: Eyeball Parse limit 35 WPM!] if foo: # [Exit 266: foo] -- # [Right Curve Ahead: slow eyeball parsing to 15 WPM!] if bar: baz else: pass # -- [Warning: Do not litter!] else: # [Exit 267: Not Foo] -- # [Right Curve Ahead: slow eyeball parsing to 15 WPM!] quux ... # [Eyeball Parse limit 55 WPM!] ... # [PSA: Friends don't let friends write asinine code] ... # [Next Rest Stop: NEVER!] Now you have the nice triangular shape that your eyes have been trained to recognize! I would suggest to use comments whenever possible. Of course there will be times when you cannot use a comment and must use an else clause. Now you have nothing to complain about :). -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.10.1313417818.27778.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Or: Blasted PHP, which operators have precedence between || and or? which is easy to forget. And you're right about the details changing from language to language, hence the operators table *for each language*. But most languages follow fairly sane rules How dare you use the words PHP and sane in two adjoining paragraphs! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article 4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Tue, Aug 16, 2011 at 1:34 AM, Roy Smith r...@panix.com wrote: In article mailman.10.1313417818.27778.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Or: Blasted PHP, which operators have precedence between || and or? which is easy to forget. And you're right about the details changing from language to language, hence the operators table *for each language*. But most languages follow fairly sane rules How dare you use the words PHP and sane in two adjoining paragraphs! By separating them with the word most. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano wrote: I'm reminded of this quote from John Baez: ...But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. (And don't even ask about the sedenions...) Aren't they the ones that mutilate cattle and abduct people? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Roy Smith r...@panix.com wrote: In article 4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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: allow line break at operators
* 2011-08-14T01:44:05-07:00 * Chris Rebert wrote: I've heard that Dylan is supposedly Lisp, sans parens. http://en.wikipedia.org/wiki/Dylan_(programming_language) It has copied/derived many features from Lisps but it's not a dialect of Lisp because of the syntax and its consequences. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 15, 11:13 pm, alex23 wuwe...@gmail.com wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
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 ,
I've seen at least one attempt to provide this in Python:
If you want 100% OOP then use Ruby:
rb [3,100,-20].sort.join('#')
-20#3#100
Ruby is great from this angle! The reading proceeds naturally from
right to left. I have become accustomed to reading Python's nested
function calls however it does feel much more natural in Ruby. Of
course, there are architectural reasons why Python cannot do this
linear syntactical processing which lends some paradigm-al niceties to
the python programmer that are not available to the Ruby folks.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
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 } 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. 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? 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. 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. Yes, sorry about that. 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. 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* 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. And you can nest arrays: c = array 5, 6, array 7, 8, 9, Now, I wouldn't actually recommend such a syntax for a programming language. (Maybe for a config file format?) It's too big and awkward for array literals in an expression. You can partly fix that by making the whitespace optional, allowing an array to be written on one line: a = array 1, 2 b = array 3, 4 but that screws up the ability to nest arrays. Also, what happens here? spam(a, b, array 5, 6) That's ambiguous -- does spam have three arguments or four? Again, easy enough to fix: spam(a; b; array 5; 6) # four args 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. 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. 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). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 mind as much, but the kinds of errors I've had would probably still be issues. 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. To some extent, I think I like braces for the same reason I like to use ECC memory whenever hardware supports it, and
Re: allow line break at operators
On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: 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* You wait for the house lights to come up. That's your ending signal. As is often said in live theatre: House lights, warmers, thank you gentlemen, going off cans! It still has an end marker. On Sun, Aug 14, 2011 at 9:07 AM, Seebs usenet-nos...@seebs.net wrote: 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.) 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. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sun, Aug 14, 2011 at 1:34 AM, Chris Angelico ros...@gmail.com wrote: snip 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. I've heard that Dylan is supposedly Lisp, sans parens. http://en.wikipedia.org/wiki/Dylan_(programming_language) Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: 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.) It has long been recognised as a wart, but it required waiting for an opportunity for breaking backward compatibility (the Python 2 → 3 transition) to fix it. If you can't yet switch to Python 3, you can explicitly ask for ‘print’ as a function in Python 2.6 or later. More at URL:http://wiki.python.org/moin/PrintAsFunction. -- \ “The generation of random numbers is too important to be left | `\to chance.” —Robert R. Coveyou | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico ros...@gmail.com writes: On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: 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? You wait for the house lights to come up. That's your ending signal. You mean people still watch movies in theatres? The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
* 2011-08-14T09:34:26+01:00 * Chris Angelico wrote: 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. Of course it's a useful feature. Basically you can put any Lisp code in the world in the place of a Lisp expression. (setf variable (handler-case (some-code) (foo-error () value 1) (bar-error () value 2))) is something like variable = try: return some_code() except FooError: return value 1 except BarError: return value 2 Sure, it's not a necessary feature. All we need is the machine language, but other than that there are differences in how languages let programmers express themselves. The above example emphasizes that 'variable' is being assigned. The how part gets less weight. If we put the assignment inside the handler-case or try-except forms we get the same result technically but the variable assignment becomes more hidden and is repeated, possibly several times. 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. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Ben Finney wrote: Chris Angelico ros...@gmail.com writes: On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: 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? You wait for the house lights to come up. That's your ending signal. You mean people still watch movies in theatres? Yup! Not often, but it's fun once in a while. The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? If it's a tape, it'll stop, or start rewinding; if it's a DVD it'll go back to the open page. :) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
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.
Whoops.
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.
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.
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 :)
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.)
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.
The way I see it, if something operates by side-effect, then it has no
business being treated as an expression. I'm not even happy with the usual
convention of Python functions that return None, such as list.sort() -- in
my opinion, languages should have procedures which don't return anything,
and can only be used as a statement, similar to Pascal procedures.
(I'm prepared to make an exception for purely functional languages.)
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.
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.
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. There are real-world scenarios involving such semantic errors involving
indentation, but they're pretty rare. I think that six weeks of not having
to type { } or BEGIN END around code blocks has saved far more time and
effort than such errors have cost me in my entire history of Python
programming.
Refactoring C or Ruby is easy for me. Refactoring Python is hard for me.
I really do rely on visible markers to sanity-check the boundaries of what
I'm indenting or outdenting. If I do something in my editor and end up
with:
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? What makes you so certain that next_thing and something else are
supposed to be inside the loop? They don't even refer to bar. Even if they
did, it's not a foolproof sign, although it is a good hint.
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.
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.
Please don't take this as an insult, because it is not meant as one, but it
seems to me from this discussion that you're a more careless coder than I
am[1], and you want more insurance to protect you from your own mistakes.
Braces give you that insurance.
I'm not saying I've never mis-indented a block of code, surely I must have.
But if I did, it was so trivial to fix, and done so rarely, I've forgotten
all about it. Consequently I don't want to pay the cost of that insurance,
as little as it is, because I don't get the benefit of it -- for me, it's
just redundant information that I have to type and read that provides no
real benefit.
And that's why I love Python, because it doesn't make my pay for insurance I
don't need.
[1] For some definition of careless.
--
Steven
--
Re: allow line break at operators
On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
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.
The way I see it, if something operates by side-effect, then it has no
business being treated as an expression.
Wikipedia (that well-known authority) lists among examples of side
effects both write data to a display or file and modify one of its
arguments.
This strongly implies that print() is a function that operates by
side-effect, just as the assignment operator (in languages in which it
is one) does. Treating a=5 as an expression with the value 5 is no
more relying on side effects than having print('asdf') an expression
with the value None.
I believe that print-as-a-function is a Good Thing, mainly because it
can be used as an argument to such as map. Somewhat silly/trivial
example:
msgs=[Hello,World]
list(map(print,msgs))
I'm aware that assignment-as-an-expression has plenty of risks
associated with it (the main one being the classic C issue of
assignment inside a conditional - a feature that I use frequently
myself, but which trips plenty of people up), which is a strong
argument for its remaining a statement, but side effects isn't on its
own.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article 4e47db26$0$30002$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: 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. URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico wrote: On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: 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. The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Wikipedia (that well-known authority) lists among examples of side effects both write data to a display or file and modify one of its arguments. [...] Good point. I withdraw my statement about things that operate about side-effects. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Chris Angelico ros...@gmail.com 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 steve+comp.lang.pyt...@pearwood.info 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 constantly.) Please don't take this as an insult, because it is not meant as one, but it seems to me from this discussion that you're a more careless coder than I am[1], and you want more insurance to protect you from your own mistakes. Braces give you that insurance. I have really, really, bad ADHD. When I was a kid a firecracker blew up in my hand because I *forgot* I was holding it. I'm not exactly careless in the pejorative sense (I don't accept the
Re: allow line break at operators
On 2011-08-14, Teemu Likonen tliko...@iki.fi 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: allow line break at operators
On Sun, Aug 14, 2011 at 10:27 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? If you're watching it from your own media, you'll come to the end of the file/DVD/whatever and VLC will know. End-of-file is a well-known condition with well-defined semantics. :) And in the theatre, there's a definition of the end based on the origin of the material (the stage manager's script/music score, or something). Yep, there's always an end marker somewhere. But we are now hopelessly off topic, I think! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: allow line break at operators
On 01/-10/-28163 02:59 PM, Roy Smith wrote: In article4e47db26$0$30002$c3e8da3$54964...@news.astraweb.com, Steven D'Apranosteve+comp.lang.pyt...@pearwood.info wrote: 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. URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. And the same page hosted on Linux would be case sensitive, per specification. The thing I find annoying is a host that decides that if a URL is close to an existing URL, it'll fix one or two typos. To me, it's either right, or it's not. Don't change www.mydomain.com/page105.html to www/mydomain.com/page102.html and pretend it's close enough. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.2285.1313358379.1164.python-l...@python.org, Dave Angel da...@ieee.org wrote: URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. Sure. But it's only in the most trivial of situations that URLs map in any trivial way to file names. And the same page hosted on Linux would be case sensitive, per specification. Well, I certainly could write an HTTP server on Linux which treated routes in a case-insensitive way. For example, if I do a GET on http://en.wikipedia.org/wiki/hypertext, I get redirected to http://en.wikipedia.org/wiki/Hypertext. On the other hand, http://en.wikipedia.org/WIKI/Hypertext gets me a 404. It's entirely up to the server to do whatever makes sense for that application. The thing I find annoying is a host that decides that if a URL is close to an existing URL, it'll fix one or two typos. To me, it's either right, or it's not. Don't change www.mydomain.com/page105.html to www/mydomain.com/page102.html and pretend it's close enough. Hosts don't decide anything. Applications running on those hosts decide things. Without knowing the application, it's impossible to say if this is the right thing to do or not. For example, it's good practice that if a URL ever worked in the past, you should keep that URL working, even if it becomes obsolete. You might want to silently return some other page, or redirect the user to some other URL. This keeps bookmarks, existing links, cached search results, etc, from going stale. To use the wikipedia example again, there are lots of redirect entries, for other (perhaps incorrect) spellings, and so forth. For example, http://en.wikipedia.org/w/index.php?title=Tabouleredirect=no -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sun, Aug 14, 2011 at 11:46 PM, Roy Smith r...@panix.com wrote: In article mailman.2285.1313358379.1164.python-l...@python.org, Dave Angel da...@ieee.org wrote: The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. Sure. But it's only in the most trivial of situations that URLs map in any trivial way to file names. And even then, it plays havoc with caches (both browser and proxy), which have no way of knowing that http://blah.com/Foo.html and http://blah.com/foo.html are the same document. (It's not hard to set up a Windows system to be case sensitive with URLs, or (even easier - at least with Apache) to have any request with uppercase letters to instantly redirect to the lower-cased version.) URLs are definitely case sensitive; any server that ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs wrote: On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Which I later withdrew. 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'. 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 feel your pain. But not all typos are equivalent. There are typos in the content of the document you are editing, and command typos. There's nothing an editor can do to prevent the first -- how is the editor supposed to know that you meant referrer rather than referer? And because it didn't, now we're stuck with a %*$%@! spelling error forever. 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: http://www.asktog.com/columns/027InterfacesThatKill.html http://www.useit.com/alertbox/20050411.html If your editor doesn't help you minimise bad commands, then your editor doesn't work for you, it works against you. 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. I sympathise, but don't care. That's your problem man, not Python's. Python has a design philosophy that doesn't match your needs precisely. Oh well, no language can be all things to all people. If you try, you get Perl, and you still fail, because your language doesn't meet the needs of people looking for something that isn't Perl *wink* 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. 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. 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. 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. 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. 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. Okay, now I'm confused... if indentation doesn't matter, how is the end misaligned? You could write this, and it would still work the same, yes? foo.each do |bar| bar.do_a_thing do_something_with(bar) end next_thing something else 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. But if indentation doesn't matter, you can't screw it up. Isn't that the whole point of this discussion? [...] You keep telling me to stop using this editor. I have not seen a
Re: allow line break at operators
On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: snip 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'. Not in the specific case of fluent interfaces[1] though, which could have been what Seebach had in mind. Whether fluent interfaces are a good idea... Cheers, Chris -- [1] http://en.wikipedia.org/wiki/Fluent_interface -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 discussion? I think there is some
Re: allow line break at operators
On 2011-08-15, Chris Rebert c...@rebertia.com wrote:
On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. Fortran 77 used to treat whitespace as always optional, so that in Python terms this: forxinrange(42) would be parsed as this: for x in range(42) Absolutely true, and that led to one of the more famous computing screw-ups in the early space program. The author intended to write this: DO 10 I=1,8 which, in Fortran, begins a loop that will run 8 times ending at the statement labeled 10. In this case, the author mistakenly typed a period instead of a comma: DO 10 I=1.8 That, unfortunately, is a perfectly valid statement that assigns the value 1.8 to the floating point variable DO10I, supposedly resulting in the loss of an unmanned launch vehicle... -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 5:03 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
Responding to Rick's standard {EDIT} posts
is like wrestling with a {EDIT}
[...]
Save yourself a lot of aggravation and kill-file him now.
Kindly allow Walter E. Kurtz to shine some light on this situation:
Pig after pig, cow after cow, village after village, army after
army. And they call me an assassin. What do you call it when the
assassins accuse the assassin? They lie.. they lie and we have to be
merciful for those who lie. Those nabobs. I hate them. How I hate
them...
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: 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. For me, i believe it was a grave mistake to allow user defined indention within a python module. Not only that, but allowing indentation to be inconsistent (within the same module) not only worse, it's insane! I could have slightly understood giving people a choice of how many indents to use however i cannot fathom the idiocy of allowing inconsistent indentation within the same module! Although GvR is no doubt a brilliant mind he keeps making the same mistakes over and over again in the name of muti-stylism. ¡Ay, caramba! Not that i find it *impossible* to read inconsistent indentation mind you, but that i find it blasphemous to the name of consistency. Programming languages MUST be consistent. Python should allow one and only one obvious way to indent a block; whether it be by a single tab char or by four spaces i don't care! But for crikey's sake pick one of them and stick with it!!! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: I was overjoyed when I saw that Ruby would let me write 1_048_576. I'll have to admit that Ruby has a few very interesting ideas, this being one of them. We all know how impossible it can be to eyeball parse a very long number like this. Having the interpretor ignore underscores in a number was very wise indeed! However i really hate the fact that Ruby FORCES you to use OOP. I LOVE OOP, however there are times when you just don't need that level of machinery to solve a problem. A good example is when scripting an API. Most times all you need is a few module level procedures and some simple logic. Try that with Ruby, then try that with Python, you'll be switching to Python in no time! PS: And before any Matz lovers start complaining: Yes, i know you can do procedural programming with ruby HOWEVER it suffers many pitfall due to (1) Ruby's scoping issues and (2) Ruby's explicit module declaration (which is more indirect than the first). -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: 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. It almost seems as if you have a valid point here until you consider that conditionals and blocks are ridged structures that must be defined under a strict set of syntactical rules with keywords and indentation. Whereas the list, dict, set, and tuple absolutely MUST have an explicit beginning AND an explicit end due to their free-form nature. You could create some strict rules for defining X-literals and remove any need for start and end tags however i see no need to do so. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 4:06 pm, Seebs usenet-nos...@seebs.net wrote: On 2011-08-12, Chris Angelico ros...@gmail.com 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. And repeatedly propagating a foolish consistency is well, FOOLISH! This problem invades every aspect of technology. Who was the idiot that decided it was okay to close SOME html tag and NOT close others? Since HTML is made to be read by machines why the hell would someone knowingly induce disorder? Which then leads to needing more logic to parse? But even more insane is why HTML has been allowed to be so disorderly for so long. Where is the need to be consistent? I tell you how to solve this, you solve it with plagues. Plagues of syntax errors will teach the unrighteous the err of their ways. -- 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 et...@stoneleaf.us 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 language
Re: allow line break at operators
On Fri, Aug 12, 2011 at 2:40 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Please be careful about conflating significant indentation with significant whitespace. Many languages have significant whitespace: foo bar is rarely the same thing as foobar but is the same as foo bar Python is no different. Of course. But most languages derived from C have a single lexer token whitespace. That one token is significant, but these are all the same: foo bar foo bar foo bar foo/* this one wasn't originally the same*/bar Python handles differently source files that differ only in whitespace. It's not only indentation; newlines are whitespace too, and they're significant. In C-derived languages, it's only presence-or-absence. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 7:34 AM, Seebs usenet-nos...@seebs.net wrote: If Python with braces wouldn't be Python at all, why on earth does the language even exist? Every language has its philosophy. Python, as conceived by Guido van Rossum, is a language which (guys, correct me where I'm wrong please!): * Eschews unnecessary syntactic salt * Has batteries included * Has a clean and readable syntax To achieve this, Python: * Uses indentation and other whitespace as structural elements (rather than semicolons, braces, etc) * Has a large standard library and an enormous PyPI collection * Uses keywords (and, or, not, if/else) rather than symbols (, |, !, ?:) for common tasks 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. Pike is very similar to Python in underlying structure. You can pass lists and dictionaries (called arrays and mappings) around as first-class objects, you can reference objects in multiple places, you can work with huge integers comfortably. But they're different in philosophy. Pike's purpose is primarily zero-downtime servers; I can (and do on a daily basis) update parts of the code of a running program, without disconnecting clients. Python doesn't do this, and to make Python do this would violate a lot of its simplicities and underlying referencings. It can be done without modifying the interpreter, but it's never been designed in. If you want that feature, you go to Pike; if you want Python's syntax, you go to Python. I hope I make myself clear, Josephine? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: On 2011-08-11, Ben Finney ben+pyt...@benfinney.id.au wrote: 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 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. 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. 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. 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. 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. In Python, I maintain that's the case for “end of line as end of statement”, and for “indentation as block structure”. -- \ “A computer once beat me at chess, but it was no match for me | `\ at kick boxing.” —Emo Philips | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
:The trouble of dealing with long lines can be avoided by a smart :editor. It's called line wrap. Yeah, usually they just wrap it pretty arbitrarily, and you don't have any control, isn't it? :umm... besides notepad pretty much any other serious programmer editor :program try to do its best to deal with line wrap: the minimal I found is :the wrapped line is indented at the same level of the flow, but I found :editors where you can specify what to do (generally something like indent :the wrapped part 2 levels or something like that) Thanks for sharing that, which I am not quite aware of . BTW, do you think things like eclipse, emacs and vim also has such kind of functionality? Best of all, would certainly like to have IDLE have it, as I am teaching Python and would like to get them to start with a simple environment. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
From: Vito 'ZeD' De Tullio zak.mc.kra...@libero.it :umm... besides notepad pretty much any other serious programmer editor :program try to do its best to deal with line wrap: the minimal I found is :the wrapped line is indented at the same level of the flow, but I found :editors where you can specify what to do (generally something like indent :the wrapped part 2 levels or something like that) Well, even if one editor can do perfect line wrapping, breaking the line at places perfectly pleasing to the eye (put aside the fact that sometimes the line breaking could be based on the meaning of the code), it is unlikely to be cross-editor consistent. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net 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? The correct comparison would be “getting the braces to match the intended structure” compared with “getting the indentation to match the intended structure”. 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... 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? If so, good for you; we're all equally dogmatic by your definition. Let's move on. If not, what makes your position less dogmatic than ours? -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Ben Finney wrote: Likewise, “end of line as end of statement” has caused me and many others problems. I don't understand this. Can you give an example? Do you mean, Sometimes I want more code in a single statement than will comfortably fit in a single line? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: Ben Finney wrote: Likewise, “end of line as end of statement” has caused me and many others problems. I don't understand this. Can you give an example? Many times I have split a line expecting that some bracketing syntax will cause the statement to continue across the split. I've been wrong, and the code either gave a SyntaxError or, worse, did something functional but unintended. That is a problem only because end-of-line (outside some bracketing syntax) ends a statement. My point is that I consider that problem to be at least on par in the severity of the problems caused by indentation-as-block-syntax. That is, very small compared with the great benefit of the clean and readable syntax that results. -- \ “Not to be absolutely certain is, I think, one of the essential | `\ things in rationality.” —Bertrand Russell | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Incidentally, I will happily argue the benefits of Python's significant whitespace, even though I disagree with it; there are quite a few. Please be careful about conflating significant indentation with significant whitespace. Many languages have significant whitespace: foo bar is rarely the same thing as foobar but is the same as foo bar Python is no different. The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. Early versions of Basic were like this, too. It was common to compress large C64 Basic programs by removing the spaces and substituting the command synonyms. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Am 12.08.2011 03:40 schrieb Steven D'Aprano: The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. ATARI 800XL. Built-in BASIC, acknowledging every command with READY. Going over it with the cursor results in ERROR- 6, meaning no READ without DATA... same as READ Y. Thomas, it was a long time ago... -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 1:34 am, Seebs usenet-nos...@seebs.net wrote: 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*. What is with you guys and this need to have your hand held to read code. Out-dents are noise and nothing more. 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? 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. In other language communities, when I find things about the language troublesome, I usually find people offering suggestions for ways to improve things, or workarounds, or acknowledging that, yes, that can be annoying. But for some reason, in this one, that's apparently against a local taboo. So instead of acknowledging that it is conceivably possible for people to prefer different things, people say things like oh, once you've done it a bit you'll realize how much better it is and then you'll love it. Condescending, smug, and, at least so far, *totally untrue* for me. Well for indention there is no alternatives. There is either indent/ dendent, or suffer the syntax error. I am also weirded out by the claim that a Python which used braces would no longer be Python in any way, shape, or form. If you were to make a C derivative which used indentation instead of braces (this should be trivial to do with a preprocessor), I can't imagine C programmers claiming it's not C. Of course it's C; it has the C type system, the C operators, the C promotion rules, C linkage and scope and so on... That's C. It's just a C variant which tweaks the punctuation. 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! 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. If Python with braces wouldn't be Python at all, why on earth does the language even exist? If all you want is indentation-which-matters, it's super easy to write a preprocessor for ANY language to do that, and you could have every last positive feature, benefit, or valuable trait of Python by doing that to any other language. 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. Unless, of course, there are *other* things that are significant about Python. In which case, a language which preserved all of those, but used braces, would still be a kind of Python after all. 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! Long story short: I think the dismissiveness and hostility I've seen from people in the Python community towards people who, for *whatever* reason, find the indentation-flow-control thing annoying, is not really helping the Python community win converts. 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. Indentation is at the very heart of Pythons philosophy. A philosophy that breaks free from decades old language design build on the detrimental ideals of multi- stylism. Good languages do not care about your singularly instinctual emotion needs for bondage, no, they care about productivity and readability from a community perspective. PS: I will admit that a few of our community members can be rather acerbic at times. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 2:20 am, Chris Angelico ros...@gmail.com wrote: Pike is very [snip] Pike's purpose is [snip] you go to Pike[snip] I hope I make myself clear, Josephine? The only thing that is clear to me is that you have a hidden agenda to incorporate pike's functionality into Python -- and this is not the first time! Chris, this incessant babbling about pike this and pike that is starting to get on my nerves. Why don't you go over to comp.lang.pike and gush to them about how wonderful the language is. PS: Although i give you brownie point for sucking up to GvR and the community at large before hinting about Esox lucius greatness. Nice! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 3:39 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net 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? The correct comparison would be “getting the braces to match the intended structure” compared with “getting the indentation to match the intended structure”. One argument I've heard from braces fans is that sometimes they want their own structure, which does not match the actual block structure. 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). Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net 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 ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net 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 ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 7:34 AM, Seebs usenet-nos...@seebs.net 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 rantingr...@gmail.com 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 Aug 12, 11:33 am, Seebs usenet-nos...@seebs.net 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 are clutching the past and it is taking you down with it. Pry your lips from Ritchie's left teet and stop slurping that brace milk; because it is polluting your mind! 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. 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. 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! 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. I would even go as far to use a special set of brackets for linear calculations before using only one, or playing the precedence game. 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? I am not trying to discredit you simply by disagreeing with you. 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Rebert c...@rebertia.com 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 Fri, Aug 12, 2011 at 4:33 PM, rantingrick rantingr...@gmail.com wrote: On Aug 12, 2:20 am, Chris Angelico ros...@gmail.com wrote: Pike is very [snip] Pike's purpose is [snip] you go to Pike[snip] I hope I make myself clear, Josephine? The only thing that is clear to me is that you have a hidden agenda to incorporate pike's functionality into Python -- and this is not the first time! Chris, this incessant babbling about pike this and pike that is starting to get on my nerves. Why don't you go over to comp.lang.pike and gush to them about how wonderful the language is. Yeah, it's something I've mentioned a few times. I think people have mentioned C on this list a few times, too; also lisp. Of course, since this is the Python mailing list (or newsgroup, depending where you read it), we aren't allowed to mention any other languages at all. Mea culpa. I'm not seeking to add Pike's functionality into Python. I want the two languages to be different, and I want the world to have different languages. Diversity and choice promote quality in ways that you don't seem to understand. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 5:33 PM, Seebs usenet-nos...@seebs.net 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 :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 6:57 PM, rantingrick rantingr...@gmail.com wrote: 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! Why is left-to-right inherently more logical than multiplication-before-addition? Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico wrote: 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. Argh! ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 1:09 PM, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 6:57 PM, rantingrick rantingr...@gmail.com wrote: 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! Why is left-to-right inherently more logical than multiplication-before-addition? Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? 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. Left-to-right is more logical because that is the choice made by the English language (which I will note, we are using right now). Also, ignoring operator precedence, left-to-right is the way math equations evaluate. See 4 / 2 * 3 - you get 6, not (2/3) and not (3/2). Now, I would not suggest changing the multiplication before addition rule, for the very reason you mention: in many cases, the established rule is expected, but that does not mean it is more logical. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Angelico ros...@gmail.com 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 rantingr...@gmail.com wrote: On Aug 12, 11:33?am, Seebs usenet-nos...@seebs.net 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 ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 5:33 PM, Seebs usenet-nos...@seebs.net 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
Seebs wrote: On 2011-08-12, rantingrick rantingr...@gmail.com 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. 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: On 2011-08-12, rantingrick rantingr...@gmail.com 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. Please be aware that the particular person to whom you're responding is decidedly not part of the helpful and welcoming community here. 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? If you're interested, check the forum's archives for a thorough history of what the helpful and welcoming community say about him. You'll find we pretty much agree with your assessment. -- \ “Generally speaking, the errors in religion are dangerous; | `\those in philosophy only ridiculous.” —David Hume, _A Treatise | _o__) of Human Nature_, 1739 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
Seebs usenet-nos...@seebs.net writes: 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. :) Much appreciated, thank you :-) -- \ “It is well to remember that the entire universe, with one | `\ trifling exception, is composed of others.” —John Andrew Holmes | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
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. Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream. 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. (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.) 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. And it really is intuitive[1]: http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html Historically, nearly all languages with braces pre-date the widespread adoption of tools that think they can mangle whitespace with impunity. (I would say that the reasons that the tools are broken is *because* programmers have trained themselves to think that whitespace doesn't matter -- ask most writers or artists and they would say *of course* whitespace matters. The separation between elements is important -- perhaps not quite as important as the elements themselves, but still important.) Explicit BEGIN/END tokens exist to make the job of the parser easier, not that of the programmer. 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. [1] For some definition of intuition. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 11:39 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: ask most writers or artists and they would say *of course* whitespace matters. You can write Perl code in the shape of a camel. Can you do that in Python? Okay. Open challenge to anyone. Write a Python script that outputs Just another Python hacker or some such message, and is shaped in some way appropriately. And no fair doing all the shaping in comments :) (Has it already been done?) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico ros...@gmail.com writes: On Fri, Aug 12, 2011 at 11:39 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: ask most writers or artists and they would say *of course* whitespace matters. You can write Perl code in the shape of a camel. Can you do that in Python? I'm glad to be using a language where that sort of hard to-read code is not encouraged by the syntax. Art is wonderful, if you don't want to communicate clearly. I'll thank the people who write the programs in my life to save their artistic expression for areas where clear communication is optional. -- \ “My business is to teach my aspirations to conform themselves | `\ to fact, not to try and make facts harmonise with my | _o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 08/12/2011 05:50 PM, Chris Angelico wrote: You can write Perl code in the shape of a camel. Can you do that in Python? Okay. Open challenge to anyone. Write a Python script that outputs Just another Python hacker or some such message, and is shaped in some way appropriately. And no fair doing all the shaping in comments Okay, my entry: print(Just another Python hacker) That lovely one-line shape resembles a straight narrow snake ;-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 8/12/2011 6:14 PM, Seebs wrote: I am responding to your whole line of posts. 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. 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. I said that over a decade when this same discussion took place, and I say it now. Different brains are different. I do not care which of us is in the majority in which population. As I and others also pointed out over a decade ago, anyone is free to add insignificant comment braces (but keep that private, please) or, more sensibly, commented dedents to help the reader keep track of indent level. for... for ... if ... for ... if ... [50 more lines of code] #end outer if [more code] -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 120.) -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 tjre...@udel.edu 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
Seebs usenet-nos...@seebs.net writes: What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? See URL:http://docs.python.org/reference/lexical_analysis.html for a comprehensive discussion of the lexing done on Python source. To examine the resulting code objects, see the ‘dis’ module in the standard library URL:http://docs.python.org/library/dis.html. -- \ “[T]he question of whether machines can think … is about as | `\ relevant as the question of whether submarines can swim.” | _o__) —Edsger W. Dijkstra | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico wrote: But both of these violate XKCD 859. For the benefit of all those who just went off to read that strip, here's something to help you unwind: ) There, you can relax now. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-13, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? See URL: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: allow line break at operators
Seebs usenet-nos...@seebs.net writes:
On 2011-08-10, Ben Finney ben+pyt...@benfinney.id.au wrote:
Seebs usenet-nos...@seebs.net writes:
On 2011-08-10, Chris Angelico ros...@gmail.com 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.
What evidence do you have of these? The latter, especially, seems to be
mere opinion unfounded in any measurement.
3. There is a HUGE degree of emotional investment in defending it.
That same observation is consistent with:
* Indentation as block syntax is an excellent idea.
* Python programmers are quite consciously aware of this.
So I don't see a reason to prefer your inference over mine.
The responses I have seen on this issue are highly emotional, full of
insults, full of blame-throwing
Again, I don't know where you've been observing that, but it's not what
I've seen.
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.
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.
Since that latter set of people includes most Python programmers who
have reacted negatively to the proposal, you may want to re-think
whether your effort is worthwhile. Meanwhile, we'll continue being
productive with Python's indentation-as-structure.
--
\ “If nature has made any one thing less susceptible than all |
`\others of exclusive property, it is the action of the thinking |
_o__) power called an idea” —Thomas Jefferson, 1813-08-13 |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
