Re: seeking deeper (language theory) reason behind Python design choice
On Sun, May 13, 2018 at 2:31 PM, Python wrote: > On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote: >> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano >> > If all programmers were as awesome as you and never made typos, the world >> > would be a better place. But we know from experience that even >> > experienced C programmers can make this mistake by accident. >> >> Yes, and I'd go further: I *am* too stupid to get this right. > > No, you are not. Do you ever say "dog" when you mean "dot" instead? > Do you ever say "dad" when you mean "mom" instead? Internalize that > "=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to" > then use those phrases in your head when you're thinking about which > one you need in your code, and I'm pretty sure you'll stop making this > mistake. It may help that the phrase with twice as many syllables > represents the operator that has twice as many characters. Eventually > it becomes second nature, like not calling Dad "Mom." Rght, of course. Because prevention of bugs is just a matter of wanting to. You remind me of a previous boss of mine, who didn't understand why debugging ever had to happen - he thought that if the programmers he employed would just take a bit more care, they could write perfect code. And commits like this never happen: https://github.com/Rosuav/MustardMine/commit/ca0b1f47b2fe4438caea549410e1f1296798ba56 Let me break it to you gently: you are flat out wrong. Yep, that's as gentle as I can make it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote: > On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano > > If all programmers were as awesome as you and never made typos, the world > > would be a better place. But we know from experience that even > > experienced C programmers can make this mistake by accident. > > Yes, and I'd go further: I *am* too stupid to get this right. No, you are not. Do you ever say "dog" when you mean "dot" instead? Do you ever say "dad" when you mean "mom" instead? Internalize that "=" is "equals" (or "assigns" if you prefer) and "==" is "is equal to" then use those phrases in your head when you're thinking about which one you need in your code, and I'm pretty sure you'll stop making this mistake. It may help that the phrase with twice as many syllables represents the operator that has twice as many characters. Eventually it becomes second nature, like not calling Dad "Mom." -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Wed, May 09, 2018 at 05:44:57AM +, Steven D'Aprano wrote: > > On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote: > >> Currently, the real reason is that lambda expressions are limited to a > >> single expression as the body of the function, and binding operations > >> in Python are statements. > > > > ...which begs the question, why shouldn't assignments be expressions, as > > they are in many other languages? TBH this is one of the few things > > about Python that I dislike. > > No, it raises the question :-) Begging the question means to assume the > answer to the same question you are asking. In formal logic perhaps, but not in colloquial speech. Search google for "beg the question"--what it will give you is exactly how I used it. [The question is begged for on account of being the obvious question to ask...] > As Chris already pointed out, there is a PEP in progress at the moment > aimed at allowing assignment expressions (PEP 572). It is very > controversial, but Guido appears to be in favour of it (as I am, although > not necessarily in its current form). Well, obviously I'm a fan of the idea... > If all programmers were as awesome as you and never made typos, the world > would be a better place. HA! I make plenty of mistakes, but I think it's fair to say that when most reasonably competent programmers have a bit of experience under their belt, some bug or other has bitten them enough as fledgelings that they become paranoid about it and just never do it again. It does seem that for many of my contemporaries, this is one of those... When I took C ages ago the text I used had a "pitfalls" section at the end of every major section, and this was one of the items it mentioned. I do think having been exposed to those ideas so early greatly benefieted me in this regard, and I've found it sorely lacking in many programming texts I've read in the many years since. Perhaps an insufficient focus on programming pitfalls in modern programs is the reason we're in this mess... -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Sun, May 13, 2018 at 01:01:04PM +1000, Chris Angelico wrote: > That's fine. Your experience has been that it hasn't been a problem; > other people's experience has been the opposite. I have never > personally had to deal with bugs in C code where braces are omitted > and multiple lines indented. Great! But that doesn't mean it's not a > problem, or at least a risk. Every line of code you write is a risk, regardless of whether it's in a class of some language designer's hated constructs, or not... until your code is thoroughly tested. [And even then...] > Guido has firmly stated that this is not going to happen in Python. > The '=' operator is NOT going to become an expression. You may as well > stop posting about it, because it's not going to change. I'm well aware of this too, but I don't think that precludes reasoned discussion of whether or not the construct is deserving of its most hated status. A large portion of what is discussed in this forum is philosophical, and entirely unpractical. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
Drat, missed the main point I wanted to address in my last post: On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote: > > This example also is a case FOR allowing assignments to be > > expressions. If Python allowed them, you could rewrite this as: > > > >while not (flag = we_are_done()): > > ... > > if error_occured(): > > break > >notify_user() > ># flag will be checked again later, perhaps for error reporting > > > > This COMPLETELY PREVENTS the spelling bug in the code above, since the > > assignment only happens in one place; and as a bonus it's less code. > > Or just use an IDE with variable name autocompletion. Every time, without fail? Probably not going to happen, no matter who you are. FWIW I *do* use an editor with autocompletion--I never use it because in the common case it's faster for me to just type whatever I'm typing. But this solution--dictating *how* people work, to overcome a limitation of the language--is a horrible one. Besides, your entire response missed the point completely.. All of the examples you "fixed" were just trivial academic examples designed to illustrate the problem. In real code, particularly in a complex project, the spelling bug is easier to cause and harder to find, and just rewriting your while loop probably won't do. My ultimate point was no matter what constructions you allow or don't allow, coders are human and they're gonna screw it up, and some of those mistakes will get past all of your well-intentioned bug traps. Protecting coders from themselves is not a good reason to exclude useful language constructs. It's a reason to have good coders, good process, and good testing. And if your code reviews won't catch well-known programming pitfalls, what good are they? -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Sun, May 13, 2018 at 12:42 PM, Python wrote: > On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote: >> On Tue, 8 May 2018 22:48:52 -0500, Python >> >if spam == arg: >> >> Mis-typing that as >> >> if spam = arg: >> >> IS the problem -- you've just changed the value bound to spam, and will >> then branch based upon the new value and not a comparison of values. > > Yes, I'm well aware. While I may have been momentarily confused about > the side effects question, if you read my post I was clearly not > confused about this. Nor do I think anyone else who pposted in the > thread needed it explained. > > Responding to this further would essentially just require me to > reiterate what I already wrote--I won't do that. I'll simply maintain > that in my rather lenghty experience, this mistake has actually been > rather rare and has to my knowledge *never* caused a support issue > requiring a bug fix to production code in projects I've been > associated with. It's a useful construction whose detriment has, IMO, > been completely overblown. > That's fine. Your experience has been that it hasn't been a problem; other people's experience has been the opposite. I have never personally had to deal with bugs in C code where braces are omitted and multiple lines indented. Great! But that doesn't mean it's not a problem, or at least a risk. Guido has firmly stated that this is not going to happen in Python. The '=' operator is NOT going to become an expression. You may as well stop posting about it, because it's not going to change. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote: > On Tue, May 8, 2018 at 9:48 PM, Python wrote: > > I'll give you an example that is both a case where Python's design > > choices make creating a bug easier, AND a case where allowing > > assignments to be expressions would save you. > > > > flag = we_are_done() > > while not flag: > > # do some stuff > > ... > > if error_occured(): > > break > > falg = we_are_done() > > notify_user() > ># flag will be checked again later, perhaps for error reporting > > while True: > if we_are_done(): > break > # do some stuff > ... > if error_occurred(): > break > notify_user() > > Fixed, using idiomatic Python and without needing to use assignment in > an expression. Two points: 1. I think the ensuing discussion clearly enough demonstrates that this isn't necessarily considered the most idiomatic Python. I would go so far as to say it demonstrates that there's no such thing in actuality, in that different "experts" will have different opinions about what is or is not Pythonic. 2. Even if there was a definitive standard as to what is or is not idiomatic Python, no one is required to write it or care about it, and I would estimate that the vast majority of people who write Python don't. People tend to use constructions they're familiar with and/or comfortable with, until they discover for themselves a reason not to. On Thu, May 10, 2018 at 08:38:39PM -0600, Ian Kelly wrote: > In what way does "while True" in the general case pretend to be an > infinite loop? The break / return is right there for anyone to see. It doesn't pretend at all, it simply is. Its loop condition is a constant which will require the loop to continue indefinitely--in the general case--without intervention from some other control feature, in the specific. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Wed, May 09, 2018 at 03:09:18PM +1000, Chris Angelico wrote: > On Wed, May 9, 2018 at 1:48 PM, Python wrote: [much snippage...] > > flag = (spam == arg) > > That's not "side effects only". Yeah, I'll chalk that up to posting too late in the evening after working too long a day... On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote: > On Tue, 8 May 2018 22:48:52 -0500, Python > >if spam == arg: > > Mis-typing that as > > if spam = arg: > > IS the problem -- you've just changed the value bound to spam, and will > then branch based upon the new value and not a comparison of values. Yes, I'm well aware. While I may have been momentarily confused about the side effects question, if you read my post I was clearly not confused about this. Nor do I think anyone else who pposted in the thread needed it explained. Responding to this further would essentially just require me to reiterate what I already wrote--I won't do that. I'll simply maintain that in my rather lenghty experience, this mistake has actually been rather rare and has to my knowledge *never* caused a support issue requiring a bug fix to production code in projects I've been associated with. It's a useful construction whose detriment has, IMO, been completely overblown. -- https://mail.python.org/mailman/listinfo/python-list
Re: Meaning of abbreviated terms
The "plist" abbreviation goes back to at least 1958 as it was used in the Lisp implementation [0]. And it may even predate Lisp. I'm very sure that what actually went into a plist has often changed over the years, but the name persists. Lisp also used "association lists" [1] which were a key/value data structure, usually called an "alist" or "a-list". Ross [0] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html [1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node153.html On 12/5/2561 BE 13:45, Bob Martin wrote: in 793617 20180511 072806 Steven D'Aprano wrote: On Fri, 11 May 2018 07:20:36 +, Bob Martin wrote: in 793605 20180511 044309 T Berger wrote: On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote: On 2018-05-05 17:57, T Berger wrote: What does the "p" in "plist" stand for? Is there a python glossary that spells out the meanings of abbreviated terms? "plist" is "property list". It's listed in the Python documentation. Thanks for the answer. Missed it till now. In IBM-speak it was parameter list. But that's not where plists came from, was it? As I understand it, the plist data format was invented by Apple, and they called it a property list. How old is Apple? I was using plist for parameter list in OS/360 in 1965. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Sat, May 12, 2018 at 5:38 PM, Ian Kelly wrote: > On Fri, May 11, 2018 at 5:26 PM, Mikhail V wrote: >> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: >>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: Do you understand that basically any python code sent by e-mail converts tabs to spaces, thus the only way to receive it - is to send binary file? >> So what is false? > > Your absurd assertion that the only way to safely email Python code is > as a binary file. Why you say so? You have agreed yourself with the assertion. Also I did not say "safe" but meant that I cannot receive the exact file in the body of e-mail in case of tabs. > no support for _fancy features_ like viewing tabs and spaces :\ is syntax highlighting fancy feature? >> Sorry, not sure what you mean. Do you propose _visible_ character >> instead of e.g. tab? But then you need to hide it to be able >> to read normally. > > Why would I need to hide the separator character in order to be able > to read the data? So you find e.g. this ok: →1 →→ 2 →→ 3 →→ 4 >> presentable to the reader. Initial idea is just use current >> Python syntax for further nesting: >> >> image === T/T: >> (127,127,127)(127,127,127)(127,127,127) >> (127,127,127)(127,127,127)(127,127,127) >> (127,127,127)(127,127,127)(127,127,127) >> >> vs: >> image = ( >> ((127,127,127), (127,127,127), (127,127,127),), >> ((127,127,127), (127,127,127), (127,127,127),), >> ((127,127,127), (127,127,127), (127,127,127),), >> ) > > And if you have more than three levels of nesting, and you don't > conveniently just have a bunch of 3-tuples that line up perfectly with > one another? Maybe you can come up with some example in current syntax? I have browsed some projects with a lot of resource definitions. sometimes it has 3-4 levels of nesting, and I have hard time understanding the structure - so maybe it is possible to simplify those according to this syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Fri, May 11, 2018 at 5:26 PM, Mikhail V wrote: > On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: >> On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: >>> Do you understand that basically any python code sent by e-mail converts >>> tabs to >>> spaces, thus the only way to receive it - is to send binary file? >> >> Um, no, this is false. We send Python code by email all the time. >> 1) Tabs as indentation: Python permits the use of both tabs and spaces > > This means if I paste some code _inside_ an existing block, > I get a Syntax error: > "TabError: inconsistent use of tabs and spaces in indentation" You can't generally paste code into other contexts and expect it to just work without any editing, for more reasons than the tabs / spaces issue. This doesn't have to do with emailing code. >> 3) Tabs that appear in strings: This one I'll grant you. > > This too. > > So what is false? Your absurd assertion that the only way to safely email Python code is as a binary file. >> In any case, the use of tabs is entirely optional. For the most part, >> programs can be safely emailed whether they contain tabs or not, the > > In real situation just send as attachment, with or without such > syntax, it will be > more polite and safe if you wish the person to run the program. > For some talks in email its not *far* worse than now. Note that this mailing list does not permit the use of attachments. Pastebin is fine, but for small snippets it's much simpler just to include them inline. >>> Yes, I have told already that there are _some_ cases when >>> tabulation formatting can cause visual confusion. >>> *But why do you blame me*? >>> It just the issues with editor's incompleteness. >> >> That's great, but if I'm editing a file on an embedded system over a >> serial port and the only editor I have available is nano, I should be >> able to use it. You can't just assume that everybody has a fully >> featured editor (and knows how to use it -- what was that point you >> made just above about beginners?) > > Wait, wait, wait - we are adult people - what problem causes nano? > I don't have nano so maybe you can tell what happens in nano if you > load for example a text file this: > > →a + b →→ a + b →→a + b →→a + b > →1 →→ 2 →→ 3 →→ 4 > →width:→→100% →→!important; > > In the above example one arrow → is one tab char. > What exact problem do you experience? I have no specific problems. It was just an example of a simple editor without support for fancy features like viewing tabs and spaces, in an environment where a more feature-rich editor may not be available. > I don't want spaces or tabs visible - there is toggle "show tabs" > and "toggle show space" for that > >> Needing to fiddle with editor settings in order to determine how the >> code in front of me that somebody else wrote is organized doesn't >> sound to me like a good feature. That sounds to me like poor >> readability. >> > > Sorry, not sure what you mean. Do you propose _visible_ character > instead of e.g. tab? But then you need to hide it to be able > to read normally. Why would I need to hide the separator character in order to be able to read the data? >>> "So the idea is to _hide brackets for_ first two levels of >>> nesting of course." >> >> In other words, this syntax is really not appropriate for more than >> two levels of nesting due to the mental gymnastics required to keep >> track of how the current level of nesting should be expressed. > > No. How you come up to this conclusion? > it is just not a trivial task to find an optimal solution to this - > on the one hand it must be feasible to parse, on the other hand > presentable to the reader. Initial idea is just use current > Python syntax for further nesting: > > image === T/T: > (127,127,127)(127,127,127)(127,127,127) > (127,127,127)(127,127,127)(127,127,127) > (127,127,127)(127,127,127)(127,127,127) > (127,127,127)(127,127,127)(127,127,127) > > vs: > > image = ( > ((127,127,127), (127,127,127), (127,127,127),), > ((127,127,127), (127,127,127), (127,127,127),), > ((127,127,127), (127,127,127), (127,127,127),), > ((127,127,127), (127,127,127), (127,127,127),), > ) And if you have more than three levels of nesting, and you don't conveniently just have a bunch of 3-tuples that line up perfectly with one another? > Seriously I find it quite an improvement both for > readability and type-ability. > I see you keep denying it for some unknown reason, > but well, its up to your conscience. I'm not sure what my conscience has to do with it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano wrote: > On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote: > >> it is just not a trivial task to find an optimal solution to this > > We already have an optimal solution to this. Yes. current syntax will not go anyway so proposal addresses cases where it is appropriate and clearly better. > > * It works with any editor, including simple ones. Ok > * It is safe for transmit over email, or on web forums, > so long as you avoid tabs and use spaces. I don't use spaces so I'm out of luck already. > * It is readable by humans without them needing to distinguish > between two different kinds of invisible space. I'm using tabs from childhood and don't find it a problem. > * It can be easily parsed by hand or by machine. Parsed by hand? > * It works with a multitude of text processing tools whether > or not they can cope with tabs. Ok. But this is bullet #1, see above, you repeat it > > * It is resistant to many sorts of typos. Here I think you oversimplify - In fact current syntax introduces typing problems in many cases: as a user with very high proficiency in typing and good sight, I have some trouble inputting nested bracketed arrays and spend some time trying to match corresponding suites. Plus the comma noise here, so your statement is too one-sided and overestimated. As said, I remember this and similar issues were raised on 'ideas' so don't pretend it does not exist. > > * It allows great flexibility in the presentation, you aren't > forced to lay things out in one specific 2D format. Only words - but nothing concrete > * It uses the same consistent rules for the rest of the language, > without adding special cases and complexity. I'll grant you for "special cases", but the rest is quite contradictive. As said, Python uses indented blocks - not bracketed blocks as in C. Python does not make semicolons mandatory. All this is a great improvement, but it seems you don't see the parallel here. > * It is a tried-and-true solution that has been used (with minor > modifications) for dozens, possibly hundreds, of programming > languages, natural language lists and data formats. > "natural language lists and data formats" OTOH all _real_ data list, tables, matrices do not include redundant commas, unless it is really needed. Any book, lectures, etc. presents them without commas so its second nature to any human to see it without commas and its just better so. M -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 12/05/2018 05:29, Steven D'Aprano wrote:
On Fri, 11 May 2018 16:56:09 +0100, bartc wrote:
0100, if not intended as octal, is
an undetectable error in C and Python 2.
How fortunate then that Python 2 is history (soon to be ancient history)
and people can use Python 3 where that error of judgement has been
rectified.
At least you're agreeing it was a mistake.
Although it does still mean that Python 3 has this funny quirk:
a = 0 # ok
a = 00123. # ok
a = int("00123")# ok
a = 00123 # error
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Sat, May 12, 2018 at 6:44 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> Tack setuid onto "owner", setgid onto "group", and sticky >> onto "others"? Pretty arbitrary, and disrupts the fundamental meaning >> of each set. > > > Yes, it would be totally silly if e.g. the "ls" command were > to regroup them that way when displaying the permission bits... > oh, wait... > > % echo > blarg.txt > % chmod blarg.txt > % ls -l blarg.txt > -rwsrwsrwt 1 greg staff 1 12 May 20:40 blarg.txt That's a hack to fit it into a fixed *display* width. And there are quite a few weirdnesses to make that work. Not something I would recommend except when, as here, backward compat is critical. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Marko Rauhamaa wrote: I'm guessing using letters as digits felt awkward among computer people for a long time. I think you may be underestimating how much weirdness early computer programmers were willing to accept. If you think using letters as hex digits is awkward, you should check out what EDSAC programmers had to put up with. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Chris Angelico wrote: Tack setuid onto "owner", setgid onto "group", and sticky onto "others"? Pretty arbitrary, and disrupts the fundamental meaning of each set. Yes, it would be totally silly if e.g. the "ls" command were to regroup them that way when displaying the permission bits... oh, wait... % echo > blarg.txt % chmod blarg.txt % ls -l blarg.txt -rwsrwsrwt 1 greg staff 1 12 May 20:40 blarg.txt -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Steven D'Aprano wrote: You had computers with 6, 9, or even 60 bits per byte, And some early machines were even weirder, e.g. the EDSAC with effectively 17-bit words and 35-bit longwords. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
