On Sat, 29 Oct 2016 10:53 pm, BartC wrote: > On 29/10/2016 02:04, Steve D'Aprano wrote: >> On Fri, 28 Oct 2016 05:09 am, BartC wrote: > >>> For years I've had discussions in comp.lang.c about things that C should >>> or should not have. > >> Bart, don't be naive. The C language isn't going to "acquire a slick new >> enhancement" based on a few emails on compl.lang.c. C is an ISO-standard. >> Stability of the language, > > C is a supposedly ultra-portable and apparently simple language.
I'm not sure if C *ever* was simple, but it certainly hasn't been simple for the last quarter of a century. The most recent version of the standard has a draft of 701 pages: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf The draft for the previous standard, C99, was 552 pages: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf See also: http://www.open-std.org/jtc1/sc22/wg14/www/standards http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents Here's a draft of ANSI C (C89): http://flash-gordon.me.uk/ansi.c.txt My browser formats that to 290 pages. So even in 1989, C was significantly complex. [...] > The language and the way it's used have a few problems - why shouldn't > someone talk about them? Nobody is stopping you from discussing C's problems in the appropriate forum. But unlike you and your hand-made compilers, with a user-base of exactly 1 user (you), there are dozens of implementations of C, with tens of thousands of users or more, and an ISO standard defining what is and isn't C. > the fact that you have a known set of >> functionality, is precisely why it was made a standard in the first >> place: to discourage the sort of "wouldn't it be cool if..." pile up of >> features and bloat and ever-changing language specs. > > Most of the enhancements I talked about were trivial. The language is > unlikely to change because of me but it would be nice for someone to > acknowledge them rather than defend one of C's crazy quirks or lack of a > feature to the death. You won't get any defence of C's crazy quirks from me. [...] > But I'd like to see Python running on a 64KB system > (Micropython doesn't count!). Hmmm. So tell me... how do you expect Python to run on tiny systems by *adding* new features? Regardless of how "small" this feature is, it is not negative size. The implementation is at least 1 byte. The documentation is at least 1 byte. The tests are at least 1 byte. If you think Python is too big now, then adding this feature will make it at least 3 bytes bigger. >>> I think this came up when someone wanted to switch from Visual Basic to >>> Python. The above is not a very sophisticated approach but it is very >>> simple and intuitive. >> >> Intuitive to whom? To me, it just looks weird. > > 'read a,b,c' is weird and unintuitive compared with its counterpart > 'print a,b,c'. OK.... print as a statement was always an anomaly, and yes, it got pretty weird: print >>sys.stderr, spam, eggs So much nicer now that it is a function that takes proper keyword arguments. In any case, I wasn't specifically talking about read a, b, c Yes, it is a bit (actually a lot) unusual to assign a value to a variable by way of a statement other than assignment, it is not unprecedented in Python. We have at least three other binding statements: import name for name in ... del name even though one of them is actually an *unbinding* statement. What I said looked weird was your syntax: read a:"h", b:"r", c:"s" If you're going to introduce special syntax for types, why make the types strings rather than symbols? > BTW what does reading three integers from the user look like in Python? for i in range(3): n = int(input("")) You want a prompt? Change the empty string to your prompt. You want to assign to three different variables? Unroll the loop: n = int(input("")) p = int(input("")) q = int(input("")) If the user types something that isn't an integer, you want to try again? Write a loop. If you're sensible, of course you will put it into a helper function: _SENTINEL = object() def read_int_with_all_the_trimmings( prompt1='Enter an int: ', prompt2='Invalid value for an int; please try again: ', prompt3='Value out of range; please try again: ', max_times=2**31, low=None, high=None, default=_SENTINEL): msg = prompt1 for attempt in range(max_times): s = input(msg) try: n = int(s) except ValueError: msg = prompt2 else: out_of_range = (low is not None and n < low) or ( high is not None and n > high) if out_of_range: msg = prompt3 else: return n if default is _SENTINEL: raise ValueError('not a valid int') return default Does your `read` statement do all that? Why not? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
