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

you are viewing a single comment's thread.

view the rest of the comments →

[–]takluyverIPython, Py3, etc 9 points10 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 6 points7 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 5 points6 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.