Live data from Hacker News

Python 3.5.0

python.org

101–110 of 165 posts

Re: Python 3.5.0

#101

Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.

> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

As someone who's bounced back and forth between Python 2 and Python 3, I'm curious about your need of parameter tuple unpacking[0]. I've never encountered it, and after some research I don't understand the use case.

I don't mean to sound like I'm trying to belittle your position, I would like to understand more. The PEP below doesn't seem to do a very good job explaining why people like them, and I'd like to hear a proponents position on the feature.

[0] - https://www.python.org/dev/peps/pep-3113/

Re: Python 3.5.0

#102
post #54

Question - is there any web/api framework that leverages asyncio ? This implicitly also means first class DB/ORM support. Flask, sqlalchemy ,etc seem to be using gevent and py 2.7.

Yes, there is. https://github.com/KeepSafe/aiohttp It's hard to write an asynchronous ORM though. Your options are either to use some existing synchronous ORM (like SQLAlchemy) in a thread pool (`loop.run_in_executor`) or use more low-level db driver: https://github.com/aio-libs/aiopg#example-of-sqlalchemy-opti...

The RethinkDB Python driver works exceptionally well with asyncio.

Re: Python 3.5.0

#103

Could someone explain how to properly install Python 3.5.0 on Ubuntu so that it replaces the system's default Python 3.4.0 as the new default? Installing is the easy part, but I haven't figured out how to also make sure all the libraries that come with Python are also replaced with the 3.5 versions. Thanks!

You probably don't want to do this.

For stability it's best to keep the system managed through packages from the standard repositories. If you install things that are not from the repositories the packaging system won't be able to track dependencies - it will have bad information about some capabilities as some items won't have been installed using the packaging system. Overwriting official system libraries is a common cause of problems.

It's best to only upgrade something when the repository for your release makes it available: it pays to be conservative about the repositories you use, sticking to the standard ones and thinking very carefully about adding any others (e.g PPA's).

If you want 'newer' versions of frameworks/libraries for development then you're better off installing them away from the main system - traditionally that is /usr/local, or using a partitioning system such as chroot.

For Python specifically there's a really nice option of use venv/virtualenv.

Re: Python 3.5.0

#104
post #54

Question - is there any web/api framework that leverages asyncio ? This implicitly also means first class DB/ORM support. Flask, sqlalchemy ,etc seem to be using gevent and py 2.7.

Yes, there is. https://github.com/KeepSafe/aiohttp It's hard to write an asynchronous ORM though. Your options are either to use some existing synchronous ORM (like SQLAlchemy) in a thread pool (`loop.run_in_executor`) or use more low-level db driver: https://github.com/aio-libs/aiopg#example-of-sqlalchemy-opti...

The asyncio example/benchmark snippet I linked above uses peewee-async:

https://peewee-async.readthedocs.org

Re: Python 3.5.0

#105
Python somehow always manages to miss the mark. The new co-routine stuff is a good example. Who can explain to me how I return more than once from the same co-routine? That is what a co-routine is after all no?

Re: Python 3.5.0

#106
post #37
post #15

Earlier quoted context omitted.

I want to see it used for an XML library, since I think node@"name" is a more succinct, and domain-appropriate equivalent for node.attrib.get("name").

I have kind of mixed feelings. The biggest argument against that PEP was that people would use it for things that are very unlike matrix multiplication, which can be confusing. I can kind of see the point there, but on the other hand the @ symbol really is natural for things like what you suggest.

It's a bit of a weak argument when pathlib is in the stdlib: https://www.python.org/dev/peps/pep-0428/#deriving-new-paths

Re: Python 3.5.0

#107

Earlier quoted context omitted.

> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

As someone who's bounced back and forth between Python 2 and Python 3, I'm curious about your need of parameter tuple unpacking[0]. I've never encountered it, and after some research I don't understand the use case. I don't mean to sound like I'm trying to belittle your position, I would like to understand more. The PEP below doesn't seem to do a very good job explaining why people like them, and I'd like to hear a p…

A good example of a use case I can think of would be to pass an (x,y) coordinate pair as a single parameter, and unpack it in the parameter definition. This would save having an extra line that says (x,y) = pt.

Unless I'm missing something, I don't see this as a show stopper personally, and see it as increasing readability.

Re: Python 3.5.0

#108

Earlier quoted context omitted.

> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.

As someone who's bounced back and forth between Python 2 and Python 3, I'm curious about your need of parameter tuple unpacking[0]. I've never encountered it, and after some research I don't understand the use case. I don't mean to sound like I'm trying to belittle your position, I would like to understand more. The PEP below doesn't seem to do a very good job explaining why people like them, and I'd like to hear a p…

I use it like es6 or haskell destructuring. Sure it's a little weak compared to both those implementations, but the tuple case covers enough to be useful.

Re: Python 3.5.0

#109
post #16

PEP 0448 in addition to already implemented PEP 3132 make it very tempting to switch. If PEP 0448 had unpacking in comprehensions I'd switch. (Doesn't seem be a follow-up PEP just for that functionality yet.) https://www.python.org/dev/peps/pep-0448/ https://www.python.org/dev/peps/pep-3132/ I'd be really nice to use this. >>> [*range(i) for i in range(5)] Instead of this monstrosity right now. >>> [x for y in (range…

fwiw:

    >>> codecs.encode(b'Python', 'base64')
    b'UHl0aG9u\n'
The encodings still exist; hex works too (or hex_codec in older Python 3s). Python 3 just restricted the encode/decode methods to always go str to bytes or bytes to str.

Re: Python 3.5.0

#110
post #41

I've recently joined a Python project, my first time working with the language. We're currently using Python 2.7. How do experienced Pythonistas decide if/when to upgrade to 3.x? I figured it was a no brainer given that it has been 7 years with a number of big releases, but Flask's warning on this topic put me off: http://flask.pocoo.org/docs/0.10/python3/

Using Python 3 in production with Flask here, and been doing so for at least a year now. Never had an issue whatsoever. The warning is frankly outdated.
Post reply on HN