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

Drop Python 2.6 support #448

Merged
merged 1 commit into from Oct 30, 2013

Conversation

Projects
None yet
4 participants
@dangra
Member

dangra commented Oct 29, 2013

No description provided.

@kmike

This comment has been minimized.

Show comment
Hide comment
@kmike

kmike Oct 29, 2013

Member

What are the reasons for dropping Python 2.6? Is it to remove bundled ordereddict?

Member

kmike commented Oct 29, 2013

What are the reasons for dropping Python 2.6? Is it to remove bundled ordereddict?

@dangra

This comment has been minimized.

Show comment
Hide comment
@dangra

dangra Oct 29, 2013

Member

Python 2.7 was released 3 years ago, it is the only 2.x version supposed to last before 3.x completely takes over.

I know it is possible to maintain a codebase that supports 2.6, 2.7 and 3.3 (as is it for 2.5); but why should we? more recent idiomatics like set and dict literals wont work under 2.6 and I really want to be able to write modern python code instead of always taking legacy in count.

There are lot more stuff that was backported only for python 2.7 listed at http://docs.python.org/dev/whatsnew/2.7.html, do we use it? not yet but why should we limit our-self not to.

I think the question is more like "What is the point of supporting python 2.6 and does it worth it?"

Member

dangra commented Oct 29, 2013

Python 2.7 was released 3 years ago, it is the only 2.x version supposed to last before 3.x completely takes over.

I know it is possible to maintain a codebase that supports 2.6, 2.7 and 3.3 (as is it for 2.5); but why should we? more recent idiomatics like set and dict literals wont work under 2.6 and I really want to be able to write modern python code instead of always taking legacy in count.

There are lot more stuff that was backported only for python 2.7 listed at http://docs.python.org/dev/whatsnew/2.7.html, do we use it? not yet but why should we limit our-self not to.

I think the question is more like "What is the point of supporting python 2.6 and does it worth it?"

@kmike

This comment has been minimized.

Show comment
Hide comment
@kmike

kmike Oct 30, 2013

Member

You're right that 2.6 is old, and its security support is just retired (2.6.9 was released yesterday). I was attached to 2.6 because of debian squeezy, but wheezy has 2.7. The only party that will suffer from this decision would be RHEL/CentOS people. If it costs us anything to support 2.6 then +1 for removing it, because its security support just ended.

Member

kmike commented Oct 30, 2013

You're right that 2.6 is old, and its security support is just retired (2.6.9 was released yesterday). I was attached to 2.6 because of debian squeezy, but wheezy has 2.7. The only party that will suffer from this decision would be RHEL/CentOS people. If it costs us anything to support 2.6 then +1 for removing it, because its security support just ended.

@pablohoffman

This comment has been minimized.

Show comment
Hide comment
@pablohoffman

pablohoffman Oct 30, 2013

Member

My list of pros & cons:

Pros:

  • will allow us to focus on writing code, not on legacy support. Easy as that might be, they add up because we're constantly dealing with them (it's not a one time thing)
  • no one objected on to the email sent to scrapy-users (even @kmike email wasn't strictly an objection)
  • I have been bitten myself before with Python 2.6 compatibility issues, including new methods or parameters added in 2.7 (unittests comes to mind, but there have been others)
  • we have shifted the approach from supporting very old versions of everything (twisted 8 ffs!) to requiring very new stuff (six 1.4.1), and this goes inline with this new philosophy
  • python 2.6 just came to end (no more security patches or bug fixes)

Cons:

  • RHEL last stable is still on Python 2.6 (they should be ashamed)

Overall: +1

Member

pablohoffman commented Oct 30, 2013

My list of pros & cons:

Pros:

  • will allow us to focus on writing code, not on legacy support. Easy as that might be, they add up because we're constantly dealing with them (it's not a one time thing)
  • no one objected on to the email sent to scrapy-users (even @kmike email wasn't strictly an objection)
  • I have been bitten myself before with Python 2.6 compatibility issues, including new methods or parameters added in 2.7 (unittests comes to mind, but there have been others)
  • we have shifted the approach from supporting very old versions of everything (twisted 8 ffs!) to requiring very new stuff (six 1.4.1), and this goes inline with this new philosophy
  • python 2.6 just came to end (no more security patches or bug fixes)

Cons:

  • RHEL last stable is still on Python 2.6 (they should be ashamed)

Overall: +1

pablohoffman added a commit that referenced this pull request Oct 30, 2013

@pablohoffman pablohoffman merged commit fa245af into scrapy:master Oct 30, 2013

1 check passed

default The Travis CI build passed
Details

@dangra dangra deleted the dangra:drop-py26 branch Oct 30, 2013

@barraponto

This comment has been minimized.

Show comment
Hide comment
@barraponto

barraponto Nov 17, 2013

Contributor

Does it mean we can move to argparse?

Contributor

barraponto commented Nov 17, 2013

Does it mean we can move to argparse?

@pablohoffman

This comment has been minimized.

Show comment
Hide comment
@pablohoffman
Member

pablohoffman commented Nov 18, 2013

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