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

Python 3 in 2016

hynek.me

Post reply on HN
Print view View original

161–170 of 194 posts

Re: Python 3 in 2016

#161

Post by EvanPlaice »

emmelaich wrote: post #28
EvanPlaice wrote: post #20

Earlier quoted context omitted.

I think the biggest barrier to adoption right now is OS support. OSX still comes bundled with python2. There's no indication that Apple is working on a transition to 3. Ubuntu is actively working on the transition but the current LTS release (ie the one companies/enterprise will use) is still locked onto python2. The same can likely be said for other flavors of *nix. From a user's perspective, python3 has been ready…

I suspect that many Pythoners will install Python3 (with homebrew) or other on OSX (and whatever other platforms still come with just Python2)

Like I said. Python3 works for regular python users.

What if I want to distribute a package to an audience that doesn't have a strong Python background.

What would otherwise be a simple 'pip install' just turned into a complex multi-step process to install a new version, update PATH, and use virtualenv to avoid conflicts with the default install used internally by the OS.

These all seem like 'simple' fixes to a regular Python user but they set a huge barrier-of-entry for others.

'Just use [insert python specific fix]' is a UX failure for a language that emphasizes usability.

To reiterate. Python3 is ready for regular python users/devs. Not so much for the rest who consume python applications.

Re: Python 3 in 2016

#162

Post by collyw »

dethos wrote: post #91

Unless it is explicitly necessary to use python 2 (like legacy stuff, that hasn't been upgraded yet), I've been using python 3 solely for almost 2 years, and there is no turning back. I have no reason to stick with the old version. The last piece that needs to change, to complete the transition, is the majority of OS makers to bundle python3 by default.

I would be as well, but many jobs out there involve existing code on python 2.

Re: Python 3 in 2016

#163

Post by crdoconnor »

EvanPlaice wrote: post #158
crdoconnor wrote: post #36

Earlier quoted context omitted.

>They have a lot to learn from the Javascript and Ruby evosystems. Such as? I really hope I'm not going to start needing 1,200 dependencies to build a simple app like I would in node.

Support for local, per-project installs without hacks like virtualenv. Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer. Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary. Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain. Support for…

* Virtualenv isn't a hack.

* Setup.py/MANIFEST.in seems like a pretty clear answer to me.

* I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment.

* Yes, I do it pretty frequently.

* "MD os the defacto standard" Huh? According to whom? ReST is fine.

* "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" in your requirements.txt and off you go.

* Yeah, they should really standardize on pip, but this is relatively minor.

* Use one of the templates.

* Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.

Re: Python 3 in 2016

#164

Post by mturmon »

raverbashing wrote: post #94
mangecoeur wrote: post #79

Earlier quoted context omitted.

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunche…

Yeah, I don't know While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky. I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.

Years ago, it used to be harder to install numpy, but this has changed. On MacOS, it's just

% pip install numpy

For more (e.g., other OS'es, build-from-source), see:

http://docs.scipy.org/doc/numpy-1.10.1/user/install.html

Re: Python 3 in 2016

#165

Post by mixmastamyk »

retrogradeorbit wrote: post #56
Odin78 wrote: post #31

Earlier quoted context omitted.

Noob question: What's so difficult about deploying/distributing python?

https://glyph.twistedmatrix.com/2015/09/software-you-can-use...

That page dismisses py2exe, but I've used it successfully for over a decade. On unix it is as simple as:

  sudo pip install [package/repo]

Re: Python 3 in 2016

#166

Post by mturmon »

sametmax wrote: post #82
retrogradeorbit wrote: post #23

I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…

Readability. Ease of scripting. Libs. Multi-paradigm. Simplicity to debug. Good instrospection. Expressivity. Fantastic community. Great documentation (because hey, docstrings). It's a no brainer to teach and to learn or train for and gives you good habits. And it does the job.

All you said, and also: the REPL and ipython.

Re: Python 3 in 2016

#167

Post by jerf »

plesner wrote: post #149
jerf wrote: post #141

Earlier quoted context omitted.

JITs for Javascript aren't comparable; at the time, nobody had C-based extensions for Javascript. It makes it a radically simpler problem. Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or…

Sure there were C-based extensions for JavaScript, that's how it integrates with the DOM. It makes it a little trickier but not a whole lot.

Sorry, perhaps I was unclear. I mean, there were no C-based extensions not under the control of the same project as controlled the JS engine, so one entity can both JIT a JS engine and simultaneously make whatever modifications it took to make them work under the new engine. Python has an enormous amount of external C-based extensions not controlled by any one entity, which constitute huge swathes of core (in importance, not in "under control of the core team") Python libraries. It's difficult to imagine what a JIT looks like that still works with those. You don't have one entity doing both the JIT and all the C extensions.

Re: Python 3 in 2016

#168

Post by jerf »

ZenoArrow wrote: post #146
jerf wrote: post #142

Earlier quoted context omitted.

But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in. I remain skeptical that STM is a good fit for this problem,…

> "So far, based on that page..." From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8" This page is probably a better starting point for the current PyPy STM work: http://pypy.org/tmdonate2.html

I didn't see anything newer there to suggest they've made a lot of progress since that page, though.

Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm not saying it's impossible. Just, I'll believe it when I see it, and I don't recommend a high degree of confidence that it will occur. Nor do I recommend that you use it as part of your advocacy... it's nowhere near solid enough to be making promises about it to people outside the community.

Re: Python 3 in 2016

#169

Post by sklogic »

stdbrouw wrote: post #43
retrogradeorbit wrote: post #23

I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…

Pick Python for the sheer amount of libraries that's available. Not just for web stuff, where Node.js and Ruby do fine, but also for scientific work, for statistics, for embedded work (Raspberry Pi or MicroPython), for systems administration, for command-line tools, for really just about anything you can imagine. And you can do all of those things while not having to switch contexts between different syntaxes and dif…

This is exactly the reason why I use C, C++ and sometimes Fortran. Yet to see a Python library I'd need.
Post reply on HN