Pytextrank – A pure Python implementation of TextRank | Hacker News Reader

Pytextrank – A pure Python implementation of TextRank

github.com

79 pointsrch17 comments

Open articleView on HN

I don't find any information on what version of Python this works with, any pointers? 2.X 3?

How is this different from all the other textrank implementation? Is this more complete?

https://github.com/summanlp/textrank

https://github.com/davidadamojr/TextRank

https://github.com/galsang/PyTextRank

rant: I hate how complex the python ecosystem is, there are different versions for language, different packaging systems (this project uses both conda and pip), sometimes you need to install stuff even with OS package manager or install packages from the source. Something really needs to be done for this mess.

Pro-tip: If you are curious and they don't mention version support, search the repo for "print" statements to help you distinguish.

Yes I know that but there are minor versions too and I really don't want to browse code to find what version I can install to.

Reading the source before running it is a good thing. Who knows if the author has put backdoor in the program?

Following that advice, it seems that's py3 compatible only. Print statements are function calls without having imported from future.

it only works the other way -- 2.7+ allows both

    print("hello")
    print "hello"

while 3+ allows only

    print("hello")

In Py2.7 you need:

    from __future__ import print_function

to get the print("hello") behaviour.

I don't remember ever having to do that, and my intro to cs class was py3 - I don't really run 2.7 day to day, is this a specific version?

  airbears2-10-142-34-161:~ ecx$ echo 'print("hello")' >0.py
  airbears2-10-142-34-161:~ ecx$ python2.7 0.py
  hello
  airbears2-10-142-34-161:~ ecx$ python2.7 -V
  Python 2.7.10

No, because the () just ends up being a no-op as grouping parentheses in the expression in Python 2.

What the import from __future__ does is make the original non-parens version illegal syntax in Python 2. You have to treat it like a function call with that import.

There is another, less obvious difference: in Python 2, if you print multiple items in parentheses, you're actually printing a tuple:

    >>> print "foo", 1, 2, "bar", "baz"
    foo 1 2 bar baz
    >>> print("foo", 1, 2, "bar", "baz")
    ('foo', 1, 2, 'bar', 'baz')
    >>> from __future__ import print_function
    >>> print("foo", 1, 2, "bar", "baz")
    foo 1 2 bar baz

True, that, behavior-wise. It's the comma that actually defines the tuple, though, hence (1) being different than (1,) and x = 1,2 assigning (1,2).

In the particular case of a print statement, the grouping parens disambiguate between the comma meaning multiple args and a single arg that's a tuple, once Python 2 implicitly wraps the entire right side with function calling parens.

In the end it's really a form of operator precedence. The from __future__ version behaves differently only because the function calling parens are now explicit and so tuple grouping parens must be added too if desired.

For what it's worth, it works fine in Python 3.5.

> I hate how complex the python ecosystem is, there are different versions for language

Like for every language out there (Java 6, Java 7, Java 8, etc.)

> different packaging systems (this project uses both conda and pip),

Yes, I believe that is an issue. But not that big. For instance, you can replace `conda install textblob` by `pip install textblob` for the given project.

> sometimes you need to install stuff even with OS package manager or install packages from the source.

Like for every scripting language out there.

> Something really needs to be done for this mess.

It used to be much worse, but it's moving in the right direction (see https://glyph.twistedmatrix.com/2016/08/python-packaging.htm...), except for the pip/conda divide.

Also: the project linked is not properly packaged (it has no setup.py). I guess I you had come across a repository with a bunch of .c files and no Makefile you would be lost too.

Java 6,7,8 is entirely different, as almost always the latest Java runs all previous programs, while Python 3 doesnt run python 2 programs at all.

I'm guessing you've never tried migrating a mid-sized Java project an older version of Java to a new version? This is definitely not my experience.

What's mid-sized? I've worked on a couple of 50,000+ line projects, and never had a problem upgrading to a newer Java.

Maybe we were lucky, or more likely didn't push any corners of the JVM in an incompatible way.

Java at least should be backward compatible. I have had no problem updating to a new java version (and this is with big codebases)

I have also never had a problem finding a library version (Assuming java has one) that would work with my java version whereas with Python that is one of the main problems all the time.

Reply on news.ycombinator.com