Python 2.x vs 3.x use survey
41–50 of 119 posts
Re: Python 2.x vs 3.x use survey
#42The survey is missing sets of answers for users who rejected or moved away from python because they were turned off by the disconnect between core devs and the community when python 3 got released.
I can't say I understand this attitude. It's analogous to cutting off your nose to spite your face. Both Python 2 and 3 are actively supported, and there's a clear migration path defined. The migration isn't complete yet, but it's progressing at a development friendly pace. I say this as someone still on Python 2.6 due to environment restrictions.
Re: Python 2.x vs 3.x use survey
#43"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 wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation. I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.
- 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". My entire office has switched to Python 3 for everything.
Re: Python 2.x vs 3.x use survey
#44"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 wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation. I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.
Not to mention pip and package management - which compared to ruby, is just terrible. I mean there isn't even an update all command in pip. And of course if you have different versions of python you have different versions of pip. With different version of packages installed.
And now for virtualenv. Ok great tool. But even in this area there's confusion. Different people use different environment managers. And virtualenv isn't the easiest thing to setup - from a new users point of view. Where in ruby there's gem. It's installed with ruby. Period.
The community isn't doing itself any favors by dragging their feet. Everyone should jump onboard the python3 wagon. And if you need a package that isn't 3, then rewrite or look for something else. Maybe if the maintainers of said packages knew that their users weren't gonna stand for not supporting version 3 they'd get off their butts and convert - or release the code and let the community convert the package for them.
Re: Python 2.x vs 3.x use survey
#45Earlier quoted context omitted.
no trailing space is a convenient shorthand - print by itself prints with a newline (so it might make sense to have print() vs println()); print + comma omits the newline and waits for the next print statement, so that print 'hi', do_something() print 'there' and print 'hi', 'there' both yield hi there (Assuming do_something() doesn't call print itself)
FWIW: pprint = functools.partial(print, end=' ') pprint('hi') do_something() print('there') print('hi', 'there', sep=' ') I appreciate the fine grained control, and the ability to do things like `functools.partial` on it. fprint = functools.partial(print, file='/var/log/foo.log') fprint("I'm writing to a file!") fprint("So am I")
Re: Python 2.x vs 3.x use survey
#46Dear Apple. Please include python 3 as /usr/bin/python3 in all future Releases. And Microsoft, if you're listening, it would be extremely sweet if you would install python by default as well...
Re: Python 2.x vs 3.x use survey
#47The 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...
The override is easy:
pymap=map
def map(...)...
(and maybe for calculator style usage you would name your list returning map and range m and r, which would also help with not confusing them with the usual behavior)Re: Python 2.x vs 3.x use survey
#48Re: Python 2.x vs 3.x use survey
#49Re: Python 2.x vs 3.x use survey
#50Earlier quoted context omitted.
I wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation. I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.
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".…
one single dependency that doesn't support py3 is the death knell to using it for anything, EVER
I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed.
(we use pyramid not django for what it's worth)