121–130 of 172 posts
Earlier quoted context omitted.
True, I meant this https://pypi.python.org/pypi/pep8
Guido doesn't like that tool; they're guidelines, not rules.
Yes, a lot of people need to get that memo
I don't like it as well, but it keeps a group of developers in check. And it can be configured, so there's that as well
Too bad autopep8 produces bad results out of the box
Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…
`print` statement is not a big deal for me. But one thing that especially annoys me is the functions in the module `itertools`. In Python 2, I use `itertools.izip` or `itertools.imap` a lot, because I'd like to avoid creating a large list only to iterate over once. When I tried migrating to Python 3, I found out that these functions are gone, and I was supposed to use plain `zip` and `map` instead. I was furious. How…
Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…
Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…
To me this is the main pain point and I'm surprised that people are not talking about this.
2to3 and 3to2 are too kludgy and writing native py2-and-py3 compatible code is quite painful and requires a number of workarounds (e.g. unicode/str/bytes type, different methods on dictionaries...)
Earlier quoted context omitted.
I always found it weird that python functions quite happily tell you that you're missing a colon, but can't 'just run' without it. Excluding one-liner syntax, why does Python actually need a colon to define a function, given it's goal of being free of unnecessary syntactic elements? I'm only an intermediate pythonista, but I'd be interested to know if there was a particular point to the colon.
It doesn't, it just is easier to scan. There isn't a goal of being completely free of syntactic elements, semicolons went because they were excessive and noisey, colons seem, at least to me (comparing with say, coffeescript) to make it less noisey.
Namely, Python3 is sufficiently different for applications supporting distributions.
If you are doing Software-as-a-Service hosted webapps, fine, you can choose your platform, but if you are shipping software, you have to make concious choices about usually supporting what the distros have.
And the Linux distros are inconsistent.
This problem sounds solveable by saying "users, install a newer Python", though this seldom is effective -- and long lifetimes of things such as RHEL 5 (yes, still afield - and some folks have to support version 2) ship versions that are less compatible with Python 3 compatible hacks than newer Pythons.
As a result, this intent to "clean things up", I feel, has massively undercut Python's growth rate. Maybe it's not declining, but there's been what feels to be an inflection point.
I suppose looking at download curves for hundreds of long-standing PyPi projects relative to the growth rates of other systems could provide this is a thing or not.
Anyway, I do love Python. The problem is not the GIL. Most folks who are making web services get by far with a pre-forking webserver (mod_wsgi, etc) and something like celery for backend jobs. multiprocessing is ok enough for some other cases.
It doesn't matter whether Python 3 is attractive so much, and that's what I mean about a decision point - the confusion gave people a chance to shop around, and some people are trying things in other languages now.
For instance, Go seems misapplied - it has a different expressiveness and domain area. I'm writing a fair amount of clojure, which also feels a bit more low level (sometimes, just in places). But I felt compelled to look around.
The crux of the theory is this - changing something singificantly will allow people the opportunity to think is this something they still want to do.
I still believe Python strikes a great balance between expressiveness and readability, and it's surpression of "clever" in programming makes it ideal for a lot of problem domains. And it's kind of old enough that people are going to want to look around.
Still, I begin to feel some of the directions being made in 3 are out of touch, just as the resistance to some more expressive language features (crippled lambdas, I vaguely recall) were that way. This happens when those that write the language don't neccessarily use the language, and the (percieved) BFDL approach of "fixing regrets" I am not sure it looks after the good of the whole, the way the 2->3 transition happened. Those should have been evolved slowly, keeping things compatible, rather than creating what is essentially a new language.
I'm still pleasantly surprised by how widely deployed Python is to the rate at which people talk about it (say, vs Rails), I think a lot of that is because it's NOT complicated, and you don't need to talk about it so much. It's a quiet workhorse.
But I've also started new projects in Python 2 - because I've needed them to work everywhere. Python 3 is almost sort of having the Perl 6 stigma to it in my mind, it's available now, but it's made a compatible break that has shaken trust.
Since Python 2 is essentially the deployed standard, there's no real reason for most apps that must be distro installable to work on hybrid support - until the distros move to a version that makes it easier to be compatible, it's more important to support where the users are than risk possible bugs and implementation trouble. Resources are better spent elsewhere.
Earlier quoted context omitted.
> There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me.
> Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me. Can you elaborate on this? Unicode processing is the same on 2.x and 3.x for the most part. There are some differences in interpreter internals, how string literals are represented and the internal representation was changed (and obviously the literal defaults and bytestrings were removed), but other…
Or you write a logfile parser and it works great for half a year, until in March where you get an UnicodeEncodeError because March is "März" in German, the only month with an Umlaut.
GIL seems to me to be only a niche problem in reality. But it is a bit of a storm in a powerpoint (i.e. people see it on a list of features of python and panic. Even though, as the article says, Javascript has much more constrained single-threadedness). I've been deploying python for almost 20 years, and I haven't had a single performance issue that was caused by GIL and couldn't easily be worked around. In my experi…
Disclaimer: I used both Python and Node.js at job, and use Node.js regularly for side projects. I think the difference is that Node embraces the single-threadedness as part of its architecture. I don't use Python that much now so I'm not sure if it's changed, but I found it clumsier by default. I know there's Twisted and other nice evented/multiprocess libraries that make Python closer to Node, but it surprises me th…
So yeah, the GIL is not an issue there. You'll just want something like celery for backend jobs, which is nice because it also maintains job state/info that survives process death - which globals in twisted won't do for you.
So, basically, it's a much more resilient way to do thngs, particularly if the front end of your application is request driven. Doesn't fit all models though.
(Also, Django + Django REST Framework is pretty awesome).
Earlier quoted context omitted.
Yeah, perhaps your experience in your office is not generally representative? In PIP, Python 3 has like 5% uptake...
What do you mean with "In PIP"? Are only 5% of the pip downloads from Python 3? That would make sense seeing as pip is included in Python 3.4, so there no need to download it. If you mean that only 5% of the packages on pypi.python.org is Python 3, I would say that sound a bit low. Also unimportant for most, if it's just the correct 5%. There's also a ton of old cruft on pypi.python.org that would count against Pytho…
I was talking about versions of Python used to download packages off of PyPI (with pip et al).
As of 2014/1, those accounted for https://alexgaynor.net/2014/jan/03/pypi-download-statistics/
Earlier quoted context omitted.
What do you mean with "In PIP"? Are only 5% of the pip downloads from Python 3? That would make sense seeing as pip is included in Python 3.4, so there no need to download it. If you mean that only 5% of the packages on pypi.python.org is Python 3, I would say that sound a bit low. Also unimportant for most, if it's just the correct 5%. There's also a ton of old cruft on pypi.python.org that would count against Pytho…
Neither downloads of PIP, nor packages in PyPI. I was talking about versions of Python used to download packages off of PyPI (with pip et al). As of 2014/1, those accounted for https://alexgaynor.net/2014/jan/03/pypi-download-statistics/
Still I don't see much reason to not switch at this point. I don't believe that most developers would be missing anything.
Small note: We run our own pypi server for a large number of packages, so our Python 3 installations aren't counted for everything, but the same should be true for many Python 2 setups.