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

Python 3 can revive Python

medium.com

Post reply on HN
Print view View original

171–180 of 242 posts

Re: Python 3 can revive Python

#171

Post by dorfsmay »

SoftwareMaven wrote: post #59
dorfsmay wrote: post #45

Earlier quoted context omitted.

Since you can define a function inside a function, why does it matter that it isn't anonymous?

Having done a lot of python and JavaScript, all I can say is it does matter. It is an extra redirect as you try to find out what is happening as part of a callback (repeated over and over). It is also additional cognitive load as you now need to mentally parse the function's name (which you don't actually care about) and the function's purpose. Finally, it is more time consuming. I really like coding in python, but t…

Is tail optimization a language or an implementation issue? Couldn't that be implemented in the compiler without changing the language?

Re: Python 3 can revive Python

#172

Post by gldsmth »

eloisant wrote: post #143
icebraining wrote: post #139

Earlier quoted context omitted.

Python was created by a non-native English speaker.

Well, he's Dutch, his language uses an alphabet meaning that even with all the accents it's still a one byte language. Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.

> Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.

Proper unicode support is not even close to being a priority when it comes to dealing with Japanese text. No one would store important Japanese text in unicode. http://en.wikipedia.org/wiki/Han_unification#Unihan_.22abstr...

One size doesn't fit all.

Re: Python 3 can revive Python

#173

Post by illumen »

sergiosgc wrote: post #154
eloisant wrote: post #145

Earlier quoted context omitted.

The question is: is the Python community OK with it becoming a niche language for scientific computing, or do we want to to keep being used as a general purpose language?

Python is also the modern sysadmin's Perl. This is a huge niche, to the point of not being a niche at all. Just take a look at the number of system tools used in a Redhat install that use python. Coincidentally, Redhat's python tools are one of the major reasons for continuing support of Python 2.

The next RHEL is going python 3 though I think? Fedora has done nicely over the last couple of years packaging everything for python 3 as well. A dozen or so packages left to do, but they are going well. Ubuntu, Debian, and Gnome have also been pushing to get to a python 3 use by the base system in the last releases... and are almost there as well. This of course has meant a lot more packages have been ported upstream in the last few months.

If the next Mac OS X release has python 3... then we things will change really quickly.

Re: Python 3 can revive Python

#174

Post by ermintrude »

chrishenn wrote: post #8

One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place. It was all fine once I got it worked out but it would so…

Check out devpi (http://doc.devpi.net/latest/). We build our projects as wheels with pip using devpi as a custom index, i.e.:

BUILD_DIR="/tmp/wheelhouse/$PROJECT" pip wheel --wheel-dir=$BUILD_DIR --find-links=$BUILD_DIR --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} --extra-index-url=https://pypi.python.org/simple/ ../$PROJECT

This will try to get packages from your devpi index, but will fall back to pypi if you don't have them.

Then upload this to devpi. It can later be installed by pip with:

pip install --use-wheel --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} $PROJECT

This makes deployments super fast because you're deploying pre-built wheels instead of downloading and compiling from pypi. It also gives you resiliance by storing copies of the dependencies you need in devpi, so if they vanish from pypi (or it's unavailable) you can still deploy your software with all the dependencies you developed against.

Re: Python 3 can revive Python

#175

Post by oshepherd »

sergiosgc wrote: post #153
skriticos2 wrote: post #118

Earlier quoted context omitted.

I add that Python is excellent at data representation and transformation. You can easily write some test data and just include it in python, then transform it any way you feel you like to get intelligence out of it. With the standard library you can easily load a CSV file you exported form a data-set and then aggregate and evaluate it with only a few lines of code without much language overhead. Schema-less mixed con…

I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it compiles quickly. I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than…

The people who call Go a systems programming language are fundamentally misguided. It is an applications programming language under any reasonable definition.

Re: Python 3 can revive Python

#176

Post by anton-107 »

1ris wrote: post #127
oleyb wrote: post #107

Earlier quoted context omitted.

ECMAScript 6 has generators, and they are already available in Node.js.

Javascript seems to go the opposite way of python: instead of ironing the warts out, it adds them. The DOM-API is nonsensical and ugly? Why not add language features so we can implement it in pure JS? Sounds like a great idea.

The DOM API has nothing to do with JS.

Re: Python 3 can revive Python

#177

Post by acqq »

sergiosgc wrote: post #153
skriticos2 wrote: post #118

Earlier quoted context omitted.

I add that Python is excellent at data representation and transformation. You can easily write some test data and just include it in python, then transform it any way you feel you like to get intelligence out of it. With the standard library you can easily load a CSV file you exported form a data-set and then aggregate and evaluate it with only a few lines of code without much language overhead. Schema-less mixed con…

I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it compiles quickly. I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than…

Go was never a class of C and Rust. Maybe it becomes once, but at the moment I observe it as a kind of server-side Java replacement: by the current design it simply can't be as low level as C and Rust. The main difference with Java is that it compiles to he native code and not bytecode. Still it is dependent on its own special conventions, GC and libraries.

The confusion comes from the announcements of the Go team where they claimed a "systems programming language" where they, it seems, didn't mean "operating systems" but more "some user-space programs on our servers," that is, their in-house user-space "systems." They of course discovered that the only group who saw possible benefits were programmers that would otherwise use languages like Python but liked extra speed and convenience of a compiled language. The other group were those that liked Go's concurrency primitives.

Re: Python 3 can revive Python

#178

Post by chrishenn »

andreabedini wrote: post #38
chrishenn wrote: post #8

One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place. It was all fine once I got it worked out but it would so…

(dormant) PyTables developer here, we do have a requirements.txt file but I understand our setup.py needs an update. Please open an issue on github and tell us about your experience and how we can improve it.

I will soon, thanks!

Re: Python 3 can revive Python

#179

Post by dorfsmay »

the_mitsuhiko wrote: post #52
dorfsmay wrote: post #46

Earlier quoted context omitted.

Seriously? The first thing I do when writing python 2 is import the print_function!

Out of curiosity: why?

I can never remember the python 2 quirky, inconsistent syntax, I always have to look it up.

PRINT TO A FILE, OR STDERR print >> sys.stderr, "blah" What are those '>' signs here? Why two? What happens if I use one only?

Compare this to (py3k): print("blablah", file=sys.stderr)

PRINT WITHOUT NEW LINE sys.stdout.write('blah') I can't use print to print?

compare to: print("blah", end="")

DISABLE FLIUSH In python 2 there are 2 or 3 different ways to do that, all more complicated than each other. Compared to:

print("blah", flush=True)

Finally, it's a function, you can do everything you do with a function, use map, return a print from another function, include it in generator expressions etc...

Re: Python 3 can revive Python

#180

Post by sergiosgc »

oshepherd wrote: post #175
sergiosgc wrote: post #153

Earlier quoted context omitted.

I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it compiles quickly. I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than…

The people who call Go a systems programming language are fundamentally misguided. It is an applications programming language under any reasonable definition.

You know that "the people who call Go a systems programming language" are its authors, do you not?
Post reply on HN