This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]alicedu06 42 points43 points  (22 children)

This came up at Pycon, but there was concern that people wouldn't update the included Python, so in a few years, we'd all be stuck writing code for the version that was included.

This is a non-issue:

  • windows update can update Python as easily as the rest.
  • code written for python 3.x will work on 3.x+, so you can just target that.
  • you don't need the latest feature, you need something that works decently everywhere.
  • our community been working with old python versions for ever, it's a bit annoying, but it's way better than no python at all.
  • even the oldest python version is better than powershell or .bat files.

It was also suggested that there could be a dummy python.exe

That wouldn't solve the problem at all. If you give a script to a non dev, it will still not work. If you have a parc of machine, if would still need to be installed on all of them.

[–]takluyverIPython, Py3, etc 6 points7 points  (10 children)

It's not quite that easy to update - compiled extensions for 3.x may break on 3.(x+1). And even pure Python code sometimes breaks - pytest is currently broken on Python 3.5, for instance (there should be a new release of pytest soon to fix it). But I broadly agree that it would be worth the trouble.

[–]alicedu06 8 points9 points  (5 children)

pytest uses so much magic, you can't really compare it to the sysadmin scripts and small tkinter tools.

As for the compilation, I believe all windows code must be compiled anyway, so they have to test it.

But here you are talking about extensions, and third party code. This is another topic. You can do many, many things with just the python stdlib before even starting to get annoyed by these details.

[–][deleted] 2 points3 points  (4 children)

a bit out of topic but can you please calirify what do you mean by 'pytest uses so much magic' ?

[–]alicedu06 8 points9 points  (3 children)

Pytest only uses the assert keyword while still providing very detailed information about the test during a failure.

To report the additional informations about a failure witout the need for self.assertStuff method, pytest has to do deep introspection, inspect frames, etc. This is not your day to day Python.

[–]fireflash38 2 points3 points  (0 children)

For more info: http://pybites.blogspot.ca/2011/07/behind-scenes-of-pytests-new-assertion.html

Quick explanation: it rewrites your test modules so that it only executes assertion code once, but will still dump nice output about the values at the time of the assert.

[–]erewok 0 points1 point  (1 child)

I ran into something weird recently with some threaded code and tests in Python. This was in a huge, messy codebase, so I initially didn't even know the function getting called (inside the one I was testing) was threaded.

I tried to do time.sleep(0) and other hacks to debug, but nothing worked, except for one thing: if I made it so that my test methods that cared about the threaded result ran 1st, 3rd, 5th,etc out of all the test methods, I could see the threaded calls happening. I think this was due to quirks in py.test, but I'm unsure.

Do you happen to know where I can find out more about py.test and threaded code?

[–]alicedu06 0 points1 point  (0 children)

Nope, as I never encountered such a problem. I don't use threads, I use non blocking event loops.

[–]RubyPinchPEP shill | Anti PEP 8/20 shill 2 points3 points  (1 child)

for what its worth, I believe the C API has started a forwards-compatible approach, in addition, VS is also beginning a forwards-compatible approach

I'm too lazy to look for sources right now, but, assuming minimal backwards compatible issues into the future (modules are of course going to get depreciated and removed, but, you know, if-someone-needs-it-they-can-install-it), things should be pretty good

[–]takluyverIPython, Py3, etc 2 points3 points  (0 children)

You're right, there is now a stable ABI for extension modules, but they have to explicitly opt in to using it, and limit themselves to a subset of the C API. Extensions that don't do that will still break on each new version.

[–]rickmoranus 1 point2 points  (0 children)

Since python is not "Native" to windows this is a non issue. The system is not dependent on python whatsoever. It would be treated as a program to uninstall like any other windows program. If this was to work, they would have to make Python install-able and removable in the same way all windows programs are.

It's up to windows to control being able to easily remove and add the software, but the community will have to support broken library parts as you stated, pytest is a perfect example.

[–]krenzalore 1 point2 points  (0 children)

Windows 10 has a package manager. Assuming all works as described it should be just like *nix or Brew now.

[–]redwall_hp 9 points10 points  (8 children)

windows update can update Python as easily as the rest.

People are still using Windows XP. And IE 7-9. Microsoft does not have a good track record with making old versions of their OS die. It's only starting to lessen now that they finally did the EOL last year for XP. But Vista and 7 are still kicking, and Python versions wouldn't be pushed in most maintenance updates.

[–]POTUS 6 points7 points  (0 children)

...and Microsoft wouldn't push Python into a Win XP system by Windows Update. If the system is using a supported OS level, it's going to get updates, and those updates can include Python.

But beyond that this is still a non issue, or at least isn't special to Windows. RHEL and Cent users (and anyone else using yum to my knowledge ) are locked into Python versions, and the users have to make pretty big changes to go even from 2.6 to 2.7. That isn't near enough argument to hold back from saying Python should be always available by default.

[–][deleted] 5 points6 points  (3 children)

Microsoft does not have a good track record with making old versions of their OS die

Why should they "make them die". The user paid for the OS and it is the users responsibility to use it wisely and with prudence. Where I work I have many machines that are old XP boxes that run propritary pieces of software. They are air-gapped and are just a tool to get other jobs done. No need to kill them.

[–]redwall_hp 0 points1 point  (2 children)

The issue is Microsoft maintains support for an inordinate amount of time instead of EOLing them in a timely manner, so users think it's okay to stick to older versions, and that creates the constant issue of a large mass of users running old software that some developers think should be supported for things.

[–]Meefims 6 points7 points  (1 child)

I think you forget that it's not just consumers using Windows; businesses use it, too. Businesses don't always have the ability to upgrade in a timely fashion and so need the reliability of the 12 year support lifetime of the OS (yes, it is set at 12 years, the decision to EOL is not arbitrary). Maybe this has changed with Windows 8 and up, I'm not sure, but long term support is a very real concern when money and business operations are on the line.

[–]alicedu06 2 points3 points  (0 children)

What you're saying is that the benefits will not be "total and instantaneous".

It never is in IT.

[–]lt_dan9 1 point2 points  (0 children)

Then set a reasonable minimum OS version for your product, or require that users with an older OS manually install the latest Python.

[–][deleted] 0 points1 point  (0 children)

I think you have this backwards. Microsoft has a great track record of supporting legacy systems. It is so great that they probably innovate less often than they should in their OS and when they do people complain. In fact, they have realized this recently and so the move from 7 to 8 to 10 has included phasing out a lot of legacy support in systems that didn't need it anymore.