81–90 of 180 posts
Earlier quoted context omitted.
Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))
I strongly dislike python, I often wonder if it would have been as popular if Guido didn't work at Google early on.
Earlier quoted context omitted.
Anything remotely interesting like that is dumped in itertools. Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known. Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to…
Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))
arrow(my_list [map args] [filter args] [filter args] [map args] [sum])
arrow(my_list [map map_func arrow.list_here])
Earlier quoted context omitted.
Anything remotely interesting like that is dumped in itertools. Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known. Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to…
Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))
Yeah, one thing I like about Ruby over Python is the fluent code th former allows of that style.
People talk about Guido not liking functional style, but that explains comprehensions over map/filter, but not function-sum() over method .sum().
Earlier quoted context omitted.
> things like `.append` changing the object, returning `None` instead of creating a copy and returning that The obvious question is why it can't return a reference to the list instead of returning None. I feel like if I've been using the language on an almost daily basis for ten years now and I still get burned by that all the time, then it's just a poorly designed feature.
random.shuffle() has bitten me that way a few times too: array = random.shuffle(array) because I expected it to return a copy or reference, instead making my array None. It would also enable chaining operations: array = array.append(A).append(B).sort() In-place vs immutable copy is a language design choice with tradeoffs on both sides, but there's no reason that I can see to not return a reference to the list. Perhap…
xs.sort() # in-place
ys = sorted(xs) # copy
with array do
begin
append(A);
append(B);
sort;
end;
array append(A); append(B); sort.
I am a pretty average Python programmer(5 years teaching, 15 years writing). I still wonder what was the reasoning for allowing creation of local objects with the same name as builtins. Okay it can be nice to redefine pprint as print I suppose. Still how many sum, list, min, max, dict(!) have been erroneously redefined in beginner tutorials and beginner code. From my experience sum and list suffer the most. Sure ther…
Cute fact about __debug__: it is one of the only ways to get compile-time conditionals in Python. Performing a comparison with `if __debug__:` will output byte code for the ensuing statement if and only if the interpreter is in debug mode - notably, in `-O` mode, it will not even generate a load of __debug__ and a conditional jump, and acts as if the statement didn’t exist at all.
We still have -X dev and sys.flags but it's runtime only.
You know what helped me with python? Breakpoints inside vscode's module. It all just kinda clicked.
python actually has a build-in `breakpoint()` function. I think it brings up a repl at the line. I've been using that instead of print debug, it's been great.
Earlier quoted context omitted.
In a way, learning Python is harder for people experienced with another language because so much of the content you find is for first-time programmers. That said, I think I had good luck with Writing Idiomatic Python.
Yes! When I learned Kotlin, I just read through the docs, and then knew of basically all the different concepts in the language. For Python, the docs were comparably very bad. For instance, Decorators aren't mentioned even once in the "The Python Tutorial". In "The Python Language Reference" (if one even bother to read such a dry document) it's barely mentioned in passing. How should a new user know it's a concept an…
Earlier quoted context omitted.
Anything remotely interesting like that is dumped in itertools. Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known. Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to…
> "I value readability and usefulness for real code" Amen. There are plenty of languages where your code ends up looking like an entry in an obfuscation competition without even trying. If you're using Python, and working for me, I expect the code to be readable by anyone. And, no, I don't give a toss whether the code is three times the length it might have been if it was dangerously, and expensively, obscure.
Like, which of these make more sense?
strList.filter(isNumeric).map(parseInt).filter(x => x != 0)
[ x for x in [ parseInt(s) for s in strList if isNumeric(s) ] if x != 0]
filter(map(filter(strList, isNumeric), parseInt), lambda x: x != 0)
And it's not like Python doesn't have the language features to implement the first pattern. Map,reduce,filter,etc. could simply be added to the iterable base class and be automatically usable for all lists, generators and more.
Cute fact about __debug__: it is one of the only ways to get compile-time conditionals in Python. Performing a comparison with `if __debug__:` will output byte code for the ensuing statement if and only if the interpreter is in debug mode - notably, in `-O` mode, it will not even generate a load of __debug__ and a conditional jump, and acts as if the statement didn’t exist at all.
Unfortunatly you often can't use -o because of the 3rd party libs that didnt' get the memo and use assert for error checking. We still have -X dev and sys.flags but it's runtime only.