Live data from Hacker News

Python 3 in 2016

hynek.me

151–160 of 194 posts

Re: Python 3 in 2016

#151
post #126

Earlier quoted context omitted.

Python is still king for really boring and maintainable scripts. I mean boring in the best way. Every Python script o read is clean and elegant. It's easy to follow and well organized. Python 3 doesn't seem to make it any better at this. In fact all Python3 does is annoy me. I never know when I need it or not, it never seems to be clear either. The fact that it's packaged as a separate entity (i.e. /user/local/bin/py…

Fundamentally, python3 fixes some of the serious WATs in python2 and makes it easier to write high quality and maintainable software. For a pretty quick overview take a look at: https://migrateup.com/main-difference-python-3/ Perhaps if python3 annoys you more than makes you say, "Hey, this prevents lots of latent bugs I might have easily shipped to production before, cool!", then you need to learn python a bit bette…

I believe the parent was talking about python3 from a users perspective (they said they aren't a Python programmer) For example when a script requires python3 and another requires python. Python3 is also not included in a lot of base systems. That could be annoying.

Re: Python 3 in 2016

#152
post #143

I've debated jumping from perl only dev into the python world for a couple of years now. I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have? Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5…

What's the can here?

Re: Python 3 in 2016

#153

I don't understand the python2 vs python3 fuss. Maybe I'm not doing anything interesting enough, but I find it fairly easy to write code that runs in python >= 2.7 and python >= 3.3. If I was working in a python2-only code base, I would just baby-step it towards python3 compatibility. It doesn't have to be a complicated, disruptive task.

Things are a lot easier with recent versions of Python 3. Not spending more time on supporting 2/3 compatible codebases was a big mistake in my opinion. I think Guido had the idea that everyone was eventually going to run 2to3 and then be done with the conversion. There is too much Python 2 code out there for that to work. Python 2 was too successful and businesses have no inventive to convert working apps.

The %-formatting (printf style) for bytes is a big deal (introduced in 3.5). Putting a 'u' prefix in front of text strings and 'b' in front of byte strings will not go a long way in making things work.

Re: Python 3 in 2016

#154

Earlier quoted context omitted.

Python 3 is much more than changing the print() statement (which, actually, is a great thing). It's about unicode by default. It's about removing 100 of duplicates way to do things to have only one. It's about making debug much, much easier, while at the same time allowing you to write better code with less mistakes. It's about removing a lot of boilerplate. It's about introducing new syntaxes allowing things not pos…

> If you see only print, you are missing the point. The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.

I think you might want to look into the 2to3 script. It should handle the conversion of your print statements.

Re: Python 3 in 2016

#155
post #145
post #143

I've debated jumping from perl only dev into the python world for a couple of years now. I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have? Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5…

I think the best case for moving to Python is for the tooling around math and data science. If you're build other types of web apps in Perl and looking to switch to something else. I'm not sure Django is going to offer you a ton of benefit for the switching cost, IMHO.

Well the benefit I initially see is more jobs and with a side note of hopefully a cleaner code base.

There are not too many perl companies that have been founded in the last 10 years. And I am finding more and more that companies that are older than 10 years old and are using perl, that this usually means they haven't changed a dang thing in their architecture or web dev process since 1998.

Which means I get to deal with CGI spaghetti, 6+ second page load times (so count ajax anything out), and the world's worse use of javascript. I've had good experiences with newer perl companies with short contract work, but these older ones are killing me and I'm pretty bummed about it as you can tell. I've worked hard to learn best practices and modern web dev styles, none of which I can use at the older places.

Re: Python 3 in 2016

#156
post #30

Three is (finally) likely to win, if only because of the constant nagging of the project leaders, and the fact that some distros will now move to it by default. But it will be a pyrrhic victory because it will have been a force-feed, not an enthusiastic, willing, adoption by the community. As a result of this mess, while Python's inertia is huge, its momentum is slowing. Its leadership, having lost credibility, canno…

That’s only true for people who are part of the community for a long time. Newcomers don’t understand what the fuss is about and why anyone would want to use Python 2. My own Python bubble is more like what you described (although the mood is improving IMHO) but talking to newcomers is eye opening.

[deleted]

Re: Python 3 in 2016

#157
post #133

Earlier quoted context omitted.

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous". 1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't " we can't make a JIT for python" rather than " nobody can make one"? Because that's how it turned out with JS. 2. If given the choice, do you think the community would turn down a JIT to avoid making the reference…

1. By people you mean "Google", and with a whole lot of money and a room full of some of the smartest people they could find. V8 is a whole department working full time, not a open source community-led effort. JS is also a different beast in a whole lot of ways. No, I am definitely saying " we can't make a JIT for Python that doesn't significantly impact single threaded scripts, retains significant backwards compatib…

You're making it sound like you're disagreeing with me but it sounds like we're in complete agreement on the main point: it's not impossible to create a cPython JIT. It's a choice whether to do it or not. (And by the way, creating a JIT is a piece of engineering, it's not black magic). It's fair enough if people think that would be the wrong choice, I might even agree actually, but if the cPython developers say, time and time again, that python is inherently unsuitable to be JITted then that's wrong and it prevents that discussion from taking place.

Re: Python 3 in 2016

#158

Earlier quoted context omitted.

I seriously doubt 4 will include breaking changes, at least not to the semantics/syntax of the language itself. What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.

>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 Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard

Standard support for direct install from GitHub without weird hacks.

Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck.

Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package.

Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.

Re: Python 3 in 2016

#159
post #98

Earlier quoted context omitted.

Two days ago I took a proof-of-concept project written in Python, using the GMPY2 library (Gnu Multiple Precision library), and ported it to C. My C code was very complicated in order to be fast. Lots of pointer swapping, bit-shifting, etc. The code was about 4% faster in C, which was more lines of code, much harder to read (and write), compiled with every imaginable flag that could offer a speedup. Switching operati…

All this because you didn't profile your code to see that 95% of the time was spent in GMP routines.

Yeah. I wasn't sure how GMPY was compiled, so I used C with my own compilation of GMP. I bet the flag differences made up the few percentage points.

Plus, with each variable being ~10Mb, I was concerned about memory copying (I studied mechanical engineering, I missed a lot of this stuff in school), and with C I could make memory copying vs passing pointers explicit. All of that was unnecessary.

It was another reinforcement of the idea: "Build it first, then optimize".

Re: Python 3 in 2016

#160

Earlier quoted context omitted.

That's a good reason, but note that it used to be the reason you picked Perl.

The difference is that most people can read most other peoples' python code. Perl didn't tend to have that quality. EDIT Added another "most" to make it clear that not everyone can write readable python.

That depends entirely on who is writing the code. I have seen some truly awful Python as well as truly awful Perl.
Post reply on HN