Re: Is this a bug or a feature in TkInter?
Found it! Thanks again :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a bug or a feature in TkInter?
Hi Terry, many thanks for your detailed explanation! (I can't see how to 'reply' under your post...) -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?
>
> def totally_not_a_generator(n):
> while True:
> if n % 2 == 0:
> n //= 2
> else:
> n = n * 3 + 1
> stealthily = n
> yield stealthily
> if n == 1:
> return n
>
> py> print(totally_not_a_generator(42)) # Lies!
>
Let's see. It's created with 'def'. It can be called by putting
parentheses after its name. Inside the parentheses, you can give it
parameters. When called, it returns a value. Hmm. Sure looks like a
function to me.
Tell me, which of these are functions and which are not?
def tnag5():
return totally_not_a_generator(5)
def tnag(n):
return iter(totally_not_a_generator(n))
def ILY():
return iter([1, 2, 3]) # your heart starts beating
async def what_about_me():
await spam()
return 42
def digits_to_number(text):
return int(text, 10)
class run_command:
"""Compatibility shim for older API"""
def __init__(self, *args):
proc = subprocess.run(*args, stdout=subprocess.PIPE)
self.rc = proc.returncode
self.output = proc.output
def run_command(*args):
proc = subprocess.run(*args, stdout=subprocess.PIPE)
return {"rc": proc.returncode, "output": proc.output}
The only one that inspect.isfunction() returns False for is the class,
and even that is a very function-like class. Every one of these is
callable and will return a useful value. Their headers announce one of
three things:
1) "I am a function" ==> def name(...):
2) "I am a factory for objects of my own type" ==> class name:
3) "I am a coroutine function" ==> async def name(...):
Not one of them is lying. And nor is your totally_not_a_generator. As
Steven said, it's a function, and it returns a value. That's not
materially different from ILY() in my example - it returns something
which you can iterate over.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 4:54 PM, Ian Kelly wrote: > On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano > wrote: >> To be honest, I'm having trouble thinking of a good use-case for "while >> True", now that we have infinite iterators. Most cases of >> >> while True: >> x = get_item() >> if not x: break >> process(x) >> >> are better written as: >> >> for x in iterator: >> process(x) > > x = get_item() > while True: > x = process(x) More likely: x = get_item() while x: process(x) x = get_item() which (a) repeats the call to get_item, (b) doesn't support the 'continue' statement, and (c) hides crucial loop iteration information at the BOTTOM of the loop. But to make this iterator, you need to separate the while loop's header from its body. Compare: while x := get_item(): process(x) def get_items(): while True: x = get_item() if not x: return yield x for x in get_items(): process(x) It hasn't actually gotten rid of the fib of the infinite loop; all it's done is wrap it up in a function. Yes, that can be of value; but adding another level of indirection doesn't solve a problem, it just moves it around. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 12:03 AM, Steven D'Aprano wrote: > On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote: > >> Would you also contend that generator functions are wrong because they >> pretend to be normal functions? > > You're going to need to be more specific. In what way are they not normal > functions? You call them like normal functions, providing arguments like > normal functions, and receiving a result just like normal functions. The way that they execute is not like a normal function. If you call one, having read the code but having failed to notice the 'yield', you will be confused by the result. Likewise, if you run a while True loop (or *any* loop, really), having read the code but failed to notice the 'break', you will be confused by the result. The point being that you cannot necessarily infer what a while loop will do just by reading the loop condition, any more than you can know what a function call will return if all you've read are the name and the signature. > If you call a function like iter(), you also get back an iterator, just > as you do when you call a generator. Is iter() not a normal function? Presumably somebody experienced with Python will already know what iter does without needing to read the code. >> def totally_not_a_generator(n): >> while True: >> if n % 2 == 0: >> n //= 2 >> else: >> n = n * 3 + 1 >> stealthily = n >> yield stealthily >> if n == 1: >> return n > > I must admit, I'm a little perplexed. In what way is this totally not a > generator? (To be precise, a generator function.) The inspect module > thinks it is (and so do I): The example was tongue-in-cheek. As suggested by the comment in the part that you cut out where I called it, the code is lying. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, May 11, 2018 at 12:04 PM, Bob van der Poel wrote: > I agree with my freind Gene! And, if it is really necessary to retain > octal, why not preface it with anything BUT a "0". I've been hit by this a > few times in the past. I used lots of hex over the years, but don't recall > ever using octal ... except in frustrating moments when I needed to change > permission bits. Because if it doesn't start with a 0, it won't look like a number. You could use &H1A2B for hex (I can't remember what the octal equivalent was), which consumes the ampersand as a syntactic character; or you could put a trailing adornment 1A2Bh, which looks like an identifier if the number starts with a letter. Much cleaner to make the marker "this is octal" or "this is hex" start with a zero, making it very clearly a number from the start. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Fri, May 11, 2018 at 4:39 PM, Ian Kelly wrote: > On Mon, May 7, 2018 at 9:45 PM, Mikhail V wrote: >> Benefits are easy to see: say I want a tuple of strings: >> >> data === T : >> "foo bar" >> "hello world" >> "to be continued..." >> >> VS current: >> >> data = ( >> "foo bar" , >> "hello world" , >> "to be continued..." , >> ) >> >> Main problem with the latter are commas, it is not easy >> to type > > In what bizarro world are commas harder to type than tabs? At least if > I type a comma I know I'll get a comma. If I type a tab then it > depends on my editor settings what I'll actually get. In Mikhail's defense, this is a reasonably elegant solution to the age-old problem of "I forgot a comma, now two of my entries got joined implicitly". It automatically makes multiple entries, and if you WANT joined entries, you would have to request that explicitly with the + operator or a line continuation backslash. Oh wait, these things aren't actual expressions, so you probably can't do either of those things... hmm. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a bug or a feature in TkInter?
On 5/11/2018 2:57 AM, Cuthbert Milligen wrote: Hi Terry, many thanks for your detailed explanation! (I can't see how to 'reply' under your post...) Followup to the list rather than reply to me, as you did, is the right thing to do. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
Marko Rauhamaa wrote: I was mildly amused when Python happily executed such code. "..." is a valid expression and thus, a valid statement. Fortunately, "?" still works for this! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
I suggest adding a new builtin constant: YouFeelLikeIt = True Then all pseudo-infinite loops can be written while YouFeelLikeIt: ... -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 10/05/2018 19:51, Chris Angelico wrote: YAGNI much? How often do you need a base-9 literal in your code?? You've obviously never programmed a Setun ternary computer: https://en.wikipedia.org/wiki/Setun -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing wrote: > I suggest adding a new builtin constant: > >YouFeelLikeIt = True > > Then all pseudo-infinite loops can be written > >while YouFeelLikeIt: > ... > Personally, I prefer to use string literals. while "you feel like it": ... Which, in a non-joking context, tends to look like this: while "moar data": data = get_data() process_data(data) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Chris Angelico wrote: Octal makes a lot of sense in the right contexts. Allowing octal literals is a Good Thing. And sticking letters into the middle of a number doesn't make that much sense, so the leading-zero notation is a decent choice. Also it's easy to forget that octal was a big part of the PDP-11 culture back then, even though it didn't fit all that well with a byte-oriented machine, largely due to earlier PDP models having multiple-of-3 word sizes. Programmers of that era probably dealt with octal numbers more often than either hex or decimal. -- Greg -- 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 think octal is a historical relic from a time when people weren't yet comfortable with hexadecimal. Octal made perfect sense for all PDP models up to the PDP-10, which had word sizes that were a multiple of 3 bits. It still partly made sense for the PDP-11, because its instruction encoding fitted well with octal. Hex came into vogue in the DEC world with the VAX, which was both byte-addressed and had a hex-oriented instruction encoding. -- 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: What do you mean, "another bit"? Currently, the chmod command on my system can manage nine primary bits (rwx for each of ugo), plus setuid, setgid, and sticky. I think the idea is that you could regroup those 4 groups of 3 into 3 groups of 4, and get a nice mapping to hex. If hex had been the conventional way of writing binary numbers back then, Ken and Dennis would probably have done it that way. Changing it now would require some fairly intimate surgery on unix, however, which is somewhat beyond the scope of what Python can achieve. -- 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: n for binary t for octal i for trinary o for duodecimal and of course, x for hexadecimal. And in format strings: "c" for decimal "a" for char "r" for string "w" for raw string Looks fine to me. Who wants to write the PEP? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Meaning of abbreviated terms
Steven D'Aprano wrote: 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. The term "property list" can also refer to a data structure in Lisp: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node108.html This has very little to do with Apple's use of the term, though. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 2018-05-10, Chris Angelico wrote: > On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens > wrote: >> This whole thread is reminding me PHP 2, which would magically treat >> the second parameter of ChMod() as octal, because clearly if weak >> typing is good then *no* typing must be best of all! >> >> ChMod($filename, 644); // second parameter is actually 420 base 10 > > Bear in mind that Unix file modes are traditionally written in octal, > because they have no meaning as numbers. They're more like > enumerations, or bitfields. The second parameter happens to be equal > to the base 10 number 420, but that's completely useless. A file mode > of 100644 means something; a file mode of 0x81a4 or 33188 decimal > means nothing. PHP went for crazy magic there, but if the API had been > built such that the "644" is passed as a string, it would have been > completely sane and entirely useful. Or indeed if it was passed as 0644 or 0o644 as an octal literal. The issue is not *why* Rasmus did this - that's obvious - the issue is that he didn't know why he *shouldn't* make a language where 1234 is a decimal integer literal except sometimes it isn't. The PHP manual even recommended that you write the second parameter as 0644 to "remind you" that it was treated as octal, although the leading 0 made no actual semantic difference to the way the code was parsed by the language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote: > Hex came into vogue in the DEC world with the VAX, which was both > byte-addressed and had a hex-oriented instruction encoding. Indeed. In 2018 when nearly all computers (aside from some DSPs) have standardised on the same number of bits, it is hard to remember that in Ancient Days there was damn little standardisation of computers. You had computers with 6, 9, or even 60 bits per byte, machines that used BCD in preference to binary ints, and even a few Russian-made computers that didn't use binary at all, but ternary. I'm also told that some of those computers didn't run Windows. *wink* -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 11/05/2018 01:11, Chris Angelico wrote: On Fri, May 11, 2018 at 8:43 AM, bartc wrote: This is Wrong, and would have been just as obviously wrong in 1989. Having spent many years programming in C and working on Unix, I strongly disagree. Using C is apt to give you a rather warped view of things. Such that everything in that language is superior to any other way of doing it. (And actually, because C didn't have binary literals for a long time (I think it still doesn't, officially), there has been a lot of discussion in comp.lang.c about how they are not really necessary: : A real programmer can auto-convert from hex : It's so easy to knock up some macro that will do it : They have /never/ needed binary in decades of programming And so on. Meanwhile my own /recent/ code includes lines like this: when 2x'101'11010'000 then ... # (x64/x87 disassembler) although I think I still prefer a trailing B, with separator: when 101'11010'000'B then ... Try /that/ in hex /or/ octal.) This was *not* obviously wrong. It's easy to say "but look at the real world"; but in the 80s and 90s, nobody would have said that it was "obviously wrong" to have the native integer wrap when it goes past a certain number of bits. And in fact, your description of the real world makes it equally obvious that numbers should have a fixed width: Much of the real world /does/ use fixed widths for numbers, like that odometer for a start, or most mechanical or electronic devices that need to display numbers. And with many such devices, they wrap as well (remember tape counters). Even my tax return has a limit on how big a sum I can enter in the boxes on the paper form. So the concept of fixed upper width, sometimes modulo numbers isn't alien to the general public. But leading zeros that completely change the perceived value of a number IS. Octal makes a lot of sense in the right contexts. Allowing octal literals is a Good Thing. And sticking letters into the middle of a number doesn't make that much sense, so the leading-zero notation is a decent choice. No it isn't. You need something that is much more explicit. I know your C loyalty is showing here, but just admit it was a terrible choice in that language, even in 1972. And just as bad in 1989. (I've used one language where the default base (radix it called it) was octal. But even there, when overriding it, the override mechanism was more obvious than the presence of a leading zero.) It's all very well to argue that it's a suboptimal choice; but you have to remember that you're arguing that point from 2018, and we have about thirty years of experience using Python. The choice was most definitely not fundamentally wrong. Ten years ago, the point was revisited, and a different choice made. That's all. This gives a few different ways of writing hex and octal: https://rosettacode.org/wiki/Literals/Integer The leading zero method for octal seems to have permeated a few other languages. While F#, among others, uses 0o, which in my browser looks like Oo12. (If, for some reason, you did want leading zeros, then the number would look like OoO12.) Why do language designers perpetuate bad ideas? The reason for designing a new language is just so you can get rid of some of them! -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 10/05/2018 21:18, bartc wrote: On 10/05/2018 19:51, Chris Angelico wrote: On Fri, May 11, 2018 at 4:31 AM, bartc wrote: 2x100 (4) Binary 3x100 (9) Ternary 4x100 (16) Quaternary 5x100 (25) etc 6x100 (36) 7x100 (49) 8x100 (64) Octal 9x100 (81) ... (Not implemented 11x to 15x, nor 10x or 16x) 0x100 (256) Hex YAGNI much? How often do you need a base-9 literal in your code?? I've just found out these also work for floating point. So that: a := 8x100.5 print a gives 64.625 in decimal (not 64.5 as I expected, because .5 is 5/8 not 5/10!). Exponent values are octal too, scaling by powers of 8. I tried it in Python 3 (0o100.5 - I find that prefix fiddly to type actually as I have to stop and think), and it seems to be illegal. Based floating point literals may be unusual, but bear in mind that in decimal, some values may not be represented exactly (eg 0.1). I believe that in base 2, 4, 8 or 16, any floating point literal can be represented exactly, at least up the precision available. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2018: Please reset your password
Regular password resets are always a good thing to do, but this time we have a specific reason to ask you to consider taking the extra time. In December 2017, our ISP detected port scans originating from our server and informed us about these. During the analysis, we found that someone (or better: some script) had found a way to break-in to our web server running the EuroPython website. We quickly fixed the situation, reset all authorizations and put measures in place to strictly limit the number of people having access to the server to a minimum and better secure the server against future break-in attempts. The server was only used as SSH port scanning relay and we found no evidence of loss or leakage of data. We don’t believe that any of your personal information got into the wrong hands, but even though the passwords are stored using secure and salted hashes (using PBKDF2), we still recommend to reset your password to be on the safe side. We know that this notice is late and we’d like to apologize for the hassle caused by this. If you have just created a new account on the https://ep2018.europython.eu/ website we just launched, no further action is necessary. We only recommend the password reset if you have had an account with us in previous years and this account is active on the new https://ep2018.europython.eu/ website. Logins on the older versions of our website are disabled for regular users, so no action is necessary on these. Please see our blog post for instructions on how to reset your password: https://blog.europython.eu/post/173793513217/europython-2018-please-reset-your-password Enjoy, -- EuroPython 2018 Team https://ep2018.europython.eu/ https://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/994879080263831552 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
bartc writes: > On 11/05/2018 01:25, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> Octal makes a lot of sense in the right contexts. >> >> I think octal is a historical relic from a time when people weren't yet >> comfortable with hexadecimal. > > It's a relic from when machines had word sizes that were multiples of > three bits, or were divided up on 3-bit boundaries. It got into C via B and B was often used on machine with a word size that was a multiple of three. But octal was very useful on 16-bit PDP-11s which is probably why it was kept. The PDP-11 has 8 registers and uses 3 bits to specify the addressing mode and many instructions use the top bit to indicate a variation such as word or byte operation. The result is that you'd never choose to use hex to look at PDP-11 code. That familiarity with octal must have played a bit part in deciding to include it in C. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
Chris Angelico : > On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing > wrote: >> I suggest adding a new builtin constant: >> >>YouFeelLikeIt = True >> >> Then all pseudo-infinite loops can be written >> >>while YouFeelLikeIt: >> ... >> > > Personally, I prefer to use string literals. > > while "you feel like it": > ... I still think my use of the Ellipsis speaks more to the maintainer of the code: while ...: pass Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Ben Bacarisse : > bartc writes: >> On 11/05/2018 01:25, Marko Rauhamaa wrote: >>> I think octal is a historical relic from a time when people weren't >>> yet comfortable with hexadecimal. >> >> It's a relic from when machines had word sizes that were multiples of >> three bits, or were divided up on 3-bit boundaries. > > It got into C via B and B was often used on machine with a word size > that was a multiple of three. But octal was very useful on 16-bit > PDP-11s which is probably why it was kept. The PDP-11 has 8 registers > and uses 3 bits to specify the addressing mode and many instructions > use the top bit to indicate a variation such as word or byte > operation. The result is that you'd never choose to use hex to look at > PDP-11 code. That familiarity with octal must have played a bit part > in deciding to include it in C. It may have been the other way round: people were comfortable with octal, which led to seeing three-bit fields everywhere and even designing CPUs accordingly. Four-bit fields were used for BCD, but I'm guessing using letters as digits felt awkward among computer people for a long time. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> What do you mean, "another bit"? Currently, the chmod command on my >> system can manage nine primary bits (rwx for each of ugo), plus >> setuid, setgid, and sticky. > > > I think the idea is that you could regroup those 4 groups > of 3 into 3 groups of 4, and get a nice mapping to hex. > If hex had been the conventional way of writing binary numbers > back then, Ken and Dennis would probably have done it that > way. But they aren't "four groups of three" that could be reorganized. They're three groups of three, plus three separate bits. Each group of three is the permissions for one category of user (the owner, anyone in the owning group, or everyone else). If your permission set is 6, you may read and write, but not execute. If it's 4, you may only read. 5 lets you read and execute. 0 denies everything. What other bit would you add? Tack setuid onto "owner", setgid onto "group", and sticky onto "others"? Pretty arbitrary, and disrupts the fundamental meaning of each set. (Plus, it still ignores the "is-directory" and "is-link" bits, etc.) > Changing it now would require some fairly intimate surgery > on unix, however, which is somewhat beyond the scope of > what Python can achieve. > Yes, and wouldn't improve either Unix or Python. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, May 11, 2018 at 9:09 PM, bartc wrote: > On 11/05/2018 01:11, Chris Angelico wrote: >> >> On Fri, May 11, 2018 at 8:43 AM, bartc wrote: >>> >>> This is Wrong, and would have been just as obviously wrong in 1989. >> >> >> Having spent many years programming in C and working on Unix, I >> strongly disagree. > > > Using C is apt to give you a rather warped view of things. Such that > everything in that language is superior to any other way of doing it. Obviously, which is why you hear me vehemently arguing against garbage collection, since in C you have to explicitly free everything up. And since I've used C and think that everything it does is the best possible way to do things, I have strongly debated that we should get rid of strings as first-class objects and just use buffers of characters, which are kinda just bytes if you squint at them. > (And actually, because C didn't have binary literals for a long time (I > think it still doesn't, officially), there has been a lot of discussion in > comp.lang.c about how they are not really necessary: > > : A real programmer can auto-convert from hex > : It's so easy to knock up some macro that will do it > : They have /never/ needed binary in decades of programming > > And so on. Meanwhile my own /recent/ code includes lines like this: > > when 2x'101'11010'000 then ... # (x64/x87 disassembler) > > although I think I still prefer a trailing B, with separator: > > when 101'11010'000'B then ... > > Try /that/ in hex /or/ octal.) I've no idea what this is supposed to mean, or why you have groups of three, five, and three. Looks like a possible bug to me. I'm sure it isn't, of course, since you're one of those perfect programmers who simply doesn't _make_ errors, but if it were my code, I would be worried that it isn't correct somewhere. >> This was *not* obviously wrong. It's easy to say >> "but look at the real world"; but in the 80s and 90s, nobody would >> have said that it was "obviously wrong" to have the native integer >> wrap when it goes past a certain number of bits. And in fact, your >> description of the real world makes it equally obvious that numbers >> should have a fixed width: > > > Much of the real world /does/ use fixed widths for numbers, like that > odometer for a start, or most mechanical or electronic devices that need to > display numbers. And with many such devices, they wrap as well (remember > tape counters). > > Even my tax return has a limit on how big a sum I can enter in the boxes on > the paper form. > > So the concept of fixed upper width, sometimes modulo numbers isn't alien to > the general public. But leading zeros that completely change the perceived > value of a number IS. Cool. So what's the native integer size for the real world? Use that as your primary data type. Oh, can't decide how many digits? That's a pity. >> Octal makes a lot of sense in the right contexts. Allowing octal >> literals is a Good Thing. And sticking letters into the middle of a >> number doesn't make that much sense, so the leading-zero notation is a >> decent choice. > > No it isn't. You need something that is much more explicit. I know your C > loyalty is showing here, but just admit it was a terrible choice in that > language, even in 1972. And just as bad in 1989. Go get a time machine. Spend some time in the 1980s. See what kinds of programming people were doing. HINT: It wasn't web app development. > Why do language designers perpetuate bad ideas? The reason for designing a > new language is just so you can get rid of some of them! Yeah, which is why your personal pet language has approximately one user. The more things you change when you create a new language, the more likely that it'll be utterly useless to anyone but yourself. Consistency is a lot more important than many people give it credit for. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 1:06 AM, Chris Angelico wrote: > On Fri, May 11, 2018 at 4:54 PM, Ian Kelly wrote: >> On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano >> wrote: >>> To be honest, I'm having trouble thinking of a good use-case for "while >>> True", now that we have infinite iterators. Most cases of >>> >>> while True: >>> x = get_item() >>> if not x: break >>> process(x) >>> >>> are better written as: >>> >>> for x in iterator: >>> process(x) >> >> x = get_item() >> while True: >> x = process(x) > > More likely: > > x = get_item() > while x: > process(x) > x = get_item() > > which (a) repeats the call to get_item, (b) doesn't support the > 'continue' statement, and (c) hides crucial loop iteration information > at the BOTTOM of the loop. > > But to make this iterator, you need to separate the while loop's > header from its body. Compare: > > while x := get_item(): > process(x) > > > def get_items(): > while True: > x = get_item() > if not x: return > yield x > > for x in get_items(): > process(x) > > It hasn't actually gotten rid of the fib of the infinite loop; all > it's done is wrap it up in a function. Yes, that can be of value; but > adding another level of indirection doesn't solve a problem, it just > moves it around. You can get rid of the while loop: for x in iter(get_item, None): process(x) The reason I suggested the function I did is because the x in that case can't reasonably be turned into an iterator because the logic depends on the loop body. You can't encapsulate the iteration logic without having side-effects in the iteration or duplicating code. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 1:01 AM, Chris Angelico wrote:
> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
>>
>> def totally_not_a_generator(n):
>> while True:
>> if n % 2 == 0:
>> n //= 2
>> else:
>> n = n * 3 + 1
>> stealthily = n
>> yield stealthily
>> if n == 1:
>> return n
>>
>> py> print(totally_not_a_generator(42)) # Lies!
>>
>
> Let's see. It's created with 'def'. It can be called by putting
> parentheses after its name. Inside the parentheses, you can give it
> parameters. When called, it returns a value. Hmm. Sure looks like a
> function to me.
>
> Tell me, which of these are functions and which are not?
>
> def tnag5():
> return totally_not_a_generator(5)
>
> def tnag(n):
> return iter(totally_not_a_generator(n))
>
> def ILY():
> return iter([1, 2, 3]) # your heart starts beating
>
> async def what_about_me():
> await spam()
> return 42
>
> def digits_to_number(text):
> return int(text, 10)
>
> class run_command:
> """Compatibility shim for older API"""
> def __init__(self, *args):
> proc = subprocess.run(*args, stdout=subprocess.PIPE)
> self.rc = proc.returncode
> self.output = proc.output
>
> def run_command(*args):
> proc = subprocess.run(*args, stdout=subprocess.PIPE)
> return {"rc": proc.returncode, "output": proc.output}
>
>
> The only one that inspect.isfunction() returns False for is the class,
> and even that is a very function-like class. Every one of these is
> callable and will return a useful value. Their headers announce one of
> three things:
>
> 1) "I am a function" ==> def name(...):
> 2) "I am a factory for objects of my own type" ==> class name:
> 3) "I am a coroutine function" ==> async def name(...):
>
> Not one of them is lying. And nor is your totally_not_a_generator. As
> Steven said, it's a function, and it returns a value.
It's a generator that says it's not a generator. How is that not lying?
Anyway, as far as I can see you just repeated the same argument that
Steven wrote. I know all this, of course, and I think you missed the
point. Please read my response to Steven.
--
https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 11:28 PM, Ian Kelly wrote: > You can get rid of the while loop: > > for x in iter(get_item, None): > process(x) > > The reason I suggested the function I did is because the x in that > case can't reasonably be turned into an iterator because the logic > depends on the loop body. You can't encapsulate the iteration logic > without having side-effects in the iteration or duplicating code. That's actually equivalent to: while (x := get_item()) != None: process(x) That's not often going to be what you want. If the function is guaranteed to return None, you should be using "is not None", and if it's simply returning something falsey, you should be checking truthiness. Once again, this is shoe-horning the available mechanics into tasks that aren't quite what they're designed for; they're "close enough" for a lot of cases, but not really correct. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
Chris Angelico : > On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing > wrote: >> I think the idea is that you could regroup those 4 groups of 3 into 3 >> groups of 4, and get a nice mapping to hex. If hex had been the >> conventional way of writing binary numbers back then, Ken and Dennis >> would probably have done it that way. > > But they aren't "four groups of three" that could be reorganized. > They're three groups of three, plus three separate bits. Each group of > three is the permissions for one category of user (the owner, anyone > in the owning group, or everyone else). "And on far-off Earth, Dr. Carlisle Perera had as yet told no one how he had wakened from a restless sleep with the message from his subconscious still echoing in his brain: The Ramans do everything in threes.W https://en.wikipedia.org/wiki/Rendezvous_with_Rama> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 11:31 PM, Ian Kelly wrote:
> On Fri, May 11, 2018 at 1:01 AM, Chris Angelico wrote:
>> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
>>> Would you also contend that generator functions are wrong because they
>>> pretend to be normal functions?
>>>
>>> def totally_not_a_generator(n):
>>> while True:
>>> if n % 2 == 0:
>>> n //= 2
>>> else:
>>> n = n * 3 + 1
>>> stealthily = n
>>> yield stealthily
>>> if n == 1:
>>> return n
>>>
>>> py> print(totally_not_a_generator(42)) # Lies!
>>>
>>
>> Let's see. It's created with 'def'. It can be called by putting
>> parentheses after its name. Inside the parentheses, you can give it
>> parameters. When called, it returns a value. Hmm. Sure looks like a
>> function to me.
>>
>> Tell me, which of these are functions and which are not?
>>
>> def tnag5():
>> return totally_not_a_generator(5)
>>
>> def tnag(n):
>> return iter(totally_not_a_generator(n))
>>
>> def ILY():
>> return iter([1, 2, 3]) # your heart starts beating
>>
>> async def what_about_me():
>> await spam()
>> return 42
>>
>> def digits_to_number(text):
>> return int(text, 10)
>>
>> class run_command:
>> """Compatibility shim for older API"""
>> def __init__(self, *args):
>> proc = subprocess.run(*args, stdout=subprocess.PIPE)
>> self.rc = proc.returncode
>> self.output = proc.output
>>
>> def run_command(*args):
>> proc = subprocess.run(*args, stdout=subprocess.PIPE)
>> return {"rc": proc.returncode, "output": proc.output}
>>
>>
>> The only one that inspect.isfunction() returns False for is the class,
>> and even that is a very function-like class. Every one of these is
>> callable and will return a useful value. Their headers announce one of
>> three things:
>>
>> 1) "I am a function" ==> def name(...):
>> 2) "I am a factory for objects of my own type" ==> class name:
>> 3) "I am a coroutine function" ==> async def name(...):
>>
>> Not one of them is lying. And nor is your totally_not_a_generator. As
>> Steven said, it's a function, and it returns a value.
>
> It's a generator that says it's not a generator. How is that not lying?
>
> Anyway, as far as I can see you just repeated the same argument that
> Steven wrote. I know all this, of course, and I think you missed the
> point. Please read my response to Steven.
You said:
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
So, yes, your function's name is outright lying. But there's nothing
about it that is *pretending* to be a normal function. It IS a normal
function.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 2018-05-11, Gene Heskett wrote: > Computers haven't read a single 8 bit byte in years, some reading > 128 or 256 bits in a single read cycle today. Nonsense. All modern CPUs that I'm aware of still still support single byte reads, and compilers still use those instructions when the size of the object being read is 8 bits. -- Grant Edwards grant.b.edwardsYow! An INK-LING? Sure -- at TAKE one!! Did you BUY any gmail.comCOMMUNIST UNIFORMS?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 2018-05-11, Dennis Lee Bieber wrote: > On Fri, 11 May 2018 01:55:58 +0100, bartc declaimed the > following: > >>On 11/05/2018 01:25, Marko Rauhamaa wrote: >>> Chris Angelico : >>> Octal makes a lot of sense in the right contexts. >>> >>> I think octal is a historical relic from a time when people weren't yet >>> comfortable with hexadecimal. >> >>It's a relic from when machines had word sizes that were multiples of >>three bits, or were divided up on 3-bit boundaries. > > The Intel 8080a was 8-bit bytes, but octal was actually more usable > when interpreting op-codes. 3-bits encoded the processor registers > (including the "M"emory access via HL address). A(7), B(0)-C(1), > D(2)-E(3), H(4)-L(5), M(6): MOV H,E => 143 octal is easier to decode > than 63 hex The first 8080-compatible "computer" I owned was a Heathkit terminal with an 8085 CPU. The firmware listings used "split octal": 0x = 000 000 0x = 377 377 IIRC, PDP-11 assembly listings and machine documentation generally used octal for the same reason: the 16-bit instruction word was internally divided into a number of 3-bit fields. -- Grant Edwards grant.b.edwardsYow! Now that I have my at "APPLE", I comprehend COST gmail.comACCOUNTING!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 2018-05-11, Steven D'Aprano wrote: > On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote: > >> Hex came into vogue in the DEC world with the VAX, which was both >> byte-addressed and had a hex-oriented instruction encoding. > > > [...] You had computers with 6, 9, or even 60 bits per byte Ah, the old CDC-6600 had 60-bit words. IIRC, the Pascal compiler used a 6-bit wide character set, which meant that you could fit 10 characters in a word, and Pascal identifiers were limited to 10 characters. > I'm also told that some of those computers didn't run Windows. Of course not, everything ran Linux back in the good old days. -- Grant Edwards grant.b.edwardsYow! PIZZA!! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Fri, May 11, 2018 at 7:40 AM, Chris Angelico wrote: > So, yes, your function's name is outright lying. But there's nothing > about it that is *pretending* to be a normal function. It IS a normal > function. The detail of whether it's a generator function affects the function's execution and may be relevant to the caller. Here are two hypothetical functions. They do some processing with side-effects over a bunch of items and return the processed items. However, one is a generator function and the other just returns a list. def process_items(items): ... def handle_items(items): ... Now, we can agree that these ought to be better documented, but say I want to call one of these for the side effects and ignore the return value. Just from reading the first line of the function, do I need to iterate over the result, or not? Scenario 2. I have two "while True" loops. One is potentially infinite and the other is not. while True: ... while True: ... Obviously, it's important to know whether a loop might be infinite before I run the code that includes it. Just from reading the first line of the loop, how do I know? You can argue that they should use strings instead to describe what they do, which would help, although I think that's potentially confusing. I don't see these two situations as being fundamentally different. Do you? -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing File Descriptors To Subprocesses
I encountered the same issue with Python 3.4 on CentOS 7 when using only the close_fds argument. Since I am passing a lot of dynamically obtained file descriptors, using the pass_fds argument is impossible for my case. Setting close_fds to False *but* also explicitly making the fds inheritable upon generation solved the issue. I would be really grateful if there was at least a note in the subprocess module explaining that one might need to explicitly make file descriptors inheritable since if it wasn't this post I would have lost even more time than I already did. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Sat, May 12, 2018 at 1:03 AM, Ian Kelly wrote: > On Fri, May 11, 2018 at 7:40 AM, Chris Angelico wrote: >> So, yes, your function's name is outright lying. But there's nothing >> about it that is *pretending* to be a normal function. It IS a normal >> function. > > The detail of whether it's a generator function affects the function's > execution and may be relevant to the caller. Here are two hypothetical > functions. They do some processing with side-effects over a bunch of > items and return the processed items. However, one is a generator > function and the other just returns a list. > > def process_items(items): > ... > > def handle_items(items): > ... > > Now, we can agree that these ought to be better documented, but say I > want to call one of these for the side effects and ignore the return > value. Just from reading the first line of the function, do I need to > iterate over the result, or not? This is no different from anything else you might need to know about the functions. It might be essential to know that "handle_items" actually doesn't return anything at all, and signals success or failure by what exception it raises. Or that "process_items", due to internal structure and implementation, absolutely must be called from the main thread, otherwise you risk OS-level signals corrupting your data. The solution is simple: read the docstring. > Scenario 2. I have two "while True" loops. One is potentially infinite > and the other is not. > > while True: > ... > > while True: > ... > > Obviously, it's important to know whether a loop might be infinite > before I run the code that includes it. Just from reading the first > line of the loop, how do I know? You can argue that they should use > strings instead to describe what they do, which would help, although I > think that's potentially confusing. > > I don't see these two situations as being fundamentally different. Do you? Not hugely, no. But it's worth noting that we have the option to annotate a function's return value. So if you need structured information about what this function or that function returns, you can provide that. It's not easy to make program-readable information about a 'while' loop (since it's not a first-class object), but you can still have structured information about whether the loop is infinite or not, by putting it into the loop header. But I still think you're overblowing the case when you claim that a generator function isn't a function. That'd be on par with claiming that a while loop isn't a loop. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 2018-05-11, Grant Edwards wrote: > On 2018-05-11, Gene Heskett wrote: >> Computers haven't read a single 8 bit byte in years, some reading >> 128 or 256 bits in a single read cycle today. > > Nonsense. All modern CPUs that I'm aware of still still support > single byte reads, and compilers still use those instructions when the > size of the object being read is 8 bits. It's not nonsense. The CPU might have a 'load a byte' instruction but it will actually read more than a byte and then throw away the extra. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On 11/05/2018 14:24, Chris Angelico wrote:
On Fri, May 11, 2018 at 9:09 PM, bartc wrote:
when 101'11010'000'B then ...
Try /that/ in hex /or/ octal.)
I've no idea what this is supposed to mean, or why you have groups of
three, five, and three. Looks like a possible bug to me. I'm sure it
isn't, of course, since you're one of those perfect programmers who
simply doesn't _make_ errors, but if it were my code, I would be
worried that it isn't correct somewhere.
The data-sheet for the 8087 numeric co-processor displays instructions
of the two-byte opcodes in formats like this (high to low bits):
[escape 1 0 1] [1 1 0 1 0 ST(i)]
'escape' is the 5-bit sequence 11011. ST(i) is a 3-bit register code. So
considered as a one 16-bit value, it's divided into groups of 5:3:5:3.
The escape sequence has already been detected, and the middle two groups
have been isolated by masking with 111'1'000B.
So it is checking for combinations of those middle 3:5 groups of bits in
a way that exactly matches how it's presented in the data sheet. And
this instruction encoding is still used in current AMD/Intel x64 processors.
The x-101-11010-xxx pattern corresponds to the FST ST(0) to ST(i)
instruction:
when 101'11010'000B then
genstr("fst ")
genstr(strfreg(freg))
It's not a bug. Just a good example of the use of binary where hex or
octal doesn't cut it because the grouping isn't purely in threes or fours.
(I understand that binary literals were added to Python from version
2.6. The question is why it took so long. They are not a heavyweight
feature.)
Cool. So what's the native integer size for the real world? Use that
as your primary data type.
Oh, can't decide how many digits? That's a pity.
What's this got to do with octal? Because many languages impose a limit
on the widths of numeric types, that somehow makes it OK to implement
octal using leading zeros? Just to catch people out because octal is
used so rarely.
Go get a time machine. Spend some time in the 1980s. See what kinds of
programming people were doing. HINT: It wasn't web app development.
I was doing lots of development in the 1980s. I just didn't use C.
Yeah, which is why your personal pet language has approximately one
user. The more things you change when you create a new language, the
more likely that it'll be utterly useless to anyone but yourself.
Consistency is a lot more important than many people give it credit for.
That's why 0100 is sixty four in Python 2, and an error in Python 3?
Instead of being one hundred in both, as common sense would have dictated.
And, for that matter, one hundred in any of my languages, some of which
did have more than one user.
BTW here is one C-ism that /didn't/ make it into Python 1:
print (0xE-1)
This prints 13 (0xE is 14, minus 1). But it would be an error in
conforming C compilers:
printf("%d", 0xE-1);
"error: invalid suffix "-1" on integer constant"
Perhaps consistency isn't always as important as you say, not for
something which is crazily stupid.
At least 0xE-1 generates an error (on some compilers; on others, only
years later when you switch compiler). 0100, if not intended as octal,
is an undetectable error in C and Python 2.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano wrote: > On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote: > >> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano >> wrote: >>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed >>> prefixes for octal: >>> Personally I would have preferred the "t". >>> >>> "t" for octal, hey? >>> >>> That would be annoying if we ever get trinary literals. >>> >>> n for binary >>> t for octal >>> i for trinary >>> or should that be r for ternary? >>> o for duodecimal >> >> I prefer it because it's the first letter of a syllable and it's not >> "o", not because it's the third letter of the word. > > You should have said. Since you quoted the PEP, I inferred you were > agreeing with the PEP's suggestion: > > even to use a "t" for "ocTal" and an "n" for "biNary" to > go along with the "x" for "heXadecimal". > > Note the "go along with". The X of hexadecimal, and the N of binary, are > the *last* letter of a syllable, not the first, so I didn't think that > "first letter of a syllable" was the rule you were applying. If it were, > you would have picked "C" for oc-tal, not t. The X of hexadecimal is pronounced as the consonant cluster /ks/. The k sound ends the first syllable, and the s sound begins the second syllable. So the X is both, really. The N of binary is the first letter of the second syllable, unless the Australian pronunciation is radically different from the American. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
On Fri, May 11, 2018 at 10:35 AM, Ian Kelly wrote: > On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano > wrote: >> On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote: >> >>> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano >>> wrote: On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed prefixes for octal: > Personally I would have preferred the "t". "t" for octal, hey? That would be annoying if we ever get trinary literals. n for binary t for octal i for trinary or should that be r for ternary? o for duodecimal >>> >>> I prefer it because it's the first letter of a syllable and it's not >>> "o", not because it's the third letter of the word. >> >> You should have said. Since you quoted the PEP, I inferred you were >> agreeing with the PEP's suggestion: >> >> even to use a "t" for "ocTal" and an "n" for "biNary" to >> go along with the "x" for "heXadecimal". >> >> Note the "go along with". The X of hexadecimal, and the N of binary, are >> the *last* letter of a syllable, not the first, so I didn't think that >> "first letter of a syllable" was the rule you were applying. If it were, >> you would have picked "C" for oc-tal, not t. > > The X of hexadecimal is pronounced as the consonant cluster /ks/. The > k sound ends the first syllable, and the s sound begins the second > syllable. So the X is both, really. > > The N of binary is the first letter of the second syllable, unless the > Australian pronunciation is radically different from the American. Also, the C in octal is the last letter of the first syllable. I stand by my choice. -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
> > And, if it is really necessary to retain > octal, why not preface it with anything BUT a "0". > I believe "0o" offers some symmetry with the "0x" prefix used for hex literals. (And "0b" for binary.) It's a bit unfortunate that zero and capital "oh" are visually so similar. Not much to be done about that at this point. Just avoid upper case for all three prefixes. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing File Descriptors To Subprocesses
On 5/11/2018 11:23 AM, pevo...@gmail.com wrote: I encountered the same issue with Python 3.4 on CentOS 7 when using only the close_fds argument. Since I am passing a lot of dynamically obtained file descriptors, using the pass_fds argument is impossible for my case. Setting close_fds to False *but* also explicitly making the fds inheritable upon generation solved the issue. I would be really grateful if there was at least a note in the subprocess module explaining that one might need to explicitly make file descriptors inheritable since if it wasn't this post I would have lost even more time than I already did. Make specific proposal on the tracker bugs.python.org. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: > On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: >> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano >> wrote: >>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: >>> >> but I propose Tab-separated elements. > > Then these are not ordinary expressions, are they? They're a different > type of expression and will require a modified parser. This adds > complexity. Definitely such syntax will require modifed parser. >> "GvR have invented amazing new syntax that cannot be preserved >> by sending it by e-mail"! >> (not me) >> >> 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" > 3) Tabs that appear in strings: This one I'll grant you. This too. So what is false? Yes with my syntax it will just become more prone to environments which replace tabs with spaces. Mostly this happens in e-mails and web forms. Why they do it I don't have an idea. Anyway keeping this in mind, I'd prefer not to adapt the syntax to such things. It would be fair that the software solutions should address those, as it should not happen. > 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. >> 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? (note, I don't ask to align the columns, I just ask what real problems you have with that?) TBH I cant say for tools other than normal editor. Just hope it will not become my problem to test all legacy stuff out there. >> For instance, there is real demand on adding new control characters >> to syntax, so as IDE developers can utilize those for making >> better user experience. If you apply same one-sided principles here >> then you behave good to one group of people, but just ignorant >> to other group of people who want better new experience. > > Please link the approved PEP that is going to add syntactically > meaningful control characters. Sorry, i was writing too fast - not control characters, but characters in general. That was kind of general parallel to the current situation. I'll try to ask better: for instance, if propose to use some unicode character operator - so I can use the editor feature. In theory - many people may potentially benefit but some people have issues with it in some software. And the issues may vary in nature - e.g. Steven can't bind a keyboard shortcut to type it. OTOH it may be something really bad - a software failure or general problem. So the question is what would be more _serious/general_ problem. 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. >> >> "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
PIP install
I have installed Python recently. Do I need to install PIP separately or this would be part of default installation. When I run pip install <>, windows complains that no such command exists -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
On Fri, May 11, 2018 at 9:39 AM, Ian Kelly wrote: > On Mon, May 7, 2018 at 9:45 PM, Mikhail V wrote: >> *Example 1. Multi-line strings* >> >> data === S : >> this is multi-line string >> escape chars: same as in strings (\\, \\n, \\t ...) , >> but "no need to 'escape' quotes" > > My reaction #1: why 'S'? Python strings have a name: it's 'str'. > ... > My reaction #2: what's the point of this construct? Python already has > multi-line strings that can be used as expressions, not as statements > only. #1. I think passing multiline data structures as arguments is not especially beautiful. Necessary? I don't know. #2. What is the point? If introduce the new syntax _at all_, - the cost of adding some additional common types is less - IOW worth investigating some options? About string type id - I agree it may be suboptimal with "S", since it is not like tuples. But well, there must be something. In this case: s = """\ multi line string multi multi line string multi line string multi line string""" vs: s === S: multi line string multi multi line string multi line string multi line string Nothing revolutional, just a bit cleaner and with an indent (which is not necesserily always a good thing but IMO a bit more presentable). The problem though, this will require editors to modify their lexers for highlighting - this is a problem :/ > My reaction #3: Not a fan of adding an '===' operator. We already have > '=' and '=='. Javascript is another language that uses '===' to mean > something completely different from this proposal (it's another > equality operator) and it's a mess there. Come up with something else. > "===" is just the least disturbing one I've come up with while experimenting. I thought it should start with "=" at least. E.g. data =% T : data =\\ T : (\\ now is syntaxError: unexpected character after line continuation) I dont know - frankly I think its too early to start the game of perfect operator choice. >> Benefits are easy to see: say I want a tuple of strings: >> >> data === T : >> "foo bar" >> "hello world" >> "to be continued..." >> >> VS current: >> >> data = ( >> "foo bar" , >> "hello world" , >> "to be continued..." , >> ) >> >> Main problem with the latter are commas, it is not easy >> to type > > In what bizarro world are commas harder to type than tabs? At least if > I type a comma I know I'll get a comma. If I type a tab then it > depends on my editor settings what I'll actually get. Well, in the above case you don't have to type tabs or commas. As for what character is easier to type : commas or tabs : I find that Tab key is maybe a bit harder when using together with upper number row keys - OTOH when using keypad - it feels easier. On average I think its comparable. Also if you type commas, usually you want to type space after a comma, or a Tab ;-) So Tab maybe will win this race. >> and, whats more important - hard to notice missing commas. > > But it's totally easy to notice missing tabs, right? Not. **Those are two different things** - commas must be there - and the issue persists, you want it or not. I still have feeling that you try to imply that commas have some role apart from Disambiguation of closely positioned tokens - that's what they are from reader's POV. In other words, if inter-token spacing is solid - commas are nothing but redundant noise. Do you understand this or not? Also there was a topic about string lists on 'Ideas' recently - so thats not only me who notices it. Issues with input of tabs is more of psychology & experience I'd say. I haven't problems with that. Normally I input 2 tabs to make it form a solid whitespace- it gives me optimal look. And I don't bother too much with perfect alignment usually. >> *Example 3. Two-dimensional tuple.* >> >> data === T/T : > > What about T/S? S/T? S/S? Are these allowed? Not really. The idea is: to identify common cases and data structures and try to find an optimal set of ID's to represent them. But the slash indicates that it's 2D case - so this one is sort of explicit sign of higher dimension. > > Also, why is there a division operator here? "slash" > >> 123"hello" >> abc + de f >> >> is a synonym for: >> >> data = ( >> (1, 2, 3, "hello") , >> (a, b, c + d, e, f ) ) > > If this is supposed to be a tabular format then why is the second row > allowed to have a different number of elements than the first row? why not ? > > What about named fields? Is there a proposal for extending this syntax > to allow construction of dicts or namedtuples? Maybe - though there already exist Python built-in methods to convert e.g. tuples to dicts and lists. > >> The rule here is: TAB character is inner elements' separator, and the >> new line is outer elements' separator. Line continuation >> character is \ (to help with long lines). > > So brackets and commas are too ugly, but line continuation characters >
Re: PIP install
On 2018-05-12 03:47, Sharan Basappa wrote: I have installed Python recently. Do I need to install PIP separately or this would be part of default installation. When I run pip install <>, windows complains that no such command exists That means that pip isn't on the Windows search path. It might be better to call the pip module via the py launcher: py -m pip install <> -- https://mail.python.org/mailman/listinfo/python-list
issue runing ipython
I see an issue while running ipython. Can anyone help please. D:\Users\sharanb>ipython notebook [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is deprecated and will be removed in future versions. [TerminalIPythonApp] WARNING | You likely want to use `jupyter notebook` in the future Traceback (most recent call last): File "d:\users\sharanb\appdata\local\programs\python\python37-32\lib\runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "d:\users\sharanb\appdata\l -- https://mail.python.org/mailman/listinfo/python-list
Re: PIP install
On Saturday, 12 May 2018 08:32:04 UTC+5:30, MRAB wrote: > On 2018-05-12 03:47, Sharan Basappa wrote: > > I have installed Python recently. Do I need to install PIP separately or > > this would be part of default installation. When I run pip install <>, > > windows complains that no such command exists > > > That means that pip isn't on the Windows search path. > > It might be better to call the pip module via the py launcher: > > py -m pip install <> thanks. i uninstalled and re-ininstalled with option to add python to my path. It works now. I could have simply added the python path to env variable but i did not realize the issue then. Thanks a lot -- https://mail.python.org/mailman/listinfo/python-list
Re: Leading 0's syntax error in datetime.date module (Python 3.6)
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. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: issue runing ipython
On Fri, 11 May 2018 20:13:08 -0700, Sharan Basappa wrote:
> I see an issue while running ipython. Can anyone help please.
Is the error message not clear enough? It tells you what the problem is
("ipython notebook" is deprecated) and tells you how to fix it (use
"jupyter notebook" instead).
> D:\Users\sharanb>ipython notebook
> [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is
> deprecated and will be removed in future versions. [TerminalIPythonApp]
> WARNING | You likely want to use `jupyter notebook` in the future
> Traceback (most recent call last):
> File
> "d:\users\sharanb\appdata\local\programs\python\python37-32\lib
\runpy.py",
> line 193, in _run_module_as_main
> "__main__", mod_spec)
> File "d:\users\sharanb\appdata\l
I don't know what more there is to say that the error message doesn't
already say. Have you tried running "jupyter notebook" instead? What
happens?
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for a "data" object syntax
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. * It works with any editor, including simple ones. * It is safe for transmit over email, or on web forums, so long as you avoid tabs and use spaces. * It is readable by humans without them needing to distinguish between two different kinds of invisible space. * It can be easily parsed by hand or by machine. * It works with a multitude of text processing tools whether or not they can cope with tabs. * It is resistant to many sorts of typos. * It allows great flexibility in the presentation, you aren't forced to lay things out in one specific 2D format. * It uses the same consistent rules for the rest of the language, without adding special cases and complexity. * 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. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Meaning of abbreviated terms
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
