Skip to content
This repository has been archived by the owner on Nov 30, 2023. It is now read-only.

Python 3 support. #412

Open
ignatenkobrain opened this issue Mar 30, 2016 · 30 comments
Open

Python 3 support. #412

ignatenkobrain opened this issue Mar 30, 2016 · 30 comments

Comments

@ignatenkobrain
Copy link

Would be great to have it.

@ed-g
Copy link

ed-g commented Aug 28, 2017

At the very least the README should be updated to say that Python 3 is not supported. I wasted time trying to get it working and I see that others have as well.

@grote
Copy link

grote commented Sep 16, 2017

Since the library doesn't seem to be maintained anymore. Does somebody want to step up, fork and take over maintainership?

@RachM
Copy link
Contributor

RachM commented Sep 17, 2017

The library is maintained - apologies for the delay.

Do you have a pull request to fix this issue?

@grote
Copy link

grote commented Sep 18, 2017

Great that this library is still maintained. Welcome back @RachM!

I don't have a Python 3 pull request ready, but knowing that there now is somebody to review and merge it, increases many people's motivation to do one.

@jamescr jamescr mentioned this issue Oct 4, 2017
@avilaton
Copy link
Contributor

I'm taking a stab at this here
https://github.com/avilaton/transitfeed/tree/feature/2to3
Already pretty far into it, nosetests tests/transitfeed reporting https://travis-ci.org/avilaton/transitfeed shows

Ran 282 tests in 1.074s
FAILED (errors=167, failures=3)

which is promising. Feel free to pitch in.
Thanks

@jwoos
Copy link

jwoos commented Sep 24, 2018

@avilaton just wanted to see the status of the port

what work is there left to do?

@avilaton
Copy link
Contributor

Some tests are still not passing and I have run out of time. Please check out the fork, run the tests and see if there is something you can do about it.
https://github.com/avilaton/transitfeed
I think at this stage it would be better to send smaller PRs with improvements instead of the full fix.

jarondl added a commit to jarondl/transitfeed that referenced this issue Nov 15, 2018
by running

    2to3 -nw -f except .

Part of google#412
jarondl added a commit to jarondl/transitfeed that referenced this issue Nov 16, 2018
Another backwards compatible change as part of google#412

by running:

    futurize -nw -f libfuturize.fixes.fix_print_with_import  .
jarondl added a commit to jarondl/transitfeed that referenced this issue Jan 28, 2019
Part of google#412

Started by:
futurize -nw -f libfuturize.fixes.fix_absolute_import  .
And followed up by fixing a few local problems.
jarondl added a commit to jarondl/transitfeed that referenced this issue Jan 28, 2019
Part of google#412

Started with `futurize -nw --stage1 .`, but had to do a few manual
changes.

Note that it includes commits from google#460
jarondl added a commit to jarondl/transitfeed that referenced this issue Jan 28, 2019
Part of google#412

Started with `futurize -nw --stage1 .`, but had to do a few manual
changes.
jarondl added a commit to jarondl/transitfeed that referenced this issue Feb 10, 2019
Part of google#412

Started with `futurize -nw --stage1 .`, but had to do a few manual
changes.
@nicolegorton
Copy link

Has this been updated for Python 3? Would be super amazing if so.

@MuckT
Copy link

MuckT commented May 27, 2019 via email

@jarondl
Copy link
Contributor

jarondl commented May 31, 2019

There are a few pull requests to slowly migrate to Python3. I think we should try to avoid branching.

@avilaton
Copy link
Contributor

I think we should create issues to give people access to stuff they can contribute with. I'll send a PR so travis tests other versions of python, then we need to surface those failed tests and make issues. People come with the intention of helping out but seeing which tests fail will make it easier.

@eternaltyro
Copy link

There should be a branch for the Python 3 port, don't you think?

@tabiva
Copy link

tabiva commented Sep 19, 2019

Got some news? I'll be glad to help!

jarondl added a commit to jarondl/transitfeed that referenced this issue Oct 4, 2019
jarondl added a commit that referenced this issue Oct 4, 2019
Change travis to Python 2.7 while working on #412
@pecalleja
Copy link

pecalleja commented Oct 12, 2019

There is a branch on this fork https://github.com/pecalleja/transitfeed/tree/python3 with support to python 3.7
I apologize for submitting a PR #491 with all changes (60K lines of code ) instead of small PR with specific changes.
I used a 2to3 tool for migrating the code, flake8 and black for formating the code, and then fix the code to pass all test with python3.7
This issue has more than 3 years old, and I just wanted to go forward to solve this problem. If you need help solving problems of python2 portability here I am.
Kind regards

@jarondl
Copy link
Contributor

jarondl commented Oct 28, 2019

@pecalleja No need to apologize, you did nothing wrong. It's just that reviewing 60k lines of code is impossible, even more so if you say you fixed code manually after applying tooling. And I don't think that forking is a great idea either from a maintenability point of view.

As I said in the pr, most of these convertors (futurize, modernize, 2to3) have fixers and you can apply some of them. In particular, 2to3 has a -f flag for that. Apply some of the fixers, make it work, and send a pr.

@pecalleja @avilaton @tabiva I recently got write permissions to this repo, and I would be happy to merge small digestible changes.

