131–140 of 381 posts
Earlier quoted context omitted.
After a quick read through, I personally find this syntax much harder to read using operator overloads than it would have been using a series of comparison functions. Tilde is a very obtuse operator and I don't know that this really buys you anything. Feels like a case of preferring cleverness over readability/usability/maintainability.
Exactly the road C++ tries to go down. How's that for a ringing endorsement?
Earlier quoted context omitted.
> which itself is a result of limiting ourselves to the ASCII symbols that can be typed I think we're ready for programming languages using some visually good Unicode characters, instead of overloading `[]{}!@#$%^&*()-_/` for everything!
Oh god, this. I want a language that as I type, != Gets replaced with a proper ≠ not equals sign and proper symbols for AND, OR, and NOT.
As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
> As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. Python is a fairly old, mature language. What features would you have been especially excited about?
Earlier quoted context omitted.
The issue, in my opinion, is when you want something like this: while m := f(many, args): # do stuff with m Now, if you're writing this in Python 3.7, you often end up with some code duplication: m = f(many, args) while m: # do stuff with m m = f(many, args) # duplicate Or something like this: while True: m = f(many, args) if not m: break # do stuff with m Personally, I consider the last version to be the most elegan…
Why not something like this: def f_iter(many, args): while True: m = f(many, args) if m: yield m else: raise StopIteration ... for m in f_iter(many, args): # do stuff with m This way you’re isolating all the initialization logic, error handling, etc. And you can focus on your domain logic in your client code.
for m in filter([re.match(...)], bool):
...
Earlier quoted context omitted.
The Mac has provided easy access to symbols since 1984, with nice mnemonics like these: option-= ≠ option- ≥ option-/ ÷ option-o ø option-w ∑ I don't know why other OSes haven't adopted something similar. The first couple of these were even idiomatic in HyperCard's scripting language.
That's like visual puns, and is limited to whatever symbols seemed important to the developer at the time. How do you discover how to type ß, °, «, ‡ etc? Android's gboard uses phonetics (long press [s] key for ß), symbolic similarity (long press [*] key for ‡) and visual similarity (long press [<] key for «) which is guessable for some symbols, but isn't discoverable for others (you can search for emoji by name, but…
Disappointing that Python sill has no support for a sorted container in its standard library, akin to C++ `set` or `map` classes.
But it does have a method to sort containers in its standard library, `sorted`, that C++ doesn't have. And it's trivial to use it to sort lists, sets, and dicts...
> The typing module incorporates several new features: > A dictionary type with per-key types. Ah, I've been waiting for this. I've been able to use Python's optional types pretty much everywhere except for dictionaries that are used as pseudo-objects, which is a fairly common pattern in Python. This should patch that hole nicely.
It was a major missed opportunity to provide a properly duck-typed Dict type, which by definition would allow untyped key-value pairs to be added to a "partially-typed" dictionary.
Gradual typing in general is a massive win for many kinds of real-world problem solving, but when you make it as hard as Python has to introduce partial types to a plain data object, you're leaving a lot of developers out in the cold.
I love MyPy and the static type hints since 3.6, but structural subtyping is superior and so obviously more Pythonic than nominal, yet support for structural subtyping keeps lagging behind.
Earlier quoted context omitted.
That's like visual puns, and is limited to whatever symbols seemed important to the developer at the time. How do you discover how to type ß, °, «, ‡ etc? Android's gboard uses phonetics (long press [s] key for ß), symbolic similarity (long press [*] key for ‡) and visual similarity (long press [<] key for «) which is guessable for some symbols, but isn't discoverable for others (you can search for emoji by name, but…
The Mac has had, as a standard feature for decades, an on-screen keyboard to allow you to explore the results of different key combinations. It’s a great tool.
This is the release that contains the controversial assignment expressions, which sparked the debate that convinced GvR to quit as BDFL. They didn't select my preferred syntax, but I'm still looking forward to using assignment expressions for testing my re.match() objects. I haven't used 3.8.0 yet but I hope its a good one because 2020 is the year that 2.7 dies and there will be a lot of people switching.
Because of the luddites at RedHat, Python2.7 isn't actually dead until 2024. It's infuriating. https://access.redhat.com/solutions/4455511