4 ms·

I upgraded from 3.7 to 3.8 and found out they removed a function in the time package required by crypto. I do strongly feel that removing functions from the co

I upgraded from 3.7 to 3.8 and found out they removed a function in the time package required by crypto. I do strongly feel that removing functions from the core library is a huge no-no for point releases.

elcritch 7y ago
From afar, Python 3.x releases seem more like major updates than point releases. There’s entirely blocks of functionality/syntax between 3.x releases.
- brianwawok 7y ago
  Except it is mostly additive. Adding new features will seldom break old stuff. It is the removing part that is hard. (With the exception being when like a variable broke because it became a keyword, but if you made a variable something like async I am not sure you are entirely innocent).
xxpor 7y ago
You're supposed to pay attention to DeprecationWarnings.
- MattGaiser 7y ago
  The problem is that the entire ecosystem needs to pay attention to such warnings and it doesn't happen. As a result, these changes end up breaking code in places the program authors never touched.
  - xxpor 7y ago
    That's true in one respect, but you as an end user can use them to know not to upgrade before your deps have changed what they need to.
    - scoot_718 7y ago
      What? You upgrade your dependencies when there's a feature or improvement you need. Not because they don't have some warnings. Who cares? The old version you implicitly claim is better isn't, it just doesn't have the warnings from their dependencies in place yet.
      - xxpor 7y ago
        I mean, if you're going to upgrade your python version, you should check your logs to see if you have had any DWs recently. If you have, upgrade your deps before upgrading python. If theres no new version available, you can't upgrade python yet.
- scoot_718 7y ago
  In my experience DeprecationWarnings get turned off so frequently because I'm not forking big library to fix all of it's Deprecated uses of their dependencies. The warnings are useless if they're not from my code, so they get turned off once globally.
  - takeda 7y ago
    They are still important. Because even if dependency has this warning, it will still break your code.
    - afiori 7y ago
      but they are also not actionable
      - takeda 7y ago
        well actually they are, they essentially saying that in future version your application will break. Yes, it is not your package that is responsible, but it still affects your application, you could open a ticket, or submit a PR. If you had that message you should also hold of with upgrading to newer python until this is resolved.
        scoot_718 7y ago
        > well actually they are, they essentially saying that in future version your application will break. No, you idiot. It's a deprecated usage in a dependency. What happens in the future is I update pandas, it stops using the deprecated numpy method, and the warning just disappears with very little action on my part. It's a useless warning. And submit a PR every time this happens? How about I request you pull me? > If you had that message you should also hold of with upgrading to newer python until this is resolved. 1. Upgrading to newer python? Who fucking cares 2. Upgrading resolves the warning entirely.
      - sambe 7y ago
        You can file an issue/PR in most cases, and if you don't get a response you may need to worry about moving libraries.
