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

Review usage of unicode_literals #189

Closed
untitaker opened this issue May 2, 2015 · 14 comments
Closed

Review usage of unicode_literals #189

untitaker opened this issue May 2, 2015 · 14 comments

Comments

@untitaker
Copy link
Member

See #187

@geier
Copy link
Member

geier commented May 10, 2015

I'm with hobarrera on this, I don't have a problem with unicode_literals and haven't seen them brake something yet.

@untitaker
Copy link
Member Author

Click will warn if unicode literals are used: pallets/click@5f33770

@geier
Copy link
Member

geier commented Aug 17, 2015

I guess we'll have to obey than.

@geier
Copy link
Member

geier commented Nov 10, 2015

turns out you were right all along :-o
the idiotic decode in 8b25e5f is only needed because of the unicode literals.

@geier geier closed this as completed in fc6afb3 Nov 18, 2015
@WhyNotHugo
Copy link
Member

From PythonCharmers/python-future#22:

Only a very low number of people are using Python 3.2 or older

I don't agree with this. Python 2.7 is still quite popular, probably the default for > 50% of the users.


While I don't really like how the code looks after these changes, I guess functionality is more important than aesthetics, so I won't argue on this further. :)

@untitaker
Copy link
Member Author

This is only talking about Python 3 versions.

@geier
Copy link
Member

geier commented Nov 19, 2015

I'm not a fan of the look either :( I'd love to drop python 2 support all along.

@WhyNotHugo
Copy link
Member

I'm not a fan of the look either :( I'd love to drop python 2 support all along.

+1 on this. Also getting rid of compat+six. However, we really need to know if it's possible for downstream packages to update to py3 (maybe the entire dependency tree is missing from many distributions?).

We could open a separate issue and open this for discussion with downstream packagers and users.

@untitaker
Copy link
Member Author

It's unlikely that Debian or some other LTS distros ship with 3.3+ as their
Python 3 package. However, khal depends on vdirsyncer, which requires 3.3+ or
2.7+.

Options:

  • Remove vdirsyncer as dependency (good idea for other reasons too)
  • Vdirsyncer drops Py2 support simultaneously.

On Thu, Nov 19, 2015 at 12:10:08PM -0800, Hugo Osvaldo Barrera wrote:

I'm not a fan of the look either :( I'd love to drop python 2 support all along.

+1 on this. Also getting rid of compat+six. However, we really need to know if it's possible for downstream packages to update to py3 (maybe the entire dependency tree is missing from many distributions?).

We could open a separate issue and open this for discussion with downstream packagers and users.


Reply to this email directly or view it on GitHub:
#189 (comment)

@WhyNotHugo
Copy link
Member

Debian seems to include python3.3 on stable+ (source):

  • python3.4: stable, testing
  • python3.5: testing, unstable

Only oldstable seems to include python3 < 3.3 (it has 3.1, according to the above link). I really don't think we should limit ourselves because of Debian-oldstable.

However, the issue is if all other dependencies are available (otherwise the burden of packaging+maintaining would fall on the current khal maintainer, most likely).

Also: Does khal currently work with python3<3.3?

@untitaker
Copy link
Member Author

Also: Does khal currently work with python3<3.3?

Definetly doesn't, because of u"".

@untitaker
Copy link
Member Author

Also bug-wise it's not ideal to use 3.3, a lot of stuff got ironed out in later versions.

@untitaker
Copy link
Member Author

#302

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

3 participants