Skip to content

WIP: Unify to a single code base compatible with both Python 2 & 3#245

Closed
jdufresne wants to merge 1 commit into
yaml:release/5.1from
jdufresne:six
Closed

WIP: Unify to a single code base compatible with both Python 2 & 3#245
jdufresne wants to merge 1 commit into
yaml:release/5.1from
jdufresne:six

Conversation

@jdufresne

Copy link
Copy Markdown
Contributor

This removes the need to maintain two separate code bases that could
potentially drift over time in subtle ways. This greatly simplifies long
term maintenance. Now, both Python 2 and 3 share the same code with the
six package as a compatibility layer.

@ingydotnet

Copy link
Copy Markdown
Member

@jdufresne I've only skimmed the changes so far, but thanks for taking this on!

Let's see if you can get the Travis tests passing next.

BTW, How necessary is it to depend on six? I notice you mostly use it for text_type and once for 2 other things.

@dthkao

dthkao commented Jan 20, 2019

Copy link
Copy Markdown
Contributor

Just chiming in that 1) this is awesome, 2) use of the six.text_type spans quite a few files and reproducing that version-conditioned logic would mean either added verbosity or a separate 2-3 compatibility module to maintain anyway, and 3) six.with_metaclass is pretty nifty.

@nitzmahone

Copy link
Copy Markdown
Member

Yeah, this has been sorely needed for a long time- thanks!

@ingydotnet ingydotnet changed the title Unify to a single code base compatible with both Python 2 & 3 WIP: Unify to a single code base compatible with both Python 2 & 3 Jan 23, 2019
@ingydotnet

Copy link
Copy Markdown
Member

Renamed this WIP:... until it's ready to merge.

@jdufresne, @nitzmahone and I think pyyaml should vendor the six.py file as part of the pyyaml dist since it is only one file and adding dependencies to an important package that currently has none might cause trouble. You can do that or we can.

Let us know if you need help getting the tests to pass.

@rooterkyberian

Copy link
Copy Markdown

Alternative proposition: drop Python 2 altogether since its by the end of the year it will reach EoL.
Python 2 users will still be able to use outdated PyYAML releases, just like they are doing with python interpreter.

Motivation: lower maintance burden, and much lower risk of bugs.

@jdufresne

Copy link
Copy Markdown
Contributor Author

I'm am definitely open to that if the maintainers are. I agree, @nitzmahone and @ingydotnet what do you say? Can we go Python 3 only?

@ingydotnet

Copy link
Copy Markdown
Member

@jdufresne Work has begun in earnest towards a PyYAML 5.1 release which we hope will become final this month. @nitzmahone, @perlpunk and I would be excited to merge this PR if it can be completed soon enough. More public details on the release should emerge this week.

@rooterkyberian it is too early to drop Python 2 support now. The YAML projects that I am involved with strive to support language versions past EOL. So it will probably be a few years.

Comment thread lib/yaml/constructor.py Outdated
@jdufresne
jdufresne changed the base branch from master to release/5.1 March 9, 2019 17:50
This removes the need to maintain two separate code bases that could
potentially drift over time in subtle ways. This greatly simplifies long
term maintenance. Now, both Python 2 and 3 share the same code with the
six package as a compatibility layer.
@jdufresne

Copy link
Copy Markdown
Contributor Author

Thanks for all feedback, but I no longer have the time to finish this. If someone else is interested they can continue from my work.

@jdufresne jdufresne closed this Mar 9, 2019
@ingydotnet

Copy link
Copy Markdown
Member

@jdufresne No problem. Thank you for starting this. I expect we will get it done soon after the 5.1 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants