4 ms·

PEP 421 -- Adding sys.implementation

41 points by drx 14y ago

rlpb 14y ago
I think this is generally a good idea, but the danger is that programs start checking for implementation instead of supported features (or quirks). It's important to make sure that the dictionary definition stays updated with features (or quirks) to prevent this. See the HTTP User-Agent mess to see what can result if this goes the wrong way.
- notatoad 14y ago
  this was my initial reaction too, but it seems as though this PEP doesn't expose any new information, just makes existing variables cleaner to access.
- snprbob86 14y ago
  There's a big difference between HTTP User-Agents and this PEP's sys.implementation. User Agent sniffing is a bad idea because browsers are outside of your control. They evolve while web sites stand still. In this case, you can control which implementation you run. You can control what software runs on that implementation. You can change both of them. They are both under your control.
  - lukeschlather 14y ago
    What if you're running on a PaaS like Google App Engine or Heroku?
    - snprbob86 14y ago
      Presumably, you can still choose or edit the software you run on it, outside of the corelibs. Also, you can ask them to fix a bug, but you can't ask somebody else's grandma to update her browser.
geoffhill 14y ago
I think this is a terrible idea. Implementers of Python should code to a unified Python standard, instead of asking programmers of Python to code to a disparate collection of implementations.
- leif 14y ago
  This doesn't seem to me to be the goal. I think the point is that implementers would produce this module, and stdlib developers would consume it. Joe Foobar python programmer should never need to know about it. I think it's maybe not the best solution, but it's good, and the fact that they're trying to address the problem somehow is great.
mappu 14y ago
I suspect this would be most useful in working around 2.6/2.7/3.1 differences and loading different files/polyfills in response, or something. But old versions arn't going to magically retroactively implement a new PEP, so we won't see the benefit for some time. Other than that it's hard to imagine a use case for needing this sort of information.
- maxerickson 14y ago
  sys.version already exists, at least in 2.7. I'm not sure how far back it goes.

41 points by drx 14y ago

rlpb 14y ago

I think this is generally a good idea, but the danger is that programs start checking for implementation instead of supported features (or quirks). It's important to make sure that the dictionary definition stays updated with features (or quirks) to prevent this. See the HTTP User-Agent mess to see what can result if this goes the wrong way.

notatoad 14y ago
this was my initial reaction too, but it seems as though this PEP doesn't expose any new information, just makes existing variables cleaner to access.
snprbob86 14y ago
There's a big difference between HTTP User-Agents and this PEP's sys.implementation. User Agent sniffing is a bad idea because browsers are outside of your control. They evolve while web sites stand still. In this case, you can control which implementation you run. You can control what software runs on that implementation. You can change both of them. They are both under your control.
- lukeschlather 14y ago
  What if you're running on a PaaS like Google App Engine or Heroku?
  - snprbob86 14y ago
    Presumably, you can still choose or edit the software you run on it, outside of the corelibs. Also, you can ask them to fix a bug, but you can't ask somebody else's grandma to update her browser.

geoffhill 14y ago

I think this is a terrible idea. Implementers of Python should code to a unified Python standard, instead of asking programmers of Python to code to a disparate collection of implementations.

leif 14y ago
This doesn't seem to me to be the goal. I think the point is that implementers would produce this module, and stdlib developers would consume it. Joe Foobar python programmer should never need to know about it. I think it's maybe not the best solution, but it's good, and the fact that they're trying to address the problem somehow is great.

mappu 14y ago

I suspect this would be most useful in working around 2.6/2.7/3.1 differences and loading different files/polyfills in response, or something. But old versions arn't going to magically retroactively implement a new PEP, so we won't see the benefit for some time. Other than that it's hard to imagine a use case for needing this sort of information.

maxerickson 14y ago
sys.version already exists, at least in 2.7. I'm not sure how far back it goes.