Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break Python backward compatibility for DEAP 2.0 - Python 3.7+ all the way #290

Open
cmd-ntrf opened this issue Jul 6, 2018 · 9 comments
Milestone

Comments

@cmd-ntrf
Copy link
Member

cmd-ntrf commented Jul 6, 2018

Mandatory thought provocating title.

This up for debate, but I think that DEAP 2.0 might be ready for a serious change of pace and moving to supporting only Python 3.7+ could be the right kick in the butt we need. I think 2.0 is not about new features, but mainly refactoring based on the numerous user feedback we got since DEAP 1.0 release.

It would allow us to close old issues like the following :

What do you think?

@cmd-ntrf cmd-ntrf added this to the 2.0 milestone Jul 6, 2018
@fmder
Copy link
Member

fmder commented Jul 6, 2018

I totally agree that we shouldn't concern ourselfes with backward compatibility for old Python versions.

Do you have any feature you intend to use in 3.7 that is not in 3.6?

@cmd-ntrf
Copy link
Member Author

cmd-ntrf commented Jul 6, 2018

Python 3.7 has data classes that could either simplify the creator or maybe even remove it completely.
https://www.python.org/dev/peps/pep-0557/

We should probably also look at the package (attrs)[https://github.com/python-attrs/attrs]. It was released a few years after DEAP, but I think it tackles a problem similar to what we faced when we came up with the creator - simplifying data class creation.

@TristanJM
Copy link

I am also in agreement with moving to Python 3. I would say 3.7 is a step too far considering you still require 3.6 to run Tensorflow.

@nielsgl
Copy link

nielsgl commented May 21, 2019

I know that this is an old topic but TensorFlow already supports 3.7 for a couple of months now.

@fmder
Copy link
Member

fmder commented Apr 11, 2020

@cmd-ntrf I think I'm onto something here. No more creator, no more fitness.values, no more toolbox.clone, easy multi-crossover.

https://gist.github.com/fmder/a8eb232e8b51a56a300b8494d5255622

@Seanny123
Copy link

@fmder I really like that approach. It looks like would resolve #480

@Seanny123
Copy link

@fmder have you already started a branch working on this? Alternatively, what would a Minimal Viable PR look like for this?

@fmder
Copy link
Member

fmder commented May 4, 2020

@Seanny123 I really appreciate your enthusiasm, but I think this is too mush of a big change for a PR ;).

@nbro
Copy link
Contributor

nbro commented Jan 29, 2021

@cmd-ntrf, @fmder Is this issue going to be discussed for how many years before something is actually done?

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

No branches or pull requests

6 participants