[Python-Dev] Default SIGINT handling dangerous?
Hi all. Is there any way to disable the default asynchronous exception raising SIGINT signal handling? Or a plan to add support for this? My searches on the net found several bug reports and discussions regarding this, but nothing seems final... :-( I believe the current Python default SIGINT handling by raising an asynchronous KeyboardInterrupt exception is dangerous, and can directly cause Python interpreter crashes even if no user code is involved, or any sort of other 'undefined behaviour' if it is. On Windows at least (using Python 3.3.3 at the moment, but seen with earlier versions as well), I occasionally get 'python.exe has stopped working' dialogs when Ctrl-C is pressed (most often if pressed during Python's initialization - loading site.py or earlier). The problem with asynchronous exceptions is, of course, that they can occur at _any_ time, even at the start of a finally: block, effectively causing cleanup code to be skipped even though the programmer intended it to be called even in case of exceptions. My scripts replace the default SIGINT/SIGBREAK signal handlers as soon as possible, and everything works great after that, but things get ugly if Ctrl-C is pressed before the script gets a chance to do this. I could even live with an 'exit with an ugly traceback', but having the process hang or fail so that Windows reports it as non-responding or reports it as 'stopped working' and offers to send failure information to Microsoft? That just leaves a bad taste in my mouth. :-( Also, Python documentation should not helpfully state or infer in several places that user can handle KeyboardInterrupt exceptions to implement Ctrl-C handling. Even if you do manage to catch it, you must never ever ignore it and must terminate your application since it might have already been left in an inconsistent state internally (e.g. some important finally clause got skipped, even one located deep in the Python standard library internals). Doing anything else can only be considered a partially working hack. Another problem is that that multiple SIGINT signals might occur in a sequence and any such KeyboardInterrupt handling can itself be interrupted in the same way as the original code. You can say that this is 'unlikely', or even add additional code to make this even more unlikely, but it still smells bad. :-( Hope this helps. Best regards, Jurko Gospodnetić Below, I've included a few script outputs (tracebacks included) from instances where Python interpreter crashed due to pressing Ctrl-C soon after an empty Python script has been run. In the first of these instances I got the Microsoft's error reporting dialog. In all the later instances I checked the Python process's debug output and every time it included the message: 'Microsoft Visual Studio C Runtime Library has detected a fatal error in python.exe.'. Using: - OS: Windows 7 SP1 x64 - Python 3.3.3 (64-it) - default site.py -- Occurrence #1: -- D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "", line 755, in _open_registry FileNotFoundError: [WinError 2] The system cannot find the file specified During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function level=0) File "", line 1565, in _find_and_load File "", line 1523, in_find_and_load_unlocked File "", line 1477, in _find_module File "", line 777, in find_module File "", line 768, in _search_registry File "", line 755, in _open_registry KeyboardInterrupt -- Occurrence #2: -- D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "C:\Program Files\Python\Python333\lib\codecs.py", line 165, in __init__ def __init__(self, errors='strict'): KeyboardInterrupt -- Occurrence #3: -- D:\Workplace>run.py Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "", line 1565, in _find_and_load File "", line 1523, in _find_and_load_unlocked File "", line 1477, in _find_module File "", line 1309, in find_module File "", line 1288, in _get_loader File "", line 1387, in find_loader File "", line 110, in _path_isfile File "", line 101, in _path_is_mode_type KeyboardInterrupt -- Occurrence #4: -- D:\Workplace>run.py Fatal Python error: Py_Initializ
Re: [Python-Dev] Default SIGINT handling dangerous?
Hi. On 14.12.2013. 17:14, R. David Murray wrote: On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" wrote: My scripts replace the default SIGINT/SIGBREAK signal handlers as soon as possible, and everything works great after that, but things get ugly if Ctrl-C is pressed before the script gets a chance to do this. I could even live with an 'exit with an ugly traceback', but having the process hang or fail so that Windows reports it as non-responding or reports it as 'stopped working' and offers to send failure information to Microsoft? That just leaves a bad taste in my mouth. :-( This sounds like a more troubling variation on the issue raised in issue 14288 (http://bugs.python.org/issue14228). The solution proposed there would appear to be something that would help you, so you might want to chime in on that issue. Thanks for the tip. I've seen the bug report you mention before, but thought to first inquire about the issue on the mailing list. I'll chime in what I know to the bug report. Final solution proposed there is to add a command-line option to delay enabling current default Python SIGINT handling until after the site.py package has been loaded. That would most likely avoid the startup crashes I mentioned in the original post. On Unix it would make Ctrl-C silently terminate the process if it occurs before default Python signal handling is enabled. I do not know what effect this would have on Windows - possibly the signal would simply be ignored & lost. It would also still leave a slight window between when Python sets up its default SIGINT handling and when user code has a chance to set up its own. My first instinct is to not do that and instead add an option to block SIGINT handling and allow user code to enable its own or default Python handling as it wishes and then unblock SIGINT handling. Note that by 'blocking' a signal I do not mean losing/ignoring it but delaying its handling until signal handling is unblocked. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Default SIGINT handling dangerous?
Hi.
On 15.12.2013. 0:19, Antoine Pitrou wrote:
It would be nice if you could get an actual C traceback
> and open an issue on the bug tracker.
Done. C traceback and related information collected and attached to a
new Python issue report available at:
http://bugs.python.org/issue19983
Python isn't supposed to crash willy-nilly when Ctrl+C is
pressed.
:-D
(also, which Python version is this?)
- Python 3.3.3 (64-bit) downloaded from:
http://www.python.org/download/releases/3.3.3
- OS: Windows 7 SP1 x64
- default site.py
Hope this helps.
Best regards,
Jurko Gospodnetić
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] undocumented help() function change in Python 3.4?
Hi. I just noticed that the way help() function displays a function signature changed between Python 3.3 & 3.4 but I can not find this documented anywhere. Here's a matching example in both Python 3.3 & Python 3.4 for comparison: Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(*args, **kwargs) Python 3.4.0b3 (v3.4.0b3:a97ce3ecc96a, Jan 26 2014, 17:50:55) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. def f(a, b, c): ... print(a, b, c) ... def g(*args, **kwargs): ... f(*args, **kwargs) ... import inspect print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (*args, **kwargs) g.__wrapped__ = f print(inspect.signature(f)) (a, b, c) print(inspect.signature(g)) (a, b, c) help(f) Help on function f in module __main__: f(a, b, c) help(g) Help on function g in module __main__: g(a, b, c) As you can see by comparing those two outputs, setting the __wrapped__ attribute on a wrapper function affects the inspect.signature() results on that function. This behaviour is the same in both Python 3.3. & 3.4 and is (somewhat) described in the Python documentation. However, help() output is not affected by this in Python 3.3, but is affected in Python 3.4, and I can not find anything regarding this in the Python 3.4 docs. Can something related to this be added at least to the 'what's changed' docs, if not to the help() documentation as well? Best regards, Jurko Gospodentić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi all.
Python 3.4 introduced a change to Lib/importlib/__init__.py that
added the following code to it:
else:
# importlib._bootstrap is the built-in import, ensure we don't create
# a second copy of the module.
_bootstrap.__name__ = 'importlib._bootstrap'
_bootstrap.__package__ = 'importlib'
_bootstrap.__file__ = __file__.replace('__init__.py', '_bootstrap.py')
sys.modules['importlib._bootstrap'] = _bootstrap
When attempting to use cxFreeze on a project, using Python 3.4. we
ran into a problem with '__file__' identifier not being defined.
Could this be a python bug? Why is this code expecting the module
loaded from importlib/__init__.py to always have a __file__ identifier?
What is supposed to happen when that code gets loaded from a ZIP archive?
Just wanted to check here before filing an issue... but if this is an
issue I hope it can be resolved before the final 3.4 release.
Best regards,
Jurko Gospodnetić
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Hi. When running the Python Windows installer 'for all users', the 32-bit installation and the 64-bit installation each gets a separate registration in the Windows registry. E.g. under: HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4 and: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.4 However, when running the installer 'for the current user only', the 32-bit and the 64-bit installation both use the same Windows registry key: HKEY_CURRENT_USER\Software\Python\PythonCore\3.4 Note that a 64-bit installation does not automatically uninstall a previous 32-bit installation in either case, or vice versa. Why the mismatch? As I understand it, whichever installation you use, you should be able to run a specific Python interpreter using the py.exe runner, as it: py.exe -3.4 py.exe -3.4-32 As it stands now - both of those run the same interpreter when they have been installed 'for the current user only'. Is this as issue or desired behaviour? Should I open an issue for it? Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] undocumented help() function change in Python 3.4?
Hi. On 8.3.2014. 6:48, Nick Coghlan wrote: Yeah, the changes to help() are doubly indirect - help() uses pydoc which uses inspect, and inspect saw a lot of changes. I'll make a few updates to the What's New to help make the consequences of this clearer. Just looked through the latest 3.4rc3 release and nothing related to this seems to have been included yet. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi Nick. On 10.3.2014. 14:25, Nick Coghlan wrote:> What is supposed to happen when that code gets loaded from a ZIP archive? > > __file__ is expected to always be set (including when loaded from a > zipfile - in that case it's the zipfile name concatenated with the > path within the zip file). If it isn't set, there's a buggy loader > involved somewhere that isn't setting it properly. I don't recall seeing that ever explicitly stated. For that matter, Python 3.4.0rc3 documentation explicitly states: > __file__ is optional. If set, this attribute’s value must be a string. > The import system may opt to leave __file__ unset if it has no > semantic meaning (e.g. a module loaded from a database). and: > Ultimately, the loader is what makes use of __file__ and/or __cached__. Or is this some rule specific to the importlib/__init__.py stdlib module? As I recall, I first learned that not all loaded modules need to have their __file__ attribute set by researching a failure in some package when installed as a zipped-egg using setuptools. Admittedly though, that was some old setuptools version. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Hi Paul. On 10.3.2014. 14:54, Paul Moore wrote: On 10 March 2014 13:03, Jurko Gospodnetić wrote: Is this as issue or desired behaviour? Should I open an issue for it? Sounds like a bug, but a pretty long-standing one. I can't think that the registry schema Python uses would *ever* have distinguished (the WOW64 component of the all-users entries is a system-generated thing, AIUI). So yes, raise a bug, but (a) it would be useful to test whether the same bug exists in 3.3 and 2.7, and (b) it's going to be tricky to fix without a backward-incompatible change to the registry settings (which will affect things like the launcher and virtualenv, for a start). Reported as issue #20883 (http://bugs.python.org/issue20883). I'll report the extra details there then. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi Brett.
On 10.3.2014. 16:44, Brett Cannon wrote:
> __file__ is optional and left off when it doesn't make any sense.
> Since importlib._bootstrap is a frozen module by default it doesn't
> have __file__ set.
Issue #20884 opened for this (http://bugs.python.org/issue20884).
Best regards,
Jurko Gospodnetić
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.4.0 - missing information on the web
Hi. On 17.3.2014. 7:29, Larry Hastings wrote: On behalf of the Python development team, I'm thrilled to announce the official release of Python 3.4. [...lots of great enhancements snipped...] Just noted that 'https://www.python.org/download' still lists Python 3.4.0rc2 as the latest 'testing release' (and does not mention the final Python 3.4.0 release at all). Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.4.0 - PEP 429 needs updating?
Hi. On 17.3.2014. 11:35, Ned Deily wrote: Thanks for the report. That and other download pages should now be up-to-date. Something similar - does PEP 429 (Python 3.4 Release Schedule) need to be updated? It still lists 3.4.0rc3 as a 'future release'. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
Hi all.
This seems like it should be an 'old' issue, but I have not been able
to find anything related to it on the web.
When you install 32-bit CPython 'for the current user only' on 64-bit
Windows, the installation does not show up in the Windows 'Add/Remove
Programs' dialog (a.k.a. 'Programs and Features' dialog on Windows 7).
It does not show up there even for the current user.
As a consequence it is possible for the user to end up in a situation
where it is impossible to install a 32-bit Python installation without
manually cleaning up a previous 32-bit Python installation's Windows
Installer related registry entries (more on this a bit later).
I tested this CPython installation behaviour with the following
CPython versions:
* 2.3.4 - works correctly
* 2.5.4 - works correctly
* 2.6.0 - works correctly
* 2.6.2 - works correctly
* 2.6.3 - does not work correctly
* 2.6.4 - does not work correctly
* 2.6.6 - does not work correctly
* 2.7.6 - does not work correctly
* 3.3.3 - does not work correctly
* 3.3.5 - does not work correctly
* 3.4.0 - does not work correctly
Several related observations, indicating that this could be some sort
of a Windows Installer misconfiguration issue possibly solvable in the
CPython installer:
* The same does not occur when you install a 64-bit CPython version -
their entry is correctly displayed in the 'Add/Remove Programs' dialog.
* 32-bit CPython installer still correctly detects that a specific
32-bit version has already been installed, even if that previous
installation is not listed in the 'Add/Remove Programs' dialog.
* When you ask Windows using its WMI interface to list all the
products installed on it (e.g. by running 'wmic product list' on the
command-line), all the installed CPython versions are correctly
displayed, even those 32-bit versions not displayed in the 'Add/Remove
Programs' dialog.
I started looking into this because I had a 32-bit CPython 3.4.0rc3
installation on my system that I wanted to remove, and since I did not
see it registered in the 'Add/Remove Programs' dialog, I directly
deleted its installation folder. That left my system in a state where a
replacement 32-bit CPython 3.4.0 installation would always fail because
it would detect that there was already a valid CPython 3.4 installation
on the system, and then it would fail attempting to uninstall it. Fixing
this required manually cleaning up leftover CPython 3.4.0rc3 windows
installer registry entries. Note that the issue could not be fixed by
using the CPython 3.4.0rc3 installer as it failed due to the same problem.
This situation would suggest that something should be done in the
Windows installer so it does not 'fail miserably' if a previous CPython
installation can not removed. Possibly allow it to detect that the
previous CPython installation has already been removed and simply clean
up its Windows Installer registry entries.
While working on this, I did discover a 'workaround' for the
'Add/Remove Programs' dialog issue, but it will take someone more
knowledgeable about the Windows Installer infrastructure to say if the
workaround can be applied directly as a clean solution or if it could
have hidden consequences:
Each 32-bit installation on 64-bit Windows has its own 'Uninstall'
registry key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
named after its Windows Installer assigned GUID, e.g.:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040}
In that key there is a value named 'WindowsInstaller' which for
CPython installations has the value '1' (of type REG_DWORD).
If you change that value to '0' (again, of type REG_DWORD), the
installation's 'Add/Remove Programs' dialog entry will get displayed
correctly, and user will be able to run the installation
(reinstall/change/uninstall) from there.
I compared MSI packaging related CPython source code (Tools/msi
folder) in 2.6.2 & 2.6.3 releases but I can not see anything suspicious
there. It could be that the observed beaviour change between those two
versions is a result of the final release packager changing his used
Windows Installer version, but I have not rebuilt CPython, and its MSI
installer to test this theory out.
Anyone have any more information on this?
Should I open a 'Add/Remove Programs' dialog related issue in the
CPython issue tracker? And possibly a separate one for making CPython
installations not fail without possible recovery if a previous CPython
installation has already been removed?
Many thanks.
Best regards,
Jurko Gospodnetić
P.S.
All this has been tested
Re: [Python-Dev] 'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
Hi. On 19.3.2014. 16:38, "Martin v. Löwis" wrote: > Am 17.03.14 22:10, schrieb Jurko Gospodnetić: >> Fixing >> this required manually cleaning up leftover CPython 3.4.0rc3 windows >> installer registry entries. Note that the issue could not be fixed >> by using the CPython 3.4.0rc3 installer as it failed due to the >> same problem. > > Did you try the 3.4.0rc3 "repair" installation? That should have > undeleted (repaired) the files that you had manually deleted. Just tested this out and repairing the same matching installation does revert the removed files. It does not reinstall pip and setuptools packages but that can be done easily by hand and so can be filed as a minor enhancement issue for the future. That at least provides a way to remove the the original installation in some way without having to manually remove its related Windows Installer registry entries. The problem with the 'Add/Remove Programs' dialog still makes this issue a bit complicated because a user not well versed in how Windows Installer tracks its installations internally would not see the installation in the 'standard place' where he is supposed to look for it, and would just be told by the new installation that 'something failed'. To use a 'repair' installation he would need to 'guess' which installation he used before and run its installer directly. When the 'Add/Remove Programs' dialog is fixed, user will be able to see & repair the installation from there, and even remove it directly if the uninstallation fails (I recall Windows asking if you want this if it can not uninstall something). I'll try to open an issue for the 'Add/Remove Programs' dialog issue soon, and I'll add a comment about the 'repair' situation there as well. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
Hi. > Did you try the 3.4.0rc3 "repair" installation? That should have > undeleted (repaired) the files that you had manually deleted. Just tested this out and repairing the same matching installation does revert the removed files. It does not reinstall pip and setuptools packages but that can be done easily by hand and so can be filed as a minor enhancement issue for the future. This minor problem reported as issue #20983. http://bugs.python.org/issue20983 Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
Hi. On 19.3.2014. 16:38, "Martin v. Löwis" wrote: Am 17.03.14 22:10, schrieb Jurko Gospodnetić: Fixing this required manually cleaning up leftover CPython 3.4.0rc3 windows installer registry entries. Note that the issue could not be fixed by using the CPython 3.4.0rc3 installer as it failed due to the same problem. Did you try the 3.4.0rc3 "repair" installation? That should have undeleted (repaired) the files that you had manually deleted. I tried different things back then, and I'm 90% sure I tried that one as well. Unfortunately, my brain is already trying to block out that painful afternoon so I can't tell you for certain. :-) But, all kidding aside, I'll try to reproduce the issue again and let you know the exact details. Should I open a 'Add/Remove Programs' dialog related issue in the CPython issue tracker? Please do. It would also good if somebody volunteered to reproduce the issue. Will do. FYI, I did reproduce the 'Add/Remove Programs' dialog issue on another PC in the mean time. Also Windows 7 x64 though. Unfortunately, I don't have other 64-bit OSs readily available at the moment. And possibly a separate one for making CPython installations not fail without possible recovery if a previous CPython installation has already been removed? Please don't. Or, at least, make it more specific. If you have manually corrupted your Python installation (by deleting essential files), you have to accept that the system installation procedures will fail. It might be possible to recover from the loss of a specific such file; for that, we would have to identify what the file is. However, the standard procedure should be to repair the installation before attempting an upgrade. Ok, as I stated above, I'll get back to you on this once I reproduce the 'corruption' issue again. Oh, and many thanks for replying! :-) Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
Hi. Should I open a 'Add/Remove Programs' dialog related issue in the CPython issue tracker? Please do. It would also good if somebody volunteered to reproduce the issue. Opened issue #20984. http://bugs.python.org/issue20984 Anyone have Windows 8 x64 available to try this out by any chance? Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 453 (Explicit bootstrapping of pip in Python installations) - slight typo
Hi. Not really sure where to report this - missing closing parentheses in the PEP text at the end of the second paragraph in section 'Implementation strategy' http://legacy.python.org/dev/peps/pep-0453/#id35 > and would not try to contact PyPI (instead installing directly > from the private wheel files. Hope this helps. Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is what happens if you freeze all the modules required for startup
Hi. On 14.4.2014. 23:51, Brett Cannon wrote: Now the question is whether the maintenance cost of having to rebuild Python for a select number of stdlib modules is enough to warrant putting in the effort to make this work. I would really love to have better startup times in production, but I would also really hate to lose the ability to hack around in stdlib sources during development just to get better startup performance. In general, what I really like about using Python for software development is the ability to open any stdlib file and easily go poking around using stuff like 'import pdb;pdb.set_trace()' or simple print statements. Researching mysterious behaviour is generally much much MUCH! easier (read: takes less hours/days/weeks) if it ends up leading into a stdlib Python module than if it takes you down into the bowels of some C module (think zipimport.c *grin*). Not to mention the effect that being able to quickly resolve a mystery by hacking on some Python internals leaves you feeling very satisfied, while having to entrench yourself in those internals for a long time just to find out you've made something foolish on your end leaves you feeling exhausted at best. Not considering the zipped stdlib technique mentioned in other posts, would it perhaps be better to support two different CPython builds: - one with all the needed stdlib parts frozen - to be used in production - one with only the minimal needed number of stdlib parts frozen - to have as much of the stdlib sources readily accessible to application developers as possible The installer could then perhaps install both executables, or the frozen stdlib parts could perhaps be built as a separate DLL to be loaded at runtime instead of its content being used from their Python sources. OK... just my 2 cents worth... :-) Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is what happens if you freeze all the modules required for startup
Hi. On 17.4.2014. 20:15, Mark Young wrote: I think he meant modifying the source files themselves for debugging purposes (e.g. putting print statements in itertools.py). Exactly! :-) Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is what happens if you freeze all the modules required for startup
Hi. On 17.4.2014. 19:57, Guido van Rossum wrote: On Thu, Apr 17, 2014 at 10:33 AM, Jurko Gospodnetić mailto:jurko.gospodne...@pke.hr>> wrote: I would really love to have better startup times in production, What's your use case? I understand why startup time is important for Hg, but I'd like to understand what other situations occur frequently enough to worry about it. The first one that pops to mind is scripting when automating different system administration tasks. When you automate something that ends up calling lots of different Python scripts - the startup times add up. Yes, I know you can update the system so that the scripts get called inside a single Python process, but that often requires major refactoring, e.g.: - you have to refactor those scripts to be importable while they were originally prepared to be used as 'stand-alone executables' - you either have to use Python as your external automation tool or you need to implement some sort of a Python based tool runner daemon process Another example is the speed at which some automated test suits run that need to call external Python scripts. Such suites often call thousands of such scripts so their startup times add up to such numbers that Python gets a bad rep. And shaving off unnecessarily wasted seconds or minutes in a test suite is always good, as it speeds up the whole develop/test cycle. :-) I've been in situations where I got a request to 'convert those Python scripts to batch files so they would run faster'. :-) And, while I really love Python as a development language, simple scripts implemented in it often do make the system feel kind of sluggish. :-( And with that in mind, the effect of systems becoming 'even more sluggish' when upgrading them to use the new 'Python 3' version, even if that slowdown is not all startup related, often comes as an additional slap in the face. :-( Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler
Hi. On 6.6.2014. 21:46, Guido van Rossum wrote: A reminder: https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg *ROFL* Subtle, ain't he? *gdr* Best regards, Jurko Gospodnetić ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
