Care to show proof? I don't see this a lot.
The code of the official Django site for example has 8 occurences: https://github.com/django/djangoproject.com/search?q=super+_...
21–30 of 156 posts
Care to show proof? I don't see this a lot.
The code of the official Django site for example has 8 occurences: https://github.com/django/djangoproject.com/search?q=super+_...
> The syntax for classical inheritance. Half of each Django app is super().__init__(args, *kwargs). At least you don't have to pass arguments to super anymore.
Yes, inheritance is hard to do well, but that's generally true. Much better to prefer composition (https://en.wikipedia.org/wiki/Composition_over_inheritance)
> Too many magic __double-underscore__ methods and properties that you have to just memorize.
Better to just start using http://attrs.org or dataclasses so you don't have to do all the manual work. Classes without boilerplate.
> Too many top-level built-in functions that (a) you have to just memorize, and (b) get really ugly. You end up with stuff like list(map(...)). I haven't used so many nested parentheses since my early days in PHP. Guido's explanation makes sense in theory, but is really annoying in practice.
I agree, there should be a pipeline operator |> like F# has. A similar proposal has been made for JS. https://github.com/tc39/proposal-pipeline-operator
> Too many other weirdo bits of magic syntax, like [list comprehensions].
List comprehensions are good, they just take 5 minutes of getting used to.
> Django specifically is so full of magic words, and its documentation is so convoluted, that I've basically given up on documentation altogether and just look at the Django source code now.
Pyramid has a much more principled design IMHO. https://trypyramid.com/
> Needing to put dict property names `{'in': 'quotes'}.
Or use `dict(foo=5)`. Python mappings can contain non-string keys, so `{5: 1.2, 6: 3.4}` maps ints to floats.
> You have to cast your data back to a list/tuple after using enumerate() and map().
Don't use map, use comprehensions.
> Different syntaxes for lists and tuples.
They are different objects, why would they have the same syntax?
> foo['bar'] returns a KeyError, so you have to do foo.get('bar')... or in some cases getattr(foo, 'bar', None), but not in others because getattr and .get are different things.
Python is a different language from Javascript.
> You can't just tack on flags to /regular_expressions/ig.
Yeah that's annoying.
> All the goofy string literals: f' ', u' ', r' ', etc.
That's a good thing, not a bad thing.
> Pipfile does not work that well.
Poetry works better. https://poetry.eustace.io
This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously without actually proposing how comprehensions could be made better one has to hope the author would say he likes the equivalent Haskell better, but there is a strong doubt that is not the case.
Complaining about having to cast generators to list... seems like the kind of dev that has their code randomly run out of memory until a senior dev comes and fixes it.
Generators should be treatable as lazy lists in the end, and lists should have a common interface whether they are lazy or eager. Someone should figure out a way to have us write code at a higher abstraction level and have same interface for lazy vs eager data structures.
...but it's not gonna happen in a dynamic language like Python. And I can't say I like the "solution" of having the entire language be lazy like Haskell either :|
We're stuck with "casting generators" for now, I guess, but it really does suck!
This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously without actually proposing how comprehensions could be made better one has to hope the author would say he likes the equivalent Haskell better, but there is a strong doubt that is not the case.
They seem to exist only to do lots of stuff in one single line of code. You end up with totally impenetrable unreadable perl-esq garbage write-once-read-never code that is too clever for its own good. And people say python is easy to learn and good for beginners...!
A better approach would be something like Java Streams/.net Lync/RxX pattern IMO. Explicit, clear, no magic, logical.
I love Rob Pikes idea that is dumb to have scope determined by invisible characters
These all just seem related to syntax, not actual program structure or capabilities. The only program structure thing I see is list comprehensions, which is one of Python's great strengths. Ironically they say Ruby is more pleasant to write, when Ruby has the deepest structural flaws of any dynamic programming language.
As a Python coder going back to 2008, I can see the point the author makes in isolation.
I disagree with the title though. Even though I mostly write Rust, Go, and C anymore, I am fine with digging into Python as needed. I cringe at thoughts of using Ruby or JS
> a big part of my frustration comes from having a JavaScript background Yeah, I thought so when I was reading the list of "problems". In fact, many of those are features (e.g. lists & tuples being different, list comprehensions, lazy evaluation, distinction between maps/dicts and objects, ...) but the author doesn't actually understand them. I hate to sound so negative, I guess I just didn't realize how bad a progra…
Either way, if the number of idiosyncracies in your language is confusing to junior developers it's absolutely something worth considering.