Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most popular Python packages now support Python 3

py3readiness.org

Post reply on HN
Print view View original

131–140 of 166 posts

Re: Most popular Python packages now support Python 3

#131

Post by bostik »

jooke wrote: post #84
bostik wrote: post #65

Earlier quoted context omitted.

Yes, the boolean group operations make many otherwise non-trivial problems remarkably easy. That's why I consider sets such a crucial feature.

Could you give some examples please?

Sure, let's get a really simple one.

You have N groups of something (persons, sales units, cars, tools, whatever). Find the values that are present in all of them. This problem comes up, all the time, in some form.

With sets it's trivial. Take the first set, and calculate a cascading intersection with every other set. At the end you're left with only the values that appeared in every one. In very clear python the code might look like this:

    common = ALL_SETS[0]
    for _set in ALL_SETS[1:]:
      common = common.intersection(_set)
    return common
Now, you can argue that underneath the hood that's still going to do N expensive iterations and you'd be right. This is where proper optimisations come in - when provided by a robust stdlib, we expect the set operations to be implemented with bitmaps.[0, 1] These are not something you'd see in a casual implementation.

Btw, in the above code example I have deliberately omitted a trivial optimisation. Let's leave that as an exercise for the reader. :)

0: http://roaringbitmap.org/about/

1: https://en.wikipedia.org/wiki/Bit_array

Re: Most popular Python packages now support Python 3

#132

Post by akvadrako »

rspeer wrote: post #85
bandrami wrote: post #74

Earlier quoted context omitted.

Why on earth do people downvote that? I want a language that isn't going to change. Every single other language community seems to understand that, but something about it pisses off Python people.

You're claiming to know the future of Python better than "Python people" know the future of Python. Python has changed incompatibly once in 26 years, and never plans to do it again, yet you're making it sound like an ongoing pattern. What language are you going to run to that has that kind of track record?

> Python has changed incompatibly once in 26 years

That's not true. Every change breaks some behavior, even if it's not throwing an Exception where one used to be thrown. Things are still being deprecated and removed in new releases.

On top of that, by adding new syntax in 3.7+, libraries may become incompatible with the system-provided installation. That won't happen with 2.7 libraries.

Re: Most popular Python packages now support Python 3

#133

Post by pjmlp »

merb wrote: post #130
striking wrote: post #15

Earlier quoted context omitted.

For network glue, Go is a wonderful and super useful language. Not just in how efficient it is, or how easy FFI calls are, but also in how easy it is to deploy. I don't see Go replacing anything that isn't a lightweight server or really small data processing script, though. Anything Tensorflow or numpy of any notable complexity will probably remain Python afaict.

well I wouldn't call kubernetes less complex. and it's still written in go. I think stuff like that is where go shines.

The key question is how many lines of code would Kubernetes have if Go was an expressive language, but I don't have big hopes for a hypothetical Go 2.0.

Re: Most popular Python packages now support Python 3

#134

Post by msl09 »

git-pull wrote: post #129
sago wrote: post #8

Clicking around, those that don't seem to be: 1. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without even a minor/patch release (initools, 2010) or in some cases a code commit (e.g. pathtools, 2012) for five years or more. I suspect that they will never be Py3, the community will just move on to alternatives. 2. Working hard to bring support (e.g. ansible). 3. Part of the graphite ecosystem. If the…

In addition, Fabric doesn't support Python 3. The feedback I've gotten back on when Python 3 will be supported and how much of the legacy fabric API's will be supported is even more limited. There is a fork with Python 3 support: https://github.com/mathiasertl/fabric/ If you use fabtools, I maintain a fork of it for fabric3: https://github.com/develtech/fabtools/tree/fabric3

I use your fork, thank you for your work!

Re: Most popular Python packages now support Python 3

#136

Post by jernfrost »

jchw wrote: post #115
jasonrhaas wrote: post #4