sigzero 7y ago
"The function time.clock() has been removed, after having been deprecated since Python 3.3" Python 3.3 was release in 2012. You've had 8 years.
- mehrdadn 7y ago
  I'm confused, who exactly has had 8 years to do what? Should he have dumped the crypto module because it was using a deprecated feature?
  - glyph 7y ago
    The reason the crypto module was using this particular deprecated feature is that it hasn't been updated at all in 8 years. The OP should have dropped it because it's unmaintained, and a maintained replacement has existed for a long time: https://cryptography.io/ https://cryptography.io/ This is an especially important consideration for security-critical libraries like cryptographic libraries.
    - mywittyname 7y ago
      OP here, thanks a bunch for this! I will take your advice and dump the crypto library for this one.
    - mehrdadn 7y ago
      See, when you explain what's wrong it's so much better than just blaming the victim with "You've had 8 years"!
    - toyg 7y ago
      One issue the ecosystem currently has, really (and its not the only one, I believe it's difficult almost everywhere), is that tracking dependency-rot is hard. Unless something breaks outright, you'll never know if a library has been abandoned; and manually checking dozens of github/gitlab repos is expensive and tedious. Pypi has an api (https://pypi.org/pypi/<pkg-name>/json https://pypi.org/pypi/<pkg-name>/json) that can be leveraged to implement alerts like "this pkg last released 5 years ago, it might be dead!". I guess that's what the "security" package uses already. It would be cool if they added an option to report on this sort of thing.
petre 7y ago
Perl does it as well, but then you've only got point releases because it's stuck at 5.
- takeda 7y ago
  I think at this point they should jump to perl7 and resume normal versioning

elcritch 7y ago

From afar, Python 3.x releases seem more like major updates than point releases. There’s entirely blocks of functionality/syntax between 3.x releases.

brianwawok 7y ago
Except it is mostly additive. Adding new features will seldom break old stuff. It is the removing part that is hard. (With the exception being when like a variable broke because it became a keyword, but if you made a variable something like async I am not sure you are entirely innocent).

xxpor 7y ago

You're supposed to pay attention to DeprecationWarnings.

MattGaiser 7y ago
The problem is that the entire ecosystem needs to pay attention to such warnings and it doesn't happen. As a result, these changes end up breaking code in places the program authors never touched.
- xxpor 7y ago
  That's true in one respect, but you as an end user can use them to know not to upgrade before your deps have changed what they need to.
  - scoot_718 7y ago
    What? You upgrade your dependencies when there's a feature or improvement you need. Not because they don't have some warnings. Who cares? The old version you implicitly claim is better isn't, it just doesn't have the warnings from their dependencies in place yet.
    - xxpor 7y ago
      I mean, if you're going to upgrade your python version, you should check your logs to see if you have had any DWs recently. If you have, upgrade your deps before upgrading python. If theres no new version available, you can't upgrade python yet.
scoot_718 7y ago
In my experience DeprecationWarnings get turned off so frequently because I'm not forking big library to fix all of it's Deprecated uses of their dependencies. The warnings are useless if they're not from my code, so they get turned off once globally.
- takeda 7y ago
  They are still important. Because even if dependency has this warning, it will still break your code.
  - afiori 7y ago
    but they are also not actionable
    - takeda 7y ago
      well actually they are, they essentially saying that in future version your application will break. Yes, it is not your package that is responsible, but it still affects your application, you could open a ticket, or submit a PR. If you had that message you should also hold of with upgrading to newer python until this is resolved.
      - scoot_718 7y ago
        > well actually they are, they essentially saying that in future version your application will break. No, you idiot. It's a deprecated usage in a dependency. What happens in the future is I update pandas, it stops using the deprecated numpy method, and the warning just disappears with very little action on my part. It's a useless warning. And submit a PR every time this happens? How about I request you pull me? > If you had that message you should also hold of with upgrading to newer python until this is resolved. 1. Upgrading to newer python? Who fucking cares 2. Upgrading resolves the warning entirely.
    - sambe 7y ago
      You can file an issue/PR in most cases, and if you don't get a response you may need to worry about moving libraries.

sigzero 7y ago

"The function time.clock() has been removed, after having been deprecated since Python 3.3" Python 3.3 was release in 2012. You've had 8 years.

mehrdadn 7y ago
I'm confused, who exactly has had 8 years to do what? Should he have dumped the crypto module because it was using a deprecated feature?
- glyph 7y ago
  The reason the crypto module was using this particular deprecated feature is that it hasn't been updated at all in 8 years. The OP should have dropped it because it's unmaintained, and a maintained replacement has existed for a long time: https://cryptography.io/ https://cryptography.io/ This is an especially important consideration for security-critical libraries like cryptographic libraries.
  - mywittyname 7y ago
    OP here, thanks a bunch for this! I will take your advice and dump the crypto library for this one.
  - mehrdadn 7y ago
    See, when you explain what's wrong it's so much better than just blaming the victim with "You've had 8 years"!
  - toyg 7y ago
    One issue the ecosystem currently has, really (and its not the only one, I believe it's difficult almost everywhere), is that tracking dependency-rot is hard. Unless something breaks outright, you'll never know if a library has been abandoned; and manually checking dozens of github/gitlab repos is expensive and tedious. Pypi has an api (https://pypi.org/pypi/<pkg-name>/json https://pypi.org/pypi/<pkg-name>/json) that can be leveraged to implement alerts like "this pkg last released 5 years ago, it might be dead!". I guess that's what the "security" package uses already. It would be cool if they added an option to report on this sort of thing.

petre 7y ago

Perl does it as well, but then you've only got point releases because it's stuck at 5.

takeda 7y ago
I think at this point they should jump to perl7 and resume normal versioning