161–170 of 242 posts
Earlier quoted context omitted.
I can tell that proper Unicode support is a reason to discounting a language/library if you're not a native English speaker and/or writing programs that have to be localized.
Python was created by a non-native English speaker.
That pretty much reiterates my points from last time we discussed (not many hours ago). https://news.ycombinator.com/item?id=7801004 Besides what already was said. It is also important to emphasize that Python 2 is already pretty good. So it is not that Python 3 is bad, it is just that it is very hard to improve on 2. Ironing out the warts is good, but this was not the right time. This should have happened 7-10 years…
Exactly. Python and JavaScript is a perfect demonstration of "worse is better". Python 2 is a vastly better language than JS, avoiding nearly all of its design misfeatures and having actually useful built-in types and standard libraries. Yet while Python spent a decade to go from 95 to 99 percent purity, JS took over the world through sheer ubiquity.
Edit: Asked on twitter for any work on this: https://twitter.com/alexchamberlain/status/47126815887225241...
Earlier quoted context omitted.
I'm using Python 3.4. All the libraries I need are available, including the world's best database library, SQLAlchemy. It's a more pleasant experience than Python 2.x. And I have the peace of mind knowing that I'm not stuck on a legacy, deprecated platform. I used to stick up for Python 3 on HN and other places but I've given up. I have no interest in converting people going to Go. And no matter what Python (or any o…
I thought I was alone. I also stopped trying to convert people to Python 3. It is a much better language. By this point, it should be obvious. After taking it for a test lap, and after cursing at forgetting parenthesis on print for the hundredth time, you get it. Anyone who uses python and, by this time, hasn't taken python 3 for a test run isn't worth my advocacy time.
Earlier quoted context omitted.
"People are leaving Python for Go because people have always left Python for fast compiled languages." I think the angst about Go comes from the fact that someone who leaves Python for Java may still come back, because you can develop far more quickly in Python than Java. But someone who leaves Python for Go probably isn't coming back... my experience is that it is slightly slower (10-20%, YMMV but we're certainly no…
My experience was Go was about 2-3x slower (development speed) than Python for prototyping. Web programming, though, which is a particular strength of Python and a particular weakness of Go. YMMV, of course. I actually really do miss list comprehensions and properties and pervasive protocols for built-in types and really concise keyword/literal syntax. I don't miss metaclasses, and I only vaguely miss decorators. (Go…
http://legacy.python.org/dev/peps/pep-3000/ Wow... that was 2006. Everything I've read in the PEP and mailing lists seems to imply that the contributors were doing their best to limit the scope of the backwards-incompatible changes to those parts that were deemed absolutely necessary. The point wasn't to break backwards compatibility to add new, competitive features. It was to make the incremental improvements to the…
Well, whose problem is it? Most people use Python in order to solve problems they have. If Python 2 solves their problems better than Python 3, they'll use Python 2. (And yes, "solves their problems better" includes "lets them continue to use an already-existing solution that works fine.") If the people developing Python want other people to use Python 3, they need to make it better than other ways of accomplishing t…
One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place. It was all fine once I got it worked out but it would so…
I recently tried to deploy a desktop app written in Python. It was a nightmare. I recently taught scientific Python to prospective switchers. The installation step was a nightmare. We really need pip wheels or conda to become mainstream. Pip alone doesn't cut it on platforms without compilers (Windows / OSX). Standalone installers are fine, but they don't resolve dependencies and they are only available for Windows.…
Earlier quoted context omitted.
If it were only syntax, 2to3 would be the answer. Exceptions and Print are not the problem. Migrating unicode-aware code and CPython extensions is a much bigger task, and incidentally, much more useful. nonlocal, asyncio, unicode, yield from. If you ask me, these four are very compelling reasons to switch to Python 3 and they solve very real problems.
There are not so terrible workarounds for all the things you mentioned. While Py3K does them better, they are still not reasons to update. As the article points out, there isn't a compelling reason other than slightly cleaner code. The community agrees as evidenced by the massive push back.
There are not so terrible workarounds for things like closures and memory management in C. While Python does them better, they are not reasons to update.
There will always be neophiles and neophobes...
Earlier quoted context omitted.
Python was created by a non-native English speaker.
I know that. I'm Italian, and Western European Languages can be expressed on a 1-byte character type. I also understand that the performance gain of 1 byte char was significant. But now is 2014 and not to have to wrestle with encodings definitely worth the performance and (somewhat) complexity hit. As a unrelated (to Python) example of the encoding nightmare: have you ever tried to import text from CSV files generate…
Earlier quoted context omitted.
No matter how fast the OS can spin up another process, you still have to contend with the overhead of Python initialization itself. And I don't quite understand what you mean by the "full number tower".
> No matter how fast the OS can spin up another process, you still have to contend with the overhead of Python initialization itself. Good point... but isn't part of that possible to reduce a little when python itself forks? I've not looked at the code, that might very well not be what happens when you use the multiprocess-module? > And I don't quite understand what you mean by the "full number tower". I was thinking…
Earlier quoted context omitted.
Not necessarily. pip cannot resolve all dependencies. For example, if a package specifies both numpy and pandas as a requirement, installation will fail. This is because pandas in turn requires numpy, and pip does not resolve the dependencies in a single step, you need to install numpy first and then go on with pandas.
In that case, couldn't you just specify Pandas as a dependency and Numpy would automatically be installed?
See https://github.com/pypa/pip/issues/1386 (oddly, the issue is closed, while the problem is acknowledged).