Live data from Hacker News

Python 2.x vs 3.x use survey

surveymonkey.com

91–100 of 119 posts

Re: Python 2.x vs 3.x use survey

#91
post #87
post #80

Earlier quoted context omitted.

Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?

Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.

Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance.

I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.

Re: Python 2.x vs 3.x use survey

#92
post #71

Earlier quoted context omitted.

What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2. Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?

See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings

As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene.

Explicit is better than implicit.

Re: Python 2.x vs 3.x use survey

#93
post #17

The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...

Those things return generators now to avoid wasting memory (you don't need to create possibly humongous list and keep it in memory during the iteration). If you want a list, just do list(your expression). If you forgot about it then do: list(_) as the very next thing. Like this: >>> map(lambda x: x*x, range(1,10)) >>> list(_) [1, 4, 9, 16, 25, 36, 49, 64, 81] Wtp ?

Yeah, it's definitely something that can be worked around, but it's something I don't have to get around in python2, so I keep using python2. Nothing truly major, just a sticky point.

Re: Python 2.x vs 3.x use survey

#94
post #17

The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...

Neither does Python2. $ python Python 2.7.5 (default, Aug 25 2013, 00:04:04) >>> xrange(10) xrange(10) >>> list(_) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

You are definitely correct; it's really the combination of py3 using generators more frequently (which is a definite good thing) with the py3 repl not evaluating them that keeps me going back to py2 for my repl needs. A more fair comparison is with ghci, which expands thunks and runs IO actions when functions return them. As others have pointed out, this can be "dangerous" in the sense of flooding your console with crap (try typing [1..] in ghci; its' annoying, but not the end of the world either), but it's also really convenient when that's what you want. The python2 repl/functions do what I want, and the python3 repl/functions don't, or at least don't often enough that I keep going back to python2 for all my repl needs. Just a random chunk of anecdata, I guess.

Re: Python 2.x vs 3.x use survey

#95
post #91
post #87

Earlier quoted context omitted.

Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.

Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for gre…

It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere. And again, it's a lot of work with no huge payoff.

Re: Python 2.x vs 3.x use survey

#96
post #95
post #91

Earlier quoted context omitted.

Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for gre…

It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere . And again, it's a lot of work with no huge payoff.

>It's more work than it appears.

I completely believe that, and good point about Python 2. I wasn't considering that side of things.

Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)

Re: Python 2.x vs 3.x use survey

#97
post #69

Earlier quoted context omitted.

This isn't actually true anymore for many, many things: - The major scientific/numerical packages support Python 3 (pandas, numpy, scipy). - The best database library supports Python 3 (SQLAlchemy) - A substantial fraction of important support libraries support Python 3 (e.g. lxml, PIL/pillow) - Django supports Python 3 I'm honestly a little confused by people who claim that library support for 3.x "isn't there yet".…

Its all well saying Django supports Python 3, but when you reply on a dependency, such as MySQL connector (which I assume a LOT of Django users will want to use), then Django effectively doesn't work with Python 3.

I just stumbled on PyMySQL[0], who supports Python 3. Is there any issue with using this library, since it seems an obvious solution to this problem?

[0] https://github.com/PyMySQL/PyMySQL/

Re: Python 2.x vs 3.x use survey

#98
post #96
post #95

Earlier quoted context omitted.

It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere . And again, it's a lot of work with no huge payoff.

> It's more work than it appears. I completely believe that, and good point about Python 2. I wasn't considering that side of things. Is it a complicated rewrite, or just big ? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would…

Come join us in #mercurial in Freenode or in mercurial-devel@selenic.com if you're interested in solving this problem.

Re: Python 2.x vs 3.x use survey

#99
post #51
post #25

"Do you think Python 3.x was a mistake?" That's where I stop filling out the survey. And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.

I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea." It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.

Why not the question "Is staying on Python 2.x a mistake?"

The whole survey is bunk. Too much misinformation and misbeliefs regarding Python 3. The only valid informed answers would be from those who've used (or used and failed) >= Py3.3 for something significant.

Re: Python 2.x vs 3.x use survey

#100
I'd also like to see the results. Curious, did you create this survey to see if there would be interest in a long-running Python 2.x fork?

IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.

I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.

Post reply on HN