How to pass options to "make test"?
After building CPython from source, I run the regression test suite, using make test (I'm on Linux). Now I would run only some tests, and pass a custom option (-R :) I tried TESTOPTS="test_pickle" make test without success. I had to do: ./python -u -bb -E -Wd -m test -r --fail-env-changed -w -j 0 test_pickle This works, but I would specify only custom options. PS: -R option finds reference leaks (python -m test --help explains it) -- https://mail.python.org/mailman/listinfo/python-list
The speed of glob()
Has anybody noticed the speed of 'glob()' has
decreased somewhere between v3.6 and v3.10.
With this little test:
import os, sys, timeit, glob
# change to suite
globPath = u'e:/net/*/*/*/*'
def _glob():
glob.glob (globPath)
# I used this 'https://docs.microsoft.com/en-gb/sysinternals/downloads/sync'
def flush_disks():
sync = r"f:\ProgramFiler\Sysinternals\sync.exe -nobanner"
print ("Exec sync: %s" % sync)
os.system (sync)
flush_disks()
print ("Python %d.%d.%d:" % sys.version_info[:3])
print (" 1st run: %.5f" % timeit.timeit (_glob, number=1))
print (" 2nd run: %.5f" % timeit.timeit (_glob, number=1))
I got these results:
Python 3.6.5:
1st run: 0.14694
2nd run: 0.09506 <- *always* the fastest
Python 3.7.7:<- from Nuget
1st run: 0.12440
2nd run: 0.09602
Python 3.10.0: <- from Git repo
1st run: 0.15922
2nd run: 0.12424
'glob()' in Python 3.6.5 is consistently 30% faster on
the 2nd run compared to 3.10.0.
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
On Wed, Jul 29, 2020 at 6:27 PM Gisle Vanem wrote: > > Has anybody noticed the speed of 'glob()' has > decreased somewhere between v3.6 and v3.10. > > I got these results: >Python 3.6.5: > 1st run: 0.14694 > 2nd run: 0.09506 <- *always* the fastest >Python 3.7.7:<- from Nuget > 1st run: 0.12440 > 2nd run: 0.09602 >Python 3.10.0: <- from Git repo > 1st run: 0.15922 > 2nd run: 0.12424 > > 'glob()' in Python 3.6.5 is consistently 30% faster on > the 2nd run compared to 3.10.0. > Unfortunately that's very hard to compare. If you're building Python from source, the parameters may be VERY different from a prepackaged binary. Are you able to redo this test with more consistent Python builds? For instance, you can go as far as 3.8 using python.org binaries, or alternatively, build all your tests from git (by checking out different branches). My guess is that something changed in the caching rules when listdir/scandir changes happened, but there's no way to know for sure. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
Chris Angelico wrote: Has anybody noticed the speed of 'glob()' has decreased somewhere between v3.6 and v3.10. I got these results: Python 3.6.5: 1st run: 0.14694 2nd run: 0.09506 <- *always* the fastest Python 3.7.7:<- from Nuget 1st run: 0.12440 2nd run: 0.09602 Python 3.10.0: <- from Git repo 1st run: 0.15922 2nd run: 0.12424 'glob()' in Python 3.6.5 is consistently 30% faster on the 2nd run compared to 3.10.0. Unfortunately that's very hard to compare. If you're building Python from source, the parameters may be VERY different from a prepackaged binary. I guess so w/o knowing why. I just tried this from MS' AppStore: Python 3.8.5: 1st run: 0.12121 2nd run: 0.07674 Fastest I've tried so far. Are you able to redo this test with more consistent Python builds? For instance, you can go as far as 3.8 using python.org binaries, or alternatively, build all your tests from git (by checking out different branches). I do not want to put to much stress on this. Maybe I'm just 'ass-u-me'ing too much? The important thing is that any Python3.x is much faster on both the 1st and 2nd run compared to my Python 2.7. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
On Wed, Jul 29, 2020 at 7:44 PM Gisle Vanem wrote: > > Chris Angelico wrote: > > >> Has anybody noticed the speed of 'glob()' has > >> decreased somewhere between v3.6 and v3.10. > >> > >> I got these results: > >> Python 3.6.5: > >> 1st run: 0.14694 > >> 2nd run: 0.09506 <- *always* the fastest > >> Python 3.7.7:<- from Nuget > >> 1st run: 0.12440 > >> 2nd run: 0.09602 > >> Python 3.10.0: <- from Git repo > >> 1st run: 0.15922 > >> 2nd run: 0.12424 > >> > >> 'glob()' in Python 3.6.5 is consistently 30% faster on > >> the 2nd run compared to 3.10.0. > >> > > > > Unfortunately that's very hard to compare. If you're building Python > > from source, the parameters may be VERY different from a prepackaged > > binary. > > I guess so w/o knowing why. I just tried this from MS' AppStore: > Python 3.8.5: >1st run: 0.12121 >2nd run: 0.07674 > > Fastest I've tried so far. That suggests that there's a lot of irrelevant noise in those numbers. Ah well. > > Are you able to redo this test with more consistent Python builds? For > > instance, you can go as far as 3.8 using python.org binaries, or > > alternatively, build all your tests from git (by checking out > > different branches). > > I do not want to put to much stress on this. Maybe I'm just 'ass-u-me'ing > too much? > > The important thing is that any Python3.x is much faster on both > the 1st and 2nd run compared to my Python 2.7. > Ah, now THAT has a number of very good explanations, and most likely IS meaningful. There've been several optimizations aimed at hammering the file system less to get the same info, so I'm not at all surprised that you're seeing an improvement. BTW, I just noticed something. The path you're using for testing purposes is "e:/net". Is that network-attached or local? If it's a remote mount of some sort, then that will make a HUGE difference, and it also means that the sync command you're using probably won't ensure that you have a clean testing platform. But if that's local, then no probs, don't mind me. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
On 29/07/2020 11.43, Gisle Vanem wrote: > Chris Angelico wrote: > >>> Has anybody noticed the speed of 'glob()' has >>> decreased somewhere between v3.6 and v3.10. >>> >>> I got these results: >>> Python 3.6.5: >>> 1st run: 0.14694 >>> 2nd run: 0.09506 <- *always* the fastest >>> Python 3.7.7: <- from Nuget >>> 1st run: 0.12440 >>> 2nd run: 0.09602 >>> Python 3.10.0: <- from Git repo >>> 1st run: 0.15922 >>> 2nd run: 0.12424 >>> >>> 'glob()' in Python 3.6.5 is consistently 30% faster on >>> the 2nd run compared to 3.10.0. >>> >> >> Unfortunately that's very hard to compare. If you're building Python >> from source, the parameters may be VERY different from a prepackaged >> binary. > > I guess so w/o knowing why. I just tried this from MS' AppStore: > Python 3.8.5: > 1st run: 0.12121 > 2nd run: 0.07674 > > Fastest I've tried so far. Official builds and most distribution builds are optimized PGO builds (PGO = profile guided optimization). It's a multi-step build approach. At first the build system creates a special instrumented version of Python that collects runtime information. Then it executes tests to collect information how the code is used. Finally the build system builds Python again. The compiler uses the runtime information to create optimized code. Some distributions also use special compiler flags or other tricks to make Python even faster. Victor Stinner (a Python core dev) and his co-workers have done some research to speed up Python by up to 30% on top of PGO, https://developers.redhat.com/blog/2020/06/25/red-hat-enterprise-linux-8-2-brings-faster-python-3-8-run-speeds/ Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
Chris Angelico wrote: BTW, I just noticed something. The path you're using for testing purposes is "e:/net". Is that network-attached or local? If it's a remote mount of some sort, then that will make a HUGE difference No. Did the word 'net' make you think that :-) It's a local FAT32 partition where I keep old 'net' related projects. Whether it's NTFS or FAT32 should hopefully not matter for relative speed-compares. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: The speed of glob()
On Wed, Jul 29, 2020 at 8:25 PM Gisle Vanem wrote: > > Chris Angelico wrote: > > > BTW, I just noticed something. The path you're using for testing > > purposes is "e:/net". Is that network-attached or local? If it's a > > remote mount of some sort, then that will make a HUGE difference > > No. Did the word 'net' make you think that :-) It's a local > FAT32 partition where I keep old 'net' related projects. > Whether it's NTFS or FAT32 should hopefully not matter for > relative speed-compares. It made me wonder, and I asked just in case :) The file system quite probably WILL make a difference, but only in the sense that different FSes will see greater or lesser effect from the same changes. The direction of the change should be the same regardless. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Non IDE development strategy - what do others do that's fairly simple?
I have a few python programs that I have written which I need to do some fairly extensive changes to (to get from gtk to gobject and to move to Python 3). This is on a Linux (xubuntu 20.04) system. I use the command line to do just about everything (even though the program is GUI!) and so I tend to edit in one window and test in an adjacent window on the same screen, I don't find GUI development environments comfortable. The existing code simply lives in ~/bin with a couple of modules in ~/bin/pymods (which directory is in my PYTHONPATH). I use mercurial for configuration management of the code, directly in the ~/bin directory. This works fine for the sort of minor bug fixing and updates that I do most of the time, I'm the only user so changing the 'live' code isn't a major issue and I can always drop back to the last working version using mercurial. However with this more major change to do I really need a 'development' copy of the code as well as the live working copy as it's likely I will take a few days to do the changes (as in an hour or so each day over some days) and I need the ability to use the program meanwhile. So, finally to the question, does anyone else have this command line based sort of approach and, if so, what do they do to provide a 'development version' of a program in parallel with a working version? I guess virtualenv (Python 2) and venv (Python 3) address this problem but they do feel rather more complex than I actually need and I'm not very clear how you move code from the virtual environment to 'live'. There's also the issue that I'm moving code from Python 2 to Python 3 so which virtual environment should I use? Any ideas or suggestions would be very welcome. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Confused by python gtk, gobject, gi, etc. (Ubuntu repositories)
I am trying to move some code from Python 2, gtk 2 (I think!) to Python 3. I am very confused as to what Ubuntu repository packages I need to install to provide the Python 3 modules I need. Searching in the repositories (and descriptions) for pygobject what I find is:- python-gi-dev/focal 3.36.0-1 amd64 development headers for GObject Python bindings python-glade2/focal 2.24.0-0~201711230314~ubuntu18.04.1 amd64 GTK+ bindings: Glade support python-gobject-2-dev/focal,focal 2.28.6-14ubuntu1 all development headers for the static GObject Python bindings python-gtk2/focal,now 2.24.0-0~201711230314~ubuntu18.04.1 amd64 [installed] Python bindings for the GTK+ widget set python-gtk2-dbg/focal 2.24.0-0~201711230314~ubuntu18.04.1 amd64 Python bindings for the GTK+ widget set (debug extension) python-gtk2-dev/focal,focal 2.24.0-0~201711230314~ubuntu18.04.1 all GTK+ bindings: devel files python-gtk2-doc/focal,focal 2.24.0-0~201711230314~ubuntu18.04.1 all Python bindings for the GTK+ widget set - documentation python-gtkspellcheck/focal,focal 3.0-0~3~ubuntu14.04.1 all spellchecking library written in Python for Gtk based on Enchant python-gtkspellcheck-doc/focal,focal 4.0.5-2 all Python GTK+ Spellcheck common documentation python3-gtkspellcheck/focal,focal 4.0.5-2 all Python 3 spellchecking library for GTK+ based on Enchant python3-hinawa-utils/focal,focal 0.2.0-1 all Library to control Audio and Music units on FireWire (IEEE1394) So what do I need to install to get what I need? Is it python3-gi? I think it is but I'm not at all sure! Also, where do I find the pygi-convert.sh script? I have python3-gi installed but I don't have pygi-convert.sh. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Non IDE development strategy - what do others do that's fairly simple?
On 2020-07-29 at 11:20:42 +0100, Chris Green wrote: > I have a few python programs that I have written which I need to do > some fairly extensive changes to (to get from gtk to gobject and to > move to Python 3). This is on a Linux (xubuntu 20.04) system. I use > the command line to do just about everything (even though the program > is GUI!) and so I tend to edit in one window and test in an adjacent > window on the same screen, I don't find GUI development environments > comfortable. +1. All of it. Except that I'm on Arch rather than XUbuntu, and our definitions of "one window" and "adjacent" likely vary. > However with this more major change to do I really need a > 'development' copy of the code as well as the live working copy as > it's likely I will take a few days to do the changes (as in an hour or > so each day over some days) and I need the ability to use the program > meanwhile. Given that you develop in production, you might be better off thinking of the Python3 version as a new program rather than a simple maintenance upgrade of the existing one. > ... does anyone else have this command line based sort of approach > and, if so, what do they do to provide a 'development version' of a > program in parallel with a working version? > I guess virtualenv (Python 2) and venv (Python 3) address this problem > but they do feel rather more complex than I actually need and I'm not > very clear how you move code from the virtual environment to 'live'. > There's also the issue that I'm moving code from Python 2 to Python 3 > so which virtual environment should I use? All my development takes place under ~/src, which is mostly under source coontrol, but not under virtual environments. When I'm satisfied, I "release" or "install" to ~/bin and/or ~/lib by copying the relevant file(s). Too many years of work-related production environments being unavailable or unsuitable for development (unless you squint just right at the times I used to patch machine code on a hardware emulator). HTH, YMMV, etc. -- https://mail.python.org/mailman/listinfo/python-list
How to diagnose import error when importing from .so file?
I have some Python Gtk 2 code I'm trying to convert to Python pygobject GTK 3. However I'm stuck on an import statement that fails:- import pyscand The error message is:- File "/usr/libexec/okimfputl.new/guicom.py", line 66, in import pyscand ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: _Py_ZeroStruct pyscand is a .so file so I fear I may be a bit stuffed unless I can find the source code for it. However any other ideas would be most welcome. In fact looking for this error it seems that is is a Python version mismatch error and I need to recompile pyscand.so against Python 3. Is there no way to sort of convert it to Python 3 without having the source? -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows and Subclassing - 'OverflowError': int too long to convert
On 7/28/20, Eko palypse wrote:
>
> Now when I get this error the message I receive in this situation is always
> like this.
>
> hWnd=197364, msg=20, wParam=*18446744072652653190*, lParam=0
>
> Traceback (most recent call last):
> File "_ctypes/callbacks.c", line 237, in 'calling callback function'
> File "", line 121, in new_scintilla2_proc
> ctypes.ArgumentError: argument 4: : int too long to
> convert
Can you provide a more complete example of how you're calling
CallWindowProcW in new_scintilla2_proc? It seems like a function
pointer is being called that doesn't have argtypes defined. For
example:
>>> user32 = ctypes.WinDLL('user32', use_last_error=True)
>>> user32.CallWindowProcW(None, None, 0x14, 18446744072652653190, 0)
Traceback (most recent call last):
File "", line 1, in
ctypes.ArgumentError: argument 4: : int too
long to convert
Perhaps in new_scintilla2_proc you're using a different instance of
ctypes.WinDLL, or you switched to using ctypes.windll.user32. I
recommend avoiding the global ctypes.LibraryLoader instances --
ctypes.cdll, ctypes.windll, and ctypes.oledll -- because using them
leads to conflicts with other libraries, but you do need to use a
single instance of ctypes.WinDLL for your user32 function prototypes,
imported from a common module.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Local access to a file, How To ?
I guess that some things are just too simple to document. I searched man-a-site to find this but failed. open( "file.in" ) Works exactly as I want. Thanks. === Footnote: "What rhymes with orange?" "No it doesn't.." -Original Message- From: Python-list On Behalf Of DL Neil via Python-list Sent: Tuesday, July 28, 2020 6:15 PM To: [email protected] Subject: Re: Local access to a file, How To ? On 29/07/2020 08:56, Steve wrote: > I have a python program that reads and writes to files that are all > within the folder that contains the python program. There is now a > second python program that is to be run to compile information in said files. > > I am having difficulty trying to call the local supporting program > from within the main program. I would it would found easily because > everything is all in the same folder. Apparently, I have to decipher > paths to do the task. > > One problem is that the project is portable on a thumb drive and the > path can change based on the computer on which the program is > executed. I look up use of path and I seem to get all absolute path > instruction and not relative. > > Where an I steering wrongly here. Questions: - is the second program kept in the same directory as the first, or somewhere else? - by "call" do you mean "import", or... If the program and the data files are in the same directory, then you will have noticed that there is no need for absolute addressing, ie open( "file.in" ) not open( "/home/me/Projets/this/file.in" ) The same applies to import-s. From program_A we can import program_B in the same directory. No need for absolute paths, anywhere! That is to say, Python works happily with the concept of the "current working directory", and when no absolute-path is provided assumes 'this directory' - or if a non-absolute-path is provided (doesn't commence with "/", in the case of Posix) prefixes the path from 'this directory'. Yes, there are many caveats beyond such a simple explanation, but that should be enough to get-going. Keeping 'everything' in the single directory, and always executing from there, should enable migration. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: How to diagnose import error when importing from .so file?
> pyscand is a .so file so I fear I may be a bit stuffed unless I can > find the source code for it. > ... > In fact looking for this error it seems that is is a Python version > mismatch error and I need to recompile pyscand.so against Python 3. Is > there no way to sort of convert it to Python 3 without having the > source? Unfortunately, you'll need to recompile the .so file (or replace the dependency). Good luck! - DLD -- David Lowry-Duda -- https://mail.python.org/mailman/listinfo/python-list
Winreg
I'm running python 3.8 on Windows 8.1 x64. Running the following code produces no errors but does not add a key, name or value. I had no problems doing this using _wirreg under python 2.7. Any insight will be helpful. Code: === import winreg hive = winreg.HKEY_LOCAL_MACHINE keypath = 'SOFTWARE\\AAA_Newkey' host = None hosthive = winreg.ConnectRegistry( host, hive ) key = winreg.CreateKeyEx( hosthive, keypath, reserved=0, access=winreg.KEY_WRITE) winreg.SetValueEx( key, 'NewValueName', 0, winreg.REG_SZ, 'NewStringValue' ) key.Close() === -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows and Subclassing - 'OverflowError': int too long to convert
Hello Eryk,
thank you for your interest in my problem and you've nailed it, the problem
was solved by putting all Windows API definitions in a separate module and
making sure that I only use WinDLL.
I would never have thought of that, because I only used WinDLL in this
module.
But a PostMessage in another module, which I created with windll, seems to
have confused things a bit and now that I have merged this and other
modules into one, I don't see the problem anymore.
Here is the desired excerpt. (user32 is now import from win32api, where all
other definitions are now also)
def new_scintilla2_proc(self, hWnd, msg, wParam, lParam):
if self.__WndProc(hWnd, msg, wParam, lParam):
return 0
print(f'{hWnd=}, {msg=}, {wParam=}, {lParam=}')
return user32.CallWindowProcW(self.prev_scintilla2_wnd_proc, hWnd,
msg, wParam, lParam)
def __WndProc(self, hWnd, msg, wParam, lParam):
event_handler = self._event_handler.get(msg, None)
if event_handler:
return event_handler(msg, wParam, lParam)
return False
Once again, thank you
Eren
Am Mi., 29. Juli 2020 um 16:26 Uhr schrieb Eryk Sun :
> On 7/28/20, Eko palypse wrote:
> >
> > Now when I get this error the message I receive in this situation is
> always
> > like this.
> >
> > hWnd=197364, msg=20, wParam=*18446744072652653190*, lParam=0
> >
> > Traceback (most recent call last):
> > File "_ctypes/callbacks.c", line 237, in 'calling callback function'
> > File "", line 121, in new_scintilla2_proc
> > ctypes.ArgumentError: argument 4: : int too long
> to
> > convert
>
> Can you provide a more complete example of how you're calling
> CallWindowProcW in new_scintilla2_proc? It seems like a function
> pointer is being called that doesn't have argtypes defined. For
> example:
>
> >>> user32 = ctypes.WinDLL('user32', use_last_error=True)
> >>> user32.CallWindowProcW(None, None, 0x14, 18446744072652653190, 0)
> Traceback (most recent call last):
> File "", line 1, in
> ctypes.ArgumentError: argument 4: : int too
> long to convert
>
> Perhaps in new_scintilla2_proc you're using a different instance of
> ctypes.WinDLL, or you switched to using ctypes.windll.user32. I
> recommend avoiding the global ctypes.LibraryLoader instances --
> ctypes.cdll, ctypes.windll, and ctypes.oledll -- because using them
> leads to conflicts with other libraries, but you do need to use a
> single instance of ctypes.WinDLL for your user32 function prototypes,
> imported from a common module.
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to diagnose import error when importing from .so file?
On 29/07/2020 15.34, Chris Green wrote: > I have some Python Gtk 2 code I'm trying to convert to Python > pygobject GTK 3. > > However I'm stuck on an import statement that fails:- > > import pyscand > > > The error message is:- > > File "/usr/libexec/okimfputl.new/guicom.py", line 66, in > import pyscand > ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > _Py_ZeroStruct > > pyscand is a .so file so I fear I may be a bit stuffed unless I can > find the source code for it. However any other ideas would be most > welcome. > > In fact looking for this error it seems that is is a Python version > mismatch error and I need to recompile pyscand.so against Python 3. Is > there no way to sort of convert it to Python 3 without having the > source? You are right. The extension module is compiled for Python 2. _Py_ZeroStruct is only available in Python 2. You need the C code for the extension module. and possibly even modify the C code to make the extension work with Python 3. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: How to diagnose import error when importing from .so file?
Christian Heimes wrote: > On 29/07/2020 15.34, Chris Green wrote: > > I have some Python Gtk 2 code I'm trying to convert to Python > > pygobject GTK 3. > > > > However I'm stuck on an import statement that fails:- > > > > import pyscand > > > > > > The error message is:- > > > > File "/usr/libexec/okimfputl.new/guicom.py", line 66, in > > import pyscand > > ImportError: /usr/libexec/okimfpdrv/pyscand.so: undefined symbol: > > _Py_ZeroStruct > > > > pyscand is a .so file so I fear I may be a bit stuffed unless I can > > find the source code for it. However any other ideas would be most > > welcome. > > > > In fact looking for this error it seems that is is a Python version > > mismatch error and I need to recompile pyscand.so against Python 3. Is > > there no way to sort of convert it to Python 3 without having the > > source? > > You are right. The extension module is compiled for Python 2. > _Py_ZeroStruct is only available in Python 2. You need the C code for > the extension module. and possibly even modify the C code to make the > extension work with Python 3. > Thanks for confirming, though it's not good news really as the chances of getting the C code to recompile pyscand.so are minimal. It's a piece of code provided by OKI and I don't really think I'll be able to get the code out of them. Even more annoying is that most of what's in pyscand.so is constants, there's only a couple of functions in there, so there's very little to it really. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Winreg
> On 29 Jul 2020, at 19:50, R Pasco wrote: > > I'm running python 3.8 on Windows 8.1 x64. Running the following code > produces no errors but does not add a key, name or value. I had no problems > doing this using _wirreg under python 2.7. Any insight will be helpful. How do you check that the key is present? Are you aware that there is one registry for 32 bit code and a separate registry for 64 bit code. if you run a 32 bit program to write the registry it will not be seen by 64 bit code for example. Barry > > Code: > === > import winreg > > hive = winreg.HKEY_LOCAL_MACHINE > keypath = 'SOFTWARE\\AAA_Newkey' > host = None > hosthive = winreg.ConnectRegistry( host, hive ) > key = winreg.CreateKeyEx( hosthive, keypath, reserved=0, > access=winreg.KEY_WRITE) > winreg.SetValueEx( key, 'NewValueName', 0, winreg.REG_SZ, 'NewStringValue' ) > key.Close() > === > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
why is requests 2.24 behaving differently on different Win10Pro PCs?
python 3.6+ requests 2.24 2- windows 10 Pro version 2004, build 19041.388 1- kubuntu 18.04 1-suse leap 15.2 Questions 1. how do I begin to diagnose the source of the problem? 2. Has anyone experienced this behavior? I have 4 PCs running the same code. On 3 they work, but 1 fails. I have 2 win10Pros running the same code on the same network on the same subnet, which uses "requests.get()" 1 PC works fine; the code executes perfectly, but the other FAILS. (statusCode = 200, but the website doesn't send webpage) The error response from the website: We've detected unusual activity from your computer network To continue, please click the box below to let us know you're not a robot. Why did this happen? Please make sure your browser supports JavaScript and cookies and that you are not blocking them from loading. For more information you can review our Terms of Service and Cookie Policy. BTW, I tried reverting back to "urllib.request" and the same problem appears. 1 PC works the other fails. I even tried "HTMLsession" which renders javascript. Same problem. -- https://mail.python.org/mailman/listinfo/python-list
