This is a tired, trolling post. Most of these issues have long been addressed as non-problems or personal preferences; when the author says "Incompetence? Politics?" what I hear is "people don't listen to me, probably because I don't know what I'm talking about". The attitude is confirmed by his/her conflating of stdlib gripes and language gripes - two very different sets of problems - and mixing requests for speed with requests for more lambda support, two things that are notoriously unlikely to go hand-in-hand.
Problems I Have with Python
61–70 of 239 posts
Re: Problems I Have with Python
#62I honestly don't get why they made the big compatibility-breaking move to Python 3 without using that opportunity to change things for better performance and no GIL.
Re: Problems I Have with Python
#63Earlier quoted context omitted.
You need to use the asyncio (or equivalent) event loop if you want to use the asnycio module. loop.run_until_complete() is synchronous though, so you would simply call that and it will block the control flow despite that function being async. You can definitely mix it with legacy code. I would recommend against it, but if you had an existing framework, you could just make the endpoints lambdas that are something like…
^ this, but be aware that it's only worth it if you do > 1 external call in parallel. I.E this is pointless: res = await get('https://somesite.com') return Response(res['data']) As you'd get the same thing if you just did it synchronously (without the await). But if you want to fetch 2 or more pages in parallel when it really pays off.
Yeah, absolutely. I am not a fan of mixing synchronous and asynchronous code, but the design of asyncio makes it very easy to do. I think that most people struggling with the concept don't realize that asyncio is inherently blocking when its being used (well, with the caveat of run_in_executor, but that's best left ignored for the purposes here)
Re: Problems I Have with Python
#64Earlier quoted context omitted.
> Very short-sightedly written. It sounds like the author just wants a language with a different philosophy Which is not a priori bad to want, especially if a language has a broken philosophy (or partially broken) to begin with.
The only way I see a philosophy as being a broken one if it is founded on false premises, or internally inconsistent (or do you see a different way?). Which is the case with Python and why?
A philosophy should also be considered broken if it is not useful for any purpose.
By extension, it could also be considered broken if it is needlessly less useful than it could be for its intended purpose.
Re: Problems I Have with Python
#65Personally I'd love to see pattern matching / de-structuring of dicts and strings:
foobar = "foo{}".format("bar")
foo = "{}bar".unformat(foobar)
def dict_returner():
return {'foo': 1, 'bar': 2, 'foobar': 3}
{'foo': newvar1, 'bar': foo} = dict_returner()
An extension to that providing a set of keys would be nice, too:
foo_and_bar = dict_returner(){'foo', 'bar'}Re: Problems I Have with Python
#66Earlier quoted context omitted.
> Very short-sightedly written. It sounds like the author just wants a language with a different philosophy Which is not a priori bad to want, especially if a language has a broken philosophy (or partially broken) to begin with.
The only way I see a philosophy as being a broken one if it is founded on false premises, or internally inconsistent (or do you see a different way?). Which is the case with Python and why?
Instead of philosophy what you say applies more to logical statements (they are broken if they are founded on false premises or are internally inconsistent).
A philosophy is more malleable and ad-hoc than axiomatic logical statements, and it can just be bad because it doesn't offer satisfactory solutions the problems it claims to have tackled, or because it sidesteps certain things, etc.
But even that is taking the "broken philosophy" allegation too literally. The author simply means that Python would be a better language if it offered more capable closures and more easy access to functional programming.
And why one might argue about the "better", there's no arguing that Python would be more expressive if it did so.
Re: Problems I Have with Python
#67Earlier quoted context omitted.
Less verbose. Also, what happens if you have even more nested lists you want to flatten? Personally I think it should just be flatten(range(i) or i in range(5)) With flatten in the global namespace
Given that flatten is surprisingly tricky to get right, it really should be built-in. The naive recursive variant will crash python if you nest lists beyond the stack limit, which is very no bueno. A list that's nested 10,000 layers deep is not especially hard to create or store in memory, and a flatten implementation should be able to handle it without crashing the interpreter. In fact, it's not a bad little program…
I've not tried, but you can probably get that by recursively mixing standard constructs and functools.chain.from_iterable().
Re: Problems I Have with Python
#68The problem I have with Python is that for loops don't have their own scope, only methods. Add that to the lack of variable declarations (even optional ones, a la my in perl, var in javascript), and it gets hard to work out what scope of any given variable actually is. Surprising example: fns = [] for n in [1,2,3,4]: def fn(): print(n) fns.append(fn) for fn in fns: fn()
But doesn't this just happen because n is a pointer? What would you expect it to print? 1,2,3,4?
In Lua it prints 1,2,3,4. It has to do with each loop iteration behaving as if it declared a different variable instead of sharing the same variable across the loop.
Anyway, the problem they were talking about is clearer when you are closing over stuff that other than the loop variable:
fns = []
for n in [1,2,3,4]:
x = n*10
def fn():
print(x)
fns.append(fn)Re: Problems I Have with Python
#69A language as old and as large and as flexible as Python ends up with a few wrinkles, but designing a successful languages isn't easy and I really admire the work done by everyone behind Python, especially the vision and invention by Guido van Rossum.
A kind of post-experience review of a language's strengths and weaknesses is a good exercise. For comments and complaints that really were influential in the history of programming languages see:
Knuth, The remaining trouble spots in Algol 60, Communications of the ACM, 10, 10, 1967, pp. 611--617. https://www.cs.virginia.edu/~asb/teaching/cs415-fall05/docs/...
J. Welsh, W. J. Sneeringer, C. A. R. Hoare, Ambiguities and insecurities in Pascal, 7, 6, November 1977, pp. 685--696. http://onlinelibrary.wiley.com/doi/10.1002/spe.4380070604/ab...
Brian W. Kernighan, Why Pascal is not my favorite programming language, April 2, 1981, AT&T Bell Laboratories. http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pasc...
Re: Problems I Have with Python
#70> The standard interpreter bring rather slow; I'm tired about this one. In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there. I've been hearing this argument for ever. PHP is sl…
"No. Python 3 arrived quickly after many warnings. Then tools, tutorials and a looooooooooooot of time have been provided.
This is nowhere Python's fault. It's the best damn migration story I've ever witnessed in my life.
My only grudge on Python 3 is that it didn't break ENOUGH. I wished for stuff to have changed more."
I think you wrote a good comment, thanks!, but regarding 2 to 3, I think you got this wrong. I think a more gradual transition would have helped - people ended up putting off the porting work, which was easy because Python 3 was installable in parallel, and nobody was really using it etc., and then it really went dead for some years, which I think was counter-productive for everyone.
I think in general it's better to keep some compatibility glue code around until most people have migrated instead of letting a let's-clean-this-shit-up! frenzy prevail.
(Now hindsight is everything, etc. etc.)