On 6/10/2016 10:49 AM, Nick Coghlan wrote:
> What Brett said is mostly accurate for me, except with one slight
> caveat: I've been explicitly trying to nudge you towards making the
> *existing tools better*, rather than introducing new tools. With
> modernize and futurize we have a fairly clear trade-off ("Do you want
> your code to look more like Python 2 or more like Python 3?"), and
> things like "pylint --py3k" and the static analyzers are purely
> additive to the migration process (so folks can take them or leave
> them), but alternate interpreter builds and new converters have really
> high barriers to adoption.
I agree with that idea. If there is anything that is "clean" enough, it
should be merged with either 2.7.x or 3.x. There is nothing in my tree
that can be usefully merged though.
> More -3 warnings in Python 2.7 are definitely welcome (since those can
> pick up runtime behaviors that the static analysers miss), and if
> there are things the existing code converters and static analysers
> *could* detect but don't, that's a fruitful avenue for improvement as
> well.
We are really limited on what can be done with the bytes/string issue
because in Python 2 there is no distinct type for bytes. Also, the
standard library does all sorts of unclean mixing of str and unicode so
a warning would spew a lot of noise.
Likewise, a warning about comparison behavior (None, default ordering of
types) would also not be useful because there is so much standard
library code that would spew warnings.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4