Python 3.5.0 • Hacker News Board

Re: Python 3.5.0

#161

Post by apaprocki » Wed, Sep 16, 2015, 11:23 AM UTC

vegabook wrote: post #141

eevee wrote: post #111

Earlier quoted context omitted.

The GitHub repo suggests there's been Python 3 support for a while: https://github.com/filmackay/blpapi-py I've run into my fair share of Python 3 roadblocks, but you'd be surprised how far you can get by making a little noise and sending the occasional patch. Library authors are much more willing to prioritize Python 3 support if it looks like people actually need it :)

I will try to compile this today - appreciate that thank you. I understand that Ubuntu is making Python 3 the default from 16.04 onwards so I need to get moving. Looks like the long dusk for 2.x is finally turning to night.

The official library supports 3.x, and the downloads are on the link you put in your original comment.

Re: Python 3.5.0

#162

Post by haypo » Wed, Sep 16, 2015, 2:53 PM UTC

lamby wrote: post #50

baxter001 wrote: post #14

The scandir update also changes the underlying implementation of os.walk giving loads of production apps a huge speed increase by making use of additional data returned by the os calls.

Could os.walk have been changed "under the hood" without a PEP? eg. using — just for example — fast_walk_in_c in _os.so (I understand that adding os.scandir might require a PEP)

No, a PEP was required because there was a lot of discussion on the API, and also non trivial choices on the implementation (pure C? pure Python? C+Python?). To have an idea of the amount of discussion, read the "Rejected ideas" of the PEP:

https://www.python.org/dev/peps/pep-0471/#rejected-ideas

Re: Python 3.5.0

#163

Post by lamby » Thu, Sep 17, 2015, 5:33 PM UTC

haypo wrote: post #162

lamby wrote: post #50

Earlier quoted context omitted.

Could os.walk have been changed "under the hood" without a PEP? eg. using — just for example — fast_walk_in_c in _os.so (I understand that adding os.scandir might require a PEP)

No, a PEP was required because there was a lot of discussion on the API, and also non trivial choices on the implementation (pure C? pure Python? C+Python?). To have an idea of the amount of discussion, read the "Rejected ideas" of the PEP: https://www.python.org/dev/peps/pep-0471/#rejected-ideas

Why would changing the underlying workings of os.walk require a PEP?

Re: Python 3.5.0

#164

Post by cben » Sat, Sep 19, 2015, 9:31 PM UTC

jodah wrote: post #153

inglor wrote: post #71

Earlier quoted context omitted.

It has the ability to statically check the type system , that's amazing. Moreover async/await with async resource management (which C# doesn't have yet) gives it a real edge for server development.

> async/await with async resource management (which C# doesn't have yet) gives it a real edge for server development An edge over what? You're still limited to a single thread via the GIL. Until that problem is solved, Python is certainly not the best bet (all else aside) for server development.

Node.js is also single thread and has been doing fine on servers.

Do you really need to share mutable state between threads in your server? If yes, what's your story when you'll need to scale to multiple servers?

If not because you can keep shared mutable state in a separate service (DB or similar), you can deal with one-machine scaling very similarly to scaling across machines - just start/fork a process per CPU. You get simplicity, avoid the whole thread-safety can of bugs, and all the administration benefits of stateless servers.

Re: Python 3.5.0

#165

Post by engi_nerd » Sat, Sep 26, 2015, 4:23 AM UTC

jkachmar wrote: post #157

engi_nerd wrote: post #116

Earlier quoted context omitted.

I work in the defense industry. Sometimes it is indeed easier to ask for forgiveness than permission, but you must be very careful. Obviously anything that violates any NDAs or security agreements is not to be pushed at all, but I've had no problems writing and running Python and MATLAB programs. Point is, defense industry doesn't automatically equal a locked down environment.

I'll chime in here and say that quite a few people in aerospace/defense (at least where I work) prefer Python to some of the more traditionally used tools. I've written a number of scripts for data analysis and simulation in Python that are much more portable for us since we don't need to get a license to run MATLAB on computers out in the field.

I just now (days later) read your profile.

If you're in the EE department...I had your exact same job a year ago. And your main Python users are down the hall in ACS. Those guys are great. Maybe EE has started to change some...since they lost pretty much half the department. For your sake, I hope so.