12 ms·

> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. This statement is plain wrong at best and intention

> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. This statement is plain wrong at best and intentionally misleading at worst. 99.99% of Python 3.5 code runs unmodified on 3.7. > At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. No. It's because some people still are on the not-latest version and still need access to the documentation. It's what every good project should do. I stopped reading there. Too much wrong in too little text.

fernandotakai 8y ago
afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.
- mahoro 8y ago
  > and i wonder why they would It's easy, actually: import asyncio @asyncio.async # SyntaxError in 3.7 def my_coroutine(...): ... And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes. Luckly, 99% of changes were trivial. Other 1% is a nightmare.
  - blattimwind 8y ago
    Using async and await as non-keywords was deprecated since 3.5, while asyncio.async was deprecated since 3.4.
- paulie_a 8y ago
  I wouldn't be surprised, I've seen a developer use type as a function name and it was imported everywhere...it caused a lot of problems. Not to mention the function literally did nothing, it essentially returned none under 99 percent of circumstances. If the person that wrote that was still at the company, that should have been a fire able offense.
- misnome 8y ago
  The ‘deprecated’ warning on invalid escape strings turned into a hard error, also.
- chasedehan 8y ago
  There is also formatted string literals from 3.5 to 3.6. 3.5 won't run if you included them in your 3.6 code
  - mixmastamyk 8y ago
    That's forward compatibility which few folks require. Backwards, yes most do.
- OJFord 8y ago
  > unless the author is using async/await as variable names (and i wonder why they would) Kubernetes-cli did, [0] inadvertently due to code generated by Swagger. [1] That doesn't mean only that project either - it means anything _depending_ (not necessarily directly!) on it is also broken under 3.7. [2] [0]: https://github.com/kubernetes-client/python/issues/558 https://github.com/kubernetes-client/python/issues/558 [1]: https://github.com/swagger-api/swagger-codegen/pull/8401 https://github.com/swagger-api/swagger-codegen/pull/8401 [2]: It bit me.
- ubernostrum 8y ago
  There is one other thing that could break, but it would be a weird one. Which is hard to explain in prose, so here's some example code: class SomeMetaClass: def __new__(name, bases, attrs): pass class SomeClass(metaclass=SomeMetaClass): pass Now suppose that SomeClass needs to use the typing module's mechanism for indicating a generic, so you could do an annotation like "SomeClass[SomeOtherType]". So you'd want to have SomeClass be a subclass of, typing.Generic[T]. That would, in Python 3 prior to 3.7, raise a TypeError due to metaclass conflict -- the generics in the typing module had their own base metaclasses. So you actually had to define an intermediate class to resolve the metaclass conflict, and do like so: class IntermediateMeta(SomeMetaClass, typing.GenericMeta): pass class SomeClass(metaclass=IntermediateMeta): pass (this was weird and rare and GenericMeta was never documented) Python 3.7 implemented PEP 560, which introduced the __class_getitem__ hook for implementing the behavior GenericMeta used to handle, and doing away with the need for the typing generics to use GenericMeta as their metaclass. So GenericMeta exists in Python 3.5 and 3.6, but no longer exists in Python 3.7, and anything which tries to reference it will break.
larkost 8y ago
I figured that was a typo for 2.7. But even then there are relatively few areas that need some touchup from 2.7 -> 3.5, and most of those are mechanical changes like having parens around print statements.
mdemare 8y ago
Tensorflow doesn’t run on 3.7, only 3.6 (and 2.7). That’s a pretty major library.
- mixmastamyk 8y ago
  Probably a C extension that needs to be compiled against a new version. Unlikely it is an actual compatibility break.
- orf 8y ago
  python3.7 -m pip install --upgrade https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.12.0-py3-none-any.whl wget https://raw.githubusercontent.com/aymericdamien/TensorFlow-Examples/master/examples/1_Introduction/helloworld.py python3.7 helloword.py Tensorflow 0.12, released over two years (before 3.7 development had even started) runs fine.
deleted 8y ago
[deleted]

fernandotakai 8y ago

afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.

mahoro 8y ago
> and i wonder why they would It's easy, actually: import asyncio @asyncio.async # SyntaxError in 3.7 def my_coroutine(...): ... And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes. Luckly, 99% of changes were trivial. Other 1% is a nightmare.
- blattimwind 8y ago
  Using async and await as non-keywords was deprecated since 3.5, while asyncio.async was deprecated since 3.4.
paulie_a 8y ago
I wouldn't be surprised, I've seen a developer use type as a function name and it was imported everywhere...it caused a lot of problems. Not to mention the function literally did nothing, it essentially returned none under 99 percent of circumstances. If the person that wrote that was still at the company, that should have been a fire able offense.
misnome 8y ago
The ‘deprecated’ warning on invalid escape strings turned into a hard error, also.
chasedehan 8y ago
There is also formatted string literals from 3.5 to 3.6. 3.5 won't run if you included them in your 3.6 code
- mixmastamyk 8y ago
  That's forward compatibility which few folks require. Backwards, yes most do.
OJFord 8y ago
> unless the author is using async/await as variable names (and i wonder why they would) Kubernetes-cli did, [0] inadvertently due to code generated by Swagger. [1] That doesn't mean only that project either - it means anything _depending_ (not necessarily directly!) on it is also broken under 3.7. [2] [0]: https://github.com/kubernetes-client/python/issues/558 https://github.com/kubernetes-client/python/issues/558 [1]: https://github.com/swagger-api/swagger-codegen/pull/8401 https://github.com/swagger-api/swagger-codegen/pull/8401 [2]: It bit me.
ubernostrum 8y ago
There is one other thing that could break, but it would be a weird one. Which is hard to explain in prose, so here's some example code: class SomeMetaClass: def __new__(name, bases, attrs): pass class SomeClass(metaclass=SomeMetaClass): pass Now suppose that SomeClass needs to use the typing module's mechanism for indicating a generic, so you could do an annotation like "SomeClass[SomeOtherType]". So you'd want to have SomeClass be a subclass of, typing.Generic[T]. That would, in Python 3 prior to 3.7, raise a TypeError due to metaclass conflict -- the generics in the typing module had their own base metaclasses. So you actually had to define an intermediate class to resolve the metaclass conflict, and do like so: class IntermediateMeta(SomeMetaClass, typing.GenericMeta): pass class SomeClass(metaclass=IntermediateMeta): pass (this was weird and rare and GenericMeta was never documented) Python 3.7 implemented PEP 560, which introduced the __class_getitem__ hook for implementing the behavior GenericMeta used to handle, and doing away with the need for the typing generics to use GenericMeta as their metaclass. So GenericMeta exists in Python 3.5 and 3.6, but no longer exists in Python 3.7, and anything which tries to reference it will break.

larkost 8y ago

I figured that was a typo for 2.7. But even then there are relatively few areas that need some touchup from 2.7 -> 3.5, and most of those are mechanical changes like having parens around print statements.

mdemare 8y ago

Tensorflow doesn’t run on 3.7, only 3.6 (and 2.7). That’s a pretty major library.

mixmastamyk 8y ago
Probably a C extension that needs to be compiled against a new version. Unlikely it is an actual compatibility break.
orf 8y ago
python3.7 -m pip install --upgrade https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.12.0-py3-none-any.whl wget https://raw.githubusercontent.com/aymericdamien/TensorFlow-Examples/master/examples/1_Introduction/helloworld.py python3.7 helloword.py Tensorflow 0.12, released over two years (before 3.7 development had even started) runs fine.

deleted 8y ago

[deleted]