Yup at this point there is no reason to not use Python 3 for new projects. What I'm finding actually is that some companies that have their codebase in Python 2 have actually started migrating to Golang rather than Python 3, because of the increased performance benefits. I'm kind of sad about this, but I think that Golang will eventually replace Python as the go-to back-end server language (maybe even data processing…

I'm currently using Go (and Python - we did go from Python 2 to Go, but later continued using Python 3) at work, but for all of the hoopla about it's concurrency, the reality is I'd rather have Rust's superior runtime safety and metaprogramming. A few things have impeded on Rust adoption at work: - Learning curve. Rust is not as bad for learning as C++, but any language with strong metaprogramming and unfamiliar or r…

I kind of like the idea of Rust, but I don't really have much belief in complex programming languages. C++ only has a large following because it piggy backed on C, which people already knew, then it gradually grew its complexity.

It is quite a different challenge to get people to use an entirely new language with high complexity.

Companies are going to be negative towards adopting a language with a steep learning curve for its employees. That represents too much risk and money.

I think Swift is a much better alternative to those who want something like Rust. Much easier to learn and you still got native code and strict typing without a need for a garbage collector.

People also know they can trust it in the sense that they know Apple supports it and all Apple development is switching to it. That takes a way a big risk factor for companies.

Re: Most popular Python packages now support Python 3

#137

Post by jernfrost »

make3 wrote: post #7
jasonrhaas wrote: post #4

Yup at this point there is no reason to not use Python 3 for new projects. What I'm finding actually is that some companies that have their codebase in Python 2 have actually started migrating to Golang rather than Python 3, because of the increased performance benefits. I'm kind of sad about this, but I think that Golang will eventually replace Python as the go-to back-end server language (maybe even data processing…

but at the same time, Python is the fastest growing language https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... because of data science and AI, and I don't see Go replacing Python anytime soon in these domains.

However Python is getting attacked by new language in all areas where it is being used. Go attacks just one area.

Julia is a much better language for data science than Python. It was essentially designed for it, while for Python it was an afterthought.

Python has a head start today with a large selection of packages and mindshare, but as we've seen with Go, I think that will start eroding in the future.

Python simply can't keep up with the development pace and possibilities offered with Julia. For Data Science and AI packages in Python to have acceptable performance they need to be written in C/C++, this means slow development. Julia has high enough performance that all these packages can be developed in Julia itself. And this is what people in this area is observing. That package development is moving much faster in the Julia community than in Python.

You can also combine these packages in ways that are simply impossible to do in Python. The need to interface with C/C++ creates a lot of artificial restrictions. E.g. processing lots of data fast requires big NumPy buffers with plain data types.

In Julia you can e.g. create a an image buffer made up of color objects and process it fast.

Unlike Go, Julia offers the ability of a gradual transition to Julia from Python, since Python packages can be used in Julia.

Re: Most popular Python packages now support Python 3

#138

Post by jernfrost »

rspeer wrote: post #112
bandrami wrote: post #108

Earlier quoted context omitted.

30 years later, scheme is still scheme. A different report has come out, and some compilers choose to implement it. But the language hasn't changed. See my point?

I particularly don't see your point when it comes to Scheme. The Scheme I learned in 2002 (MIT Scheme) is all but abandoned. I was one of the people hired to rewrite MIT's course code from MIT Scheme to DrScheme, which was definitely not compatible. DrScheme itself has been superseded by Racket, except at that point MIT changed all their CS courses and rewrote everything again in Python. What Scheme implementation do…

Of course code being data in Scheme you could easily write program that processes scheme code and transforms it to a different syntax. I would assume this would be harder with Python code.

Re: Most popular Python packages now support Python 3

#139

Post by Macha »

Cyph0n wrote: post #104
actuallyalys wrote: post #102

Earlier quoted context omitted.

>The language maintainers themselves have clarified that introducing breaking changes was a mistake in hindsight and that it will never happen again. What are you referring to? I haven't heard or read any core developers say anything close to 'introducing breaking changes was a mistake in hindsight'.

I recall reading something along those lines, but I could be mistaken!

https://opensource.com/life/14/9/why-python-4-wont-be-python...

Re: Most popular Python packages now support Python 3

#140

Post by feikname »

adamtulinius wrote: post #126
odonnellryan wrote: post #81

Earlier quoted context omitted.

Supervisord isn't open source? What

Open source doesn't mean the source must be publicly available for everyone to read. :)

That's exactly what I thought open source meant. How can a source be open if not everyone can read it? I didn't get your comment.
Post reply on HN