@jarondl jarondl pinned this issue Oct 28, 2019
This was referenced Oct 28, 2019
@pecalleja
Copy link

ok, let's do it. thanks

@trevh3
Copy link
Contributor

trevh3 commented Nov 6, 2019

Hey, I’m willing to put some horsepower behind this effort. Wont use conversion tools, and all commits will pass the python2 and python3 tests. I have a couple questions for the supporting community:

  1. are we shooting for python 2 and 3 compatibility? Or are we making a clean break at some version?
  2. how small should the commits be? I’d like to go function by function if possible, but some of the concepts cross a couple function/class boundaries. (Str/byte conversion dance in loader._loadCSV, util.endoflinechecker, CSV.reader)
  3. are there devs that have a global understanding of the codebase that I can bounce ideas off of? Or should I Lone Ranger it and submit PRs that are in the “ready to be merged” state?

@pecalleja
Copy link

Hi @trevh3, I working hard too on this issue, I started the python3 porting (again) following the guidelines from @jarondl with small changes commits, some times it is very difficult, as you say, because of the type of problem to solve (StringIO to BytesIO migration for example). I neither using conversion tools and making the changes to pass python2 and python3 tests, one test file at time.
I heavily use this tool on my daily basis and I would very happy to share ideas and make this project better.
Right now Transitfeed Google Group is closed and could be nice to have an open discussion platform for this project ( https://groups.google.com/forum/#!forum/transitfeed show a message: "You do not have permission to access this content. (#418)" when trying to join)

@trevh3
Copy link
Contributor

trevh3 commented Nov 6, 2019

Thanks @pecalleja - I think we can work on this together.

Unfortunately, I don't think a straight port is going to be the most elegant solution here. The majority of our woes look like they will arise from how Python 2 and 3 think differently about strings (utf8 and unicode).

Correct me if I'm wrong, but I think the best approach is to do as much of the work as we can in unicode and down covert to utf-8 when we have to.
(start) -> bytes in utf8 -> util.endoflinechecker -> strings (unicode) -> csv.reader -> unicode from now on, except for things that absolutely need to be in utf-8.

@pantierra
Copy link

pantierra commented Dec 10, 2019

Just my two cents: We are only 21 days away (and counting) from reaching end of life of Python 2. While supporting Python 2 and 3 in parallel was important for many years, IMHO it is not anymore starting from January 2020.

Many people started porting this library to Python 3 here and got a push back because of a best, desired stepwise approach with support for both versions of Python.

Given the urgency in time, I would be grateful to get a release of transitfeed that works with Python 3 and I wouldn't care about Python 2 at all anymore.

Thanks for all the good work!

@prusswan
Copy link

Yup, a new version does not have to support both Python 3 and 2. The current version will continue to work for Python 2.

@prusswan
Copy link

prusswan commented Sep 7, 2020

Understand this is not exactly actively maintained, but if anyone is still interested in finishing the port, we probably need to check the Travis tests and fix them by groups.

@olivierhill
Copy link

I can surely help, just need some pointers and/or list of bugs and we can split the work.

@nathanschepers
Copy link

I'm in the middle of another project now but will be hitting a milestone soon, and would love to contribute to this once I get there. We should review where everything is and make a plan. Not sure how we should organize to do that, but I have some planning/management skills and would be happy to volunteer some time on that front if there is interest.

@carlfredl
Copy link

Hello everyone. Just wanted to make sure you were aware that we over at MobilityData have been developing a new, open-source canonical GTFS validator written in Java. We've got a plan to be able to see to maintenance of the new validator into the future and keep up with new spec additions.

We're currently finalizing feature parity with the Python validator for rules that align with the GTFS spec, which we'll announce soon. We'll then continue working on improving speed and performance and building out additional validation rules. Contributions and collaboration are very welcome!

@jpnbastos
Copy link

Hey, what is the status on this? I actually would love to use this tool for a project. If someone is organising the efforts I would be willing to lend a hand or two

@eternaltyro
Copy link

Perhaps a good start would be to use whatever conversion tools are available and then just work with the diffs it creates. I see that there's one called 2to3 https://docs.python.org/3/library/2to3.html

It messes things up a bit especially when dealing with classes but I think the diff it produces makes it easy to do manual corrections.

@davidgutierrez
Copy link

https://cloud.google.com/python/docs/python2-sunset

it will be great, that Google remembers this title project and update it so we can use it in the google cloud plataform.

@tabiva
Copy link

tabiva commented Jun 24, 2021

Perhaps a good start would be to use whatever conversion tools are available and then just work with the diffs it creates. I see that there's one called 2to3 https://docs.python.org/3/library/2to3.html

It messes things up a bit especially when dealing with classes but I think the diff it produces makes it easy to do manual corrections.

I've tryied this some time ago, and I could get things to kinda work. Unfortunately I don't have the code anymore, but I can try again and put everything on a new branch if that would be helpful.

@KristjanESPERANTO
Copy link

I'm using the python3 branch [1] from @pecalleja. For me this works fine.

Thank you for your efforts @pecalleja!

[1] https://github.com/pecalleja/transitfeed/tree/python3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests