[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: Hi Steve, Thanks for a quick reply. > Yeah, this whole issue is basically because Burn (our installer tool) won't do > per-machine bundle registration even when it's only installing per-machine > packages. So the install block that it would normally throw up fails if you > use a different user account to install it the second time. Hmmm, I'm not sure this is exactly the case as this seems to happen even when we install Python using the `systemuser` user account initially and then rerun the installer using that same user account. Might I suggest adding this information to some 'known defects/limitations' Python documentation though? Together with more details on what it implies and how to deal with it? The current behaviour definitely does not seem like something one would expect as a user. > > (Python gets installed as a step in one of our installers) > > I'm intrigued by this - if Python is a dependency of your application, it's > better to repackage it yourself and install to your own directory. The > installer is basically there for end-users, but if you're not doing an > end-user kind of install there's really nothing gained. > > This whole scenario is fairly under-developed though. It comes up quite > infrequently, so we don't have any really convenient instructions on how to go > about it. Doesn't mean we can't help, but because we don't have a clear idea > of what you may be trying to achieve, we'd like to hear about it before > telling you how to approach this kind of thing. Our thinking was that if Python already wrapped up all of its installation logic to 'work correctly' (clean install, upgrade, uninstall, detecting files already in use, updating any relevant registry settings or globally installed files, etc.), we might as well use that, so we run the installer in silent mode and just process its exit code for stuff like errors, reboot required, etc. Logically the same process that Microsoft gives as the official way to install its Visual Studio run-time libraries (not saying that process is not filled with its own caveats :-D). We can of course take the installed Python distribution folder content and package that up in our installer directly, and that would avoid the official Python installer problems. We were hoping to avoid the problem of manually updating such a repackaging, e.g. Python deciding to add some more data to the Windows registry, some add-on installation copes with that and now requires that information to work correctly as well so now we have to debug/detect that also and tweak our installer to do the same, deal with any related version updating logic, etc. By embedding your installer, our 'Python version upgrade' process basically becomes: - pop the new Python installer into our 3rdparty library archive - update the used Python version configuration - run the installer build So if this bad installer behaviour is not going to get fixed, I guess we'll go and play with getting this working using Python's Windows embeddable zip file distribution instead. All suggestions welcome. :-) Thanks again! Best regards, Jurko Gospodnetić -- ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Change by Jurko Gospodnetić : -- versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Change by Jurko Gospodnetić : -- versions: -Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: Some other potentially related issues: - https://bugs.python.org/issue25164 - https://bugs.python.org/issue32966 - https://bugs.python.org/issue37756 And some other related links: - https://docs.microsoft.com/en-us/troubleshoot/windows-server/application-management/msi-installation-error-1603 - https://superuser.com/questions/1238473/cant-uninstall-python-3-6-on-windows-10 - https://www.programmersought.com/article/41342430755/ - https://www.programmersought.com/article/41342430755/ And I'm attaching some of the Python installer logs I found from one of the debugging sessions researching this problem. It contains logs from a few installation runs and you can see there from the first log file in each batch and from the names of the other log files that the initial two failed while the last one was presumably done after an uninstall and worked. -- Added file: https://bugs.python.org/file49461/Python 3.8.3 (32-bit)_20200723053832.7z ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29033] Windows Python installer rolls back when run under SYSTEM account (SCCM)
Jurko Gospodnetić added the comment: This seems related to https://bugs.python.org/issue41800. -- nosy: +Jurko.Gospodnetić ___ Python tracker <https://bugs.python.org/issue29033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
Jurko Gospodnetić added the comment: This also seems related to https://bugs.python.org/issue29033. -- ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41800] Python installation fails when run under system account if there is already an existing installation on the system already
New submission from Jurko Gospodnetić : This issue seems to affect all Python 3 Windows installers. Reproduced on: - various Windows 10 systems - one Windows 8 system - one Windows 7 system - all tested Python 3+ installers up to and including 3.8.5 Scenario: 1. there is already an existing Python 3+ installation on a Windows system, installed for all users 2. you run a Python 3+ installer (any version, even the one matching the already installed Python version) under the `systemprofile` Windows user account, targeting all users and the same target folder that the currently existing installation is located in - example how to do this manually: - using the Microsoft/SysInternals `psexec` utility to open a command prompt running under the `systemprofile` Windows user account: `psexec -i -s cmd` - run the Python installer from that command-prompt, in our case it was the following command: `python-3.8.5.exe /passive TargetDir=C:\Python38 InstallAllUsers=1 PrependPath=1` 3. result will be any of the following at random: - failed installation with different Windows error codes, including totally opaque 0x80070643 `Fatal Error during installation` - successful installation - seemingly successful installation that does not really install all the Python components, e.g. the whole `Lib` folder may end up being empty - seemingly successful installation that then can not be uninstalled as the uninstaller reports that it can not find the existing installation on the system - this effect can often, but not always, be fixed by rerunning the installer and then running the uninstaller - you can run the uninstaller from the command-line using something like: `python-3.8.5.exe /uninstall /passive` Additional notes on produced results: - each installation seems to generate differently named log files in the `C:\Windows\Temp` folder, i.e. the `systemprofile` user account's `%TEMP%` folder - the log file names indicate whether each specific component is being installed for the current-user or all-user variants, and those seem to be chosen at random in our problematic scenario - it seems like the components whose log files are marked as being installed for the current user are not getting installed at all, or may possibly be getting installed to some other undisclosed location The same does not occur if any of the following is true: - if the installation is run from an regular end-user account - if there is no Python currently installed on the system A workaround we found in our case (Python gets installed as a step in one of our installers) is to basically do (uninstall, install) in a loop with some hand-crafted checking to see if the existing installation is ok (includes running some Python code + checking for some specific Python distribution files we've found to be missing in some scenarios). -- components: Installation messages: 377039 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Python installation fails when run under system account if there is already an existing installation on the system already versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue41800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38905] venv python reports wrong sys.executable in a subprocess on Windows
Jurko Gospodnetić added the comment: encountered what I believe is the same problem, so here are some more details I noticed, after checking what exactly that process name lookup does using ProcessMonitor: - when running my external process in a `venv` generated virtual environment, POpen() started subprocess executables are first looked up in the base Python executable's folder (the one used to create our virtual environment) as opposed to the one running the external Python process, if POpen() is called with `shell=False` - when doing the same and passing `shell=True` to the POpen() call, there is no such initial folder in the lookup - when doing the same on a `virtualenv` generated virtual environment, the file lookup is done in the correct folder first - the one containing the current Python executable and not in the base one -- nosy: +Jurko.Gospodnetić ___ Python tracker <https://bugs.python.org/issue38905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Jurko Gospodnetić added the comment: Here's another patch fixing the Visual Studio Express edition issue plus some minor related code-cleanup. See the Hg repo at: https://bitbucket.org/jurko/cpython branch: jurko/distutils_msvc_express_fix direct link: https://bitbucket.org/jurko/cpython/commits/branch/jurko/distutils_msvc_express_fix Basically - native 64-bit compiler is not available with Visual Studio Express edition, but its 32-bit to 64-bit cross-compiler is, so the fix just attempts to configure the cross-compiler if configuring the native compiler fails to set all the necessary environment variables. Tested to work correctly with Visual Studio Express edition installed, and no additional Platform SDK. I'm also directly attaching a bundle containing the same commits. I've split up the changes into cleanly separated commits so they should be real easy to review verify, and there should be no risk of breakage in use cases not explicitly attacked by the proposed changes. Hope this helps. Best regards, Jurko Gospodnetić -- hgrepos: +274 nosy: +Jurko.Gospodnetić Added file: http://bugs.python.org/file36822/CPython_msvc_express_fix_based_on_ec3077e23b7d1353af65a987d4caaef4343bdb41.hg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file36823/218ef482e1e4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Removed file: http://bugs.python.org/file36823/218ef482e1e4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument
New submission from Jurko Gospodnetić: If you have an optional nargs=argparse.REMAINDER argument defined then, if specified, its value should contain all the remaining command-line content. However, it seems that value does not include later '--' arguments. For example, the following works as expected: import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(--args, nargs=argparse.REMAINDER) args = parser.parse_args(--args cmd --arg1 XX ZZ.split()) assert args.args == [cmd, --arg1, XX, ZZ] But the following fails with 'PROG: error: unrecognized arguments: -- ZZ': import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(--args, nargs=argparse.REMAINDER) args = parser.parse_args(--args cmd --arg1 XX -- ZZ.split()) assert args.args == [cmd, --arg1, XX, --, ZZ] Note that the same code works as expected when using a positional nargs=argparse.REMAINDER arguments: import argparse parser = argparse.ArgumentParser(prog=PROG) parser.add_argument(args, nargs=argparse.REMAINDER) args = parser.parse_args(args cmd --arg1 XX ZZ.split()) assert args.args == [cmd, --arg1, XX, ZZ] args = parser.parse_args(args cmd --arg1 XX -- ZZ.split()) assert args.args == [cmd, --arg1, XX, --, ZZ] But that, of course, does not allow us to have the args value start with something like --blah that looks like an optional argument. Hope this helps. Best regards, Jurko Gospodnetić -- components: Library (Lib) messages: 225484 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: argparse not including '--' arguments in previous optional REMAINDER argument type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22223] argparse not including '--' arguments in previous optional REMAINDER argument
Jurko Gospodnetić added the comment: Might be related to the following issues: http://bugs.python.org/issue9571 http://bugs.python.org/issue13922 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to distribute python console program
Hi Nicholas. On 22.6.2014. 4:51, Nicholas Cannon wrote: I have a simple program that is ran in the console with 2 modules and i was wondering how i could like export it so i could give it to someone to use as like a utlitie in the console? Assumptions: * You have one script - script.py, using two additional module - module1.py module2.py. * You want to hold the script in some generic Utility folder (on your system path or wherever). Let's refer to that folder as 'D:\Utility', just to make it seem more realistic. * Target machine already has the desired Python environment installed. The simplest 'all in one' solution would be to simply copy script.py, module1.py module2.py into the 'D:\Utility' folder. Then you can run script.py as a script (using whatever Python environment you prefer) and its folder (i.e. 'D:\Utility') will automatically be added to the Python path, ergo module1.py module2.py can be easily imported using 'import module1' 'import module2' respectively. One possible bad side to this organization is that the user does not necessarily know what module1.py module2.py files are - they are stored together with other utility scripts but need not be runnable scripts by themselves. If they can be run as standalone scripts then that is all fine and well but if they are not - user does now know that they should not be and possibly what they are related to. A slight variation making it clear which scripts should be runnable directly and which should not would be to move module1.py module.py under some 'D:\Utility\script_details' folder and add an empty __init__.py file to that folder as well. Then module1.py module2.py can be imported as: 'import script_details.module1' and: 'import script_details.module2' respectively. Another addition is to prepare a packaged installer that installs your files in one of the aforementioned structures as any other application, e.g. under '/usr/bin', 'C:\Program Files' or whatever, but that's strictly an addition to what was described earlier. If the script and the modules you mention are self-contained and are not intended to be reused elsewhere, then I don't think you need anything more complex than that. If they are not then you have an option to place the implementation module in some shared Python environment folder, e.g. a specific Python environment's 'site-packages' folder. That would allow you to easily reuse those modules from other scripts located in other folders, but it would also introduce additional complications - with it you need to make sure the folder you placed them on has indeed been configured to be located on the used Python environment's Python path. Another variation is to package an installer that basically installs a stand-alone Python distribution together with your script, e.g. like something done by cx_Freeze or similar projects. Then your target machine does not need to have Python installed separately, but on the other hand, the installation is much larger and you risk getting multiple Python installations all over the same machine. :-) Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: How keep Python 3 moving forward - suds Python 3
Hi Roy. On 24.5.2014. 1:57, Roy Smith wrote: You need 19 projects to transition to Python 3. Of those 19 projects, 17 have no direct dependencies blocking their transition: [...snipped...] suds That's a big list. A few of those we could probably work around or replace with a different module without too much pain. But, between gevent, boto, fabric, and suds, any idea of migrating is a total non-starter for us. I imagine they're all working on ports, but I'll check back in a year and see how things stand. FYI, the suds-jurko fork works on Python 3. And since I'm not aware of any other actively maintained fork, should I find more free time in the future I might rename it to suds and try to convert it to a formal successor to suds. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Common issue but unable to find common solution (ez_setup.py on PC)
Hi. On 7.5.2014. 13:55, Jason Mellone wrote: By way of google I realize I am having what appears to be a pretty common issue install ez_setup.py on a PC (Windows XP, Python27). I receive an error message that looks like the following: Installing easy_install-2.7.exe.manifest script to C:\Python27\Scripts [...snipped a long traceback...] return self.loader.get_data(path) zipimport.ZipImportError: bad local file header in c:\python27\lib\site-packages \setuptools-3.5.1-py2.7.egg Something went wrong during the installation. See the error message above. You can run into this when attempting to upgrade an existing setuptools installation packaged as a zipped egg (due to some old zipimporter caches not getting cleaned up correctly). Is there a common solution for this issue? It has already been reported and a patch has been prepared. See the following: https://bitbucket.org/pypa/setuptools/issue/168 https://bitbucket.org/pypa/setuptools/pull-request/48 But the patch is still waiting on the maintainer to apply it. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Common issue but unable to find common solution (ez_setup.py on PC)
Hi Jason, On 7.5.2014. 15:52, Jason Mellone wrote: So, is the answer: 1 - Until the patch is applied there is no answer or 2 - I can go in and manually modify the code, and have the ez setup work? I see the patch has just been applied to the setuptools development repo, so the bug will be fixed in the next setuptools release, which seems imminent, judging from the latest setuptools commits. Related commits (see them at https://bitbucket.org/pypa/setuptools/commits/all) are on a branch containing the c95540cfeaec64251e78add403513a4f30700319 commit from 2014-04-15. But, if you need to fix your problem sooner, you can always do one of the following: 1. Not run ez_setup.py if setuptools is already installed and instead just run 'easy_install -U setuptools' to perform the upgrade. (I think that avoids the problem at hand, but I don't recall all the details so I could be mistaken.) 2. Manually remove setuptools before running ez_setup.py (either by removing the setuptools egg from your site-packages folder or perhaps by running 'pip uninstall setuptools'). 3. Checkout the development version of setuptools and install from there or prepare your own private setuptools package based on the current development tip. So you should be able to get your scenario to work, whatever it is. Hope this helps. Best regards, Jurko Gospodnetić P.S. I guess you're using google groups. I really hate the double spacing that leaves in your quotes and thus makes me scroll a lot and waste a lot of time trying to parse your message. Please try to use a different newsgroup client, e.g. Thunderbird. Many thanks. -- https://mail.python.org/mailman/listinfo/python-list
Why has __new__ been implemented as a static method?
Hi all. I was wandering why Python implements its __new__ method as a static and not a class method? __new__ always accepts a cls parameter, which lead me to believe it was a class method. Also, implementing __new__ as a class method seems natural when thinking about __new__ as 'a method you call on a class to create a new instance of that class'. The difference between the two implementations is admittedly not that significant. In most cases __new__ would still need to have its cls parameter explicitly specified since it is most often called on a class and not on an instance. Having it implemented as a class method would allow this: class X: def __new__(cls, x): return super().__new__(x) instead of having to do this, as we do now: class X: def __new__(cls, x): return super().__new__(cls, x) Thinking about this some more - I guess having it as a static method allows you to use super() and still create a new 'subclass' when asked to instantiate a base class. Perhaps some sort of a factory pattern implementation like so: class Base: def __new__(cls, x): actual_class = get_class_for(x) return super().__new__(actual_class, x) If __new__ were a class method, the same logic could not be so easily implemented as you would need to call __new__ on actual_class, and so each actual_class would need to implement its own __new__ skipping its direct parent's __new__ - yuck... what a mess... Could that be the actual use case causing Guido to model __new__ as a static method? Or was it something else? I'm not suggesting this be changed, of course. I'm just curious as to whether I'm not fully understanding something in this part of Python. I generally find Python highly intuitive and it's not often something about it takes me by surprise like this. :-) Thanks in advance. Best regards, Jurko Gospodnetić P.S. Normally, I'd chalk this issue up under 'bike-shedding', but it came up while teaching others about Python and so does not feel right leaving it as 'because that's the way it is'. :-) -- https://mail.python.org/mailman/listinfo/python-list
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
Jurko Gospodnetić added the comment: Thanks for the detailed response! :-( I should have tested more before reporting the issue. Sorry for the noise. :-( I saw the 'cls' argument and assumed it was a class method. Having to explicitly specify cls did not seem to be in contradiction with this since I assumed __new__ is generally invoked on the class directly. I still do not see why it had to be a static method and has not been implemented as a class method, but I guess I'll better ask that kind of a question on the python user's newsgroup. :-) Just in case it can help someone else, here's some sample code what convinced me __new__ was indeed implemented as a static method: class X: pass X.__new__() # TypeError: object.__new__(): not enough arguments X.__new__(X) # creates a new X instance x = X() x.__new__() # TypeError: object.__new__(): not enough arguments x.__new__(X) # creates a new X instance If __new__ had been a class method then calling 'x.__new__()' would have worked as well. Thanks again for the replies! Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
New submission from Jurko Gospodnetić: Doc/reference/datamodel.rst documentation states that the __new__ method is a static method (in Python, not in C!) when it is in fact a class method. A patch has been prepared in the https://bitbucket.org/jurko/cpython repository. branch: datamodel_doc_typo_fix commit: 81c5ba188805e42292c3eb9cffa56fbd5b7c6aee But it'll probably be easier for you to just change that single word directly. :-D Hope this helps. Best regards, Jurko Gospodnetić -- assignee: docs@python components: Documentation hgrepos: 245 messages: 217748 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: Python __new__ method doc typo (it's a class and not a static method) type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21415] Python __new__ method doc typo (it's a class and not a static method)
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file35130/81c5ba188805.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Jurko Gospodnetić added the comment: Thanks for looking into this Xavier. Could someone reopen this issue so it can gets looked at again? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Jurko Gospodnetić added the comment: Just ran into this problem and it's so uncomfortable researching dynamic structures at run-time using PDB without this. :-( As a workaround, you can use a trick similar to this one to 'import' your locals into the list comprehension body: [l['r'](x) for l in (locals(),) for x in l['some_local']] assuming 'r' 'some_local' are two local variables in your surrounding scope. Ugly, but at least it can be made/forced to work if needed... Best regards, Jurko Gospodnetić -- nosy: +Jurko.Gospodnetić versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21160] incorrect comments in nturl2path.py
New submission from Jurko Gospodnetić: nturl2path.py module contains comments implying that it converts local paths to URLs with ':' characters replaced with '|'. This has not been true since Python 2.6. Commit at: http://bitbucket.org/jurko/cpython/commits/8fe56380b09e238f104ba4a4d7a67df73182bc21 updates those comments - prepared against the CPython development repo. -- components: Library (Lib), Windows hgrepos: 230 messages: 215592 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: incorrect comments in nturl2path.py versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: segmentation fault, executable python file
Hi. On 4.4.2014. 11:17, Chris Angelico wrote: But from here you need someone more familiar with cxfreeze. All I can advise is to compare installed packages on each; maybe you have multiple versions of some library or something. From what little I know of it, it freezes as little as possible of Python's modules into the executable and stores the remaining Python code in a single zip file and loads it from there at run-time. That should limit your search area to just the frozen part and externally used libraries, and my instinct tells me gdb should be able to point you in the culprit's direction in no time. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
Jurko Gospodnetić added the comment: Or, if you do not want to get into the specifics of how to manually install setuptools/pip, it would probably be better to just refer the user to the 'ensurepip' module for the initial installation and tell him to upgrade whatever is needed from there without going in to any further details here. 'ensurepip' module itself is documented elsewhere (https://docs.python.org/3.4/library/ensurepip.html), and that documentation should perhaps be updated to include enough information (or references to external documentation containing that information) for the user to be able to perform the upgrades. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] When interrupted during startup, Python should not call abort() but exit()
Jurko Gospodnetić added the comment: Anyone have an eye on this item? What are the chances of the suggested patch being applied for Python 3.5? Or the issue resolved in some other way? Anything I can do to help? P.S. I'm not sure exactly how the regular development protocol goes around here so, just for the record, please know that no offense in intended with this ping. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] When interrupted during startup, Python should not call abort() but exit()
Jurko Gospodnetić added the comment: err... by Python 3.5 I meant Python 3.4.1 as well :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
New submission from Jurko Gospodnetić: In the Python documentation note: http://docs.python.org/3.4/library/venv.html#venv-def the paragraph: Common installation tools such as Distribute and pip work as expected with venvs - i.e. when a venv is active, they install Python packages into the venv without needing to be told to do so explicitly. Of course, you need to install them into the venv first: this could be done by running distribute_setup.py with the venv activated, followed by running easy_install pip. Alternatively, you could download the source tarballs and run python setup.py install after unpacking, with the venv activated. refers to the Distribute package and its specifics (how it should be installed) but that package has been deprecated in favor of the setuptools package. I suggest to change it to something like: Common installation tools such as setuptools and pip work as expected with venvs - i.e. when a venv is active, they install Python packages into the venv without needing to be told to do so explicitly. Of course, you need to install them into the venv first: this could be done by running setuptools project's ez_setup.py with the venv activated, followed by running easy_install pip. Alternatively, you could download the source tarballs and run python setup.py install after unpacking, with the venv activated. I'm attaching a patch based on the current tip in CPython's development repository. Hope this helps. Best regards, Jurko Gospodnetić -- assignee: docs@python components: Documentation files: fix_Distribute_reference_in_venv_docs.patch keywords: patch messages: 214554 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: Python docs reference the Distribute package which has been deprecated in favor of Setuptools versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34582/fix_Distribute_reference_in_venv_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Thanks Brett! :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20983] Python 3.4 'repair' Windows installation does not install pip setuptools packages
New submission from Jurko Gospodnetić: On Windows, when you repair your Python 3.4 installation, it will not reinstall pip setuptools. Here by 'repair' I mean a 'Windows Installer' based repair installation. Reproduced using: * Windows 7 SP1 x64. * Python 3.4.0 (32-bit). To reproduce do the following: * Install Python. * For example to the target installation folder: 'C:\Program Files (x32)\Python\Python340'. * This will automatically install pip setuptools Python packages. * Delete or rename your target installation folder. * Rerun your Python installation and choose to repair the current installation. * This will restore the original target installation folder and all the basic installation files under that folder, but it will not reinstall pip setuptols Python packages. -- components: Installation, Windows messages: 214113 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Python 3.4 'repair' Windows installation does not install pip setuptools packages versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
New submission from Jurko Gospodnetić: 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. 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 All this has been tested using one Windows 7 SP1 (x64) machine and using only CPython 3.4.0 installation on another. 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 - its 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 the 32-bit versions not displayed in the 'Add/Remove Programs' dialog. I compared MSI packaging related CPython source code (Tools/msi folder) in 2.6.2 2.6.3 releases but failed to 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. -- components: Installation, Windows messages: 214116 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment: Here is a possible 'workaround' for the 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment: This issue can confuse a regular user in the following scenario: 1. User uses 'for current user only' Python installations. 2. User expects to be able to see all installed software listed in the 'Add/Remove Programs' dialog and does not know that the listing presented there might be incomplete, how to use WMI to get an alternative listing or have any other indication that he should look for some external software providing this listing. 3. User has 32-bit 64-bit CPython 3.4.0rc3 installed on his machine. 4. User uninstalls the 64-bit CPython 3.4.0rc3 version and installs a new 64-bit CPython 3.4.0 release. No problems there. 5. User now wants to remove the old 32-bit CPython 3.4.0rc3 installation from his computer. 6. User checks the 'Add/Remove Programs' dialog and does not see the installation listed there. 7. User checks the 32-bit CPython 3.4 related Start menu folder for an uninstall link, but all the links there are related only to the 64-bit CPython 3.4.0 installation. 8. User checks the 32-bit CPython 3.4.0rc3 installation target folder (where its python.exe and other files are located) but finds no uninstaller there either. 9. Since there is no uninstaller to be found for this CPython installation, user assumes it is ok to just delete its folder and does so. 10. User attempts to install a new 32-bit CPython 3.4.0 installation and that breaks dues to not being able to uninstall a detected previous installation. If user thinks of it - he can now work around this by finding an old installation package for the previously installed 32-bit CPython version, running that, choosing to first repair the current installation and then run the installation again to remove the current installation. Or clean up the previous installation's Windows Installer related registry entries by hand (painful error prone). Or be unable to ever install a new version. :-) And, speaking from personal experience :-D, if he does apply the workaround he can 'feel dumb' about not locating and trying out the original installation before removing the original installed data and cuss fuss about nothing around him instructing him to look into that possibility. :-D If nothing else, this could be 'patched up' by having CPython's Windows installer that fails to uninstall a previous installation, suggest manually repairing the previous installation by running its installation package directly before attempting to rerun this installation. It could also reporting the original installation's install package location on disk, as read from the registry (Windows Installer makes a copy under some random generated name which user is unlikely to find by simple trial error). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows
Jurko Gospodnetić added the comment: Here are some more Windows Installer notes taken down when originally researching this issue on my end. Hopefully they can be of some use to anyone researching the issue further: - each installation gets a GUID key identifying it - the installation GUID key can be converted into a corresponding product key using the following algorithm: def guid_to_product_key(guid): guid = string in format {----} parts = guid.lstrip({).rstrip(}).split(-) key = [] # Reverse the first 3 parts. for p in range(3): key.extend(reversed(parts[p])) # Swap character pairs in remaining parts. for part in parts[3:]: for i in range(len(part) // 2): key.append(part[2 * i + 1]) key.append(part[2 * i]) return .join(key).upper() - some Windows Installer registry keys related to a specific installation: Example installation GUID key: {a37f2d73-72d1-364d-ba5d-cea430bcc040} Example product key: 37D2F73A1D27D463ABD5EC4A03CB0C04 Installed for example user with SID: S-1-5-21-2100645858-3408510361-1554613642-1000 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{a37f2d73-72d1-364d-ba5d-cea430bcc040} HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\37D2F73A1D27D463ABD5EC4A03CB0C04 HKEY_CURRENT_USER\Software\Microsoft\Installer\Features\37D2F73A1D27D463ABD5EC4A03CB0C04 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000 \Products\37D2F73A1D27D463ABD5EC4A03CB0C04 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040} Product key listed under several different subkeys under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000\Components Product key listed under: HKEY_CURRENT_USER\Software\Microsoft\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What does gc.get_objects() return?
Hi. On 17.3.2014. 18:18, Antoine Pitrou wrote: All in all, though, gc.get_objects() is an expensive function call (it will walk the entire graph of objects tracked by the GC, which can be very large in non-trivial applications), so it's really only useful for debugging (and, I'd add, for low-level debugging). In most situations, gc.get_objects() is certainly the wrong tool to use. I agree, and for the record, we were using it for debugging when I started this thread - trying to track down a memory leak. :-) gc.get_objects() turned out to be of great help with in resolving the issue - in the end we tracked it down to a typical reference counting problem in a Python extension DLL. *doh* Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread._stop() behavior changed in Python 3.4
Hi. On 17.3.2014. 19:03, Ian Kelly wrote: So yes, despite the lack of true concurrency, a thread can continue to run after its _stop has been called. Actually 'true' or 'false' concurrency does not matter here. CPython supports multiple threads and implements them using underlying native OS threads. The fact that it has an internal mutex (GIL) preventing it from executing/interpreting Python code at the same time in multiple threads (most of the time) does not come into play.. When one thread exits its GIL protected section (e.g. finishes processing one bytecode instruction and is about to go on to processing the next one), another thread may pick up the GIL and do some of its work, e.g. print out some output. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Step 2: Jurko can you see if the uploaded patch fixes things for you? Yup. That's exactly how we were working around the issue before reporting it here. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What does gc.get_objects() return?
Hi. On 12.3.2014. 23:40, Ian Kelly wrote: Or is it? a = 1,2,3 gc.is_tracked(a) True gc.collect() 0 gc.is_tracked(a) False Ufff.. nice one :-D Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: What does gc.get_objects() return?
Hi. On 13.3.2014. 3:54, Terry Reedy wrote: On 3/12/2014 3:34 PM, Jurko Gospodnetić wrote: I was wondering if someone could explain gc.get_objects() in a bit more detail to me. Does it return a list of 'all objects known to Python'? Only some of them? Which does it return? Which it does not? [...detailed explanation snipped...] Thank you very much for taking the time to explain it all in detail. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
What does gc.get_objects() return?
Hi all. I was wondering if someone could explain gc.get_objects() in a bit more detail to me. Does it return a list of 'all objects known to Python'? Only some of them? Which does it return? Which it does not? For example (done using CPython 3.4 interactive interpreter) here it does not contain an object I know exists: a = object() a in gc.get_objects() False but here it does: class Foo: pass ... a = Foo() a in gc.get_objects() True It also does not seem to contain string objects. At first I thought that perhaps interned strings were not placed under GC control, so I tested this: a = asdkjfhk23498237$(*$*($ksjdhfkjsd b = asdkjfhk23498237$(*$*($ksjdhfkjsd a is b False a in gc.get_objects() False b in gc.get_objects() False Which shows that non-interned scripts such as these are not getting listed in gc.get_objects() either. :-s Many thanks. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: What does gc.get_objects() return?
Hi. On 12.3.2014. 21:02, MRAB wrote: I was wondering if someone could explain gc.get_objects() in a bit more detail to me. Does it return a list of 'all objects known to Python'? Only some of them? Which does it return? Which it does not? gc.is_tracked(...) might be relevant to your question. Thanks! The documentation for gc.is_tracked() straightened me out. :-) So gc.collect() returns a list of all the objects GC is in charge of, and which instances are and are not tracked by the GC is, I guess, an interpreter implementation detail. For CPython 3.4 I guess strings and other atomic types such as ints are not, as well as raw object() instances. Custom class instances on the other hand seem to be under GC control. Thanks again. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: As mentioned by Anthony Tuininga at: https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9077661 The value of __file__ in the problematic importlib/__init__.py module with Python 3.3. is 'frozen' while with Python 3.4 it is not defined. And this 'frozen' string seems to be something coming from Python and not cx_Freeze (I see it in 'Python/import.c' in both Python 3.3.5 3.4). Hope this helps. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Ask per Nick's instructions I tweaked cx_Freeze to import a dummy package as frozen. The dummy package has the following structure: gugu/ __init__.py and its __init__.py file contains only the 8 bytes '__file__' (does not include the quotes). Then running a frozen executable based on a script with the following content: import gugu results in a NameError due to the name '__file__' not being recognized. You can see more detailed information at: https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9084842 Hope this helps. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: That 'what's new' item seems relevant, except that the issue here is related to the __file__ attribute instead of __path__. Could it be that the same fix actually updated how the __file__ attribute is defined as well? The bug seems to be caused by importlib\__init__.py expecting its __file__ attribute to be defined, thus not allowing it to be frozen at all. :-( Based on my rather slim understanding of how module 'freezing' works I guess executables wanting to freeze the importlib\__init__.py module can work around the problem by adding code to the front of that module to hardcode its __file__ attribute value, before freezing it. However I'd be happier with Python not requiring that the __file__attribute be defined internally at all. Imposing a workaround such as this on anyone wanting to freeze the importlib package seems rather nasty. Best regards, Jurko Gospodnetić -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: This could possibly also have been caused by a resolution to issue 18088 (http://bugs.python.org/issue18088). See commit e873f2e67353 (http://hg.python.org/cpython/rev/e873f2e67353). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: +1 for the clean solution :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20784] 'collections.abc' is no longer defined when collections is imported
Jurko Gospodnetić added the comment: Item possibly related to this. When packaging a simple HelloWorld-like application like this: print(Hello world) import configparser using cx_Freeze and Python 3.4, you get the following error on packaged application startup: Traceback (most recent call last): File C:\Program Files\Python\Python34rc3\lib\site-packages\cx_freeze-4.3.2-py3.4-win-amd64.egg\cx_Freeze\initscripts\Console3.py, line 27, in module exec(code, m.__dict__) File hello_world.py, line 4, in module File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\configparser.py, line 121, in module from collections.abc import MutableMapping File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2201, in _find_and_load_unlocked raise ImportError(_ERR_MSG.format(name), name=name) ImportError: No module named 'collections.abc' As I see it, the config parser module is attempting to import 'collections.abc'. The same does not occur with Python 3.3.5 or 3.3.3. Not sure if this is due to something cx_Freeze does so it failed to collect some module in the created installation package, or if it's something to look into in Python itself. Just looked similar to this so I bring it up as additional info for anyone looking deeper into this issue. Hope this helps. Best regards, Jurko Gospodnetić -- nosy: +Jurko.Gospodnetić ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20784] 'collections.abc' is no longer defined when collections is imported
Jurko Gospodnetić added the comment: I cannot reproduce your issue Meaning you do not have the environment set up for this or that you tried it and it worked for you? If it 'worked for you', I can send you more detailed environment information when get back to my office in an hour or so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: Here's a recipe I can use to reproduce the problem on my PC. Environment: * Windows 7 SP1 x64 * Python 3.4.0rc3 * cx_Freeze checkout from its current HEAD * repository: https://bitbucket.org/anthony_tuininga/cx_freeze * HEAD commit: 52b63b3296843cd612cfbe047a9f6529df4c0444 * I'm attaching a compressed checkout. * TortoiseHg 2.11 - just in case you're having problems using the cx_Freeze Hg sandbox I attached to this comment and want to know if it is Hg version related. * Microsoft Visual Studio 2010 C/C++ compiler. * Exact cl.exe version information: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 -- 1. prepare to build cx_Freeze -- To build the given cx_Freeze project using Python 3.4 the following tweak must first be done in Python's Lib\distutils\msvc9compiler.py module: Around line 649 replace the line: if mfinfo is not None: with: if mfinfo is not None and target_desc != executable: This is an unrelated issue that still needs to be researched. -- 2. build install cx_Freeze -- Standard Python package installation - go to your cx_Freeze sandbox project folder and run py34 setup.py install. This should result in cx_Freeze-4.3.2-py3.4-win-amd64.egg folder being added under your Python 3.4 installation's site-packages folder. -- 3. prepare a test project -- Create a new folder and add the following files to it: hello_world.py: print(Hello world) import asyncio import sys print(sys.version_info) setup.py: from cx_Freeze import setup, Executable setup(name=HelloWorld, version=0.1, description=HelloWorld, executables=[Executable(hello_world.py, base=Console)]) Note that only the 'import asyncio' line is necessary to reproduce the issue. The rest is just useful output for the user/tester. -- 4. prepare a 'frozen' test project executable -- Go to the test project folder and run the following command: py34 setup.py build_exe This should create a new executable under: build\exe.win-amd64-3.4\hello_world.exe -- 5. run the prepared executable -- You should get output looking something like: Hello world Traceback (most recent call last): File C:\Program Files\Python\Python34rc3\lib\site-packages\cx_freeze-4.3.2-py3.4-win-amd64.egg\cx_Freeze\initscripts\Cons exec(code, m.__dict__) File hello_world.py, line 8, in module import asyncio File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\__init__.py, line 23, in module from .locks import * File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\locks.py, line 9, in module from . import tasks File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2261, in _handle_fromlist _call_with_frames_removed(import_, from_name) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 321, in _call_with_frames_removed return f(*args, **kwds) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load return _find_and_load_unlocked(name, import_) File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2203, in _find_and_load_unlocked module = _SpecMethods(spec)._load_unlocked() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1191, in _load_unlocked return self._load_backward_compatible() File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 1161, in _load_backward_compatible spec.loader.load_module(spec.name) File C:\Program Files\Python\Python34rc3\lib\asyncio\tasks.py, line 12, in module import inspect File C:\Program Files\Python\Python34rc3\lib\importlib\_bootstrap.py, line 2214, in _find_and_load
Re: Windows installation problem with 3.3.5
Hi. On 10.3.2014. 4:16, Mark Lawrence wrote: It looks as if the upgrade from 3.3.4 to 3.3.5 has stolen my copies of py.exe and pyw.exe from c:\windows. Before I raise an issue on the bug tracker could someone please confirm this, as it wouldn't be the first time I've managed to screw something up. What exactly do you mean by 'stolen'? Removed those executables? Or reused the original ones instead of new ones you expected to be installed over them? Or the opposite - overwrote them with new ones and you expected the old ones to stay around? I just tested the same thing and the original executables that were there got overwritten with newer ones, as I expected. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows installation problem with 3.3.5
Hi. On 10.3.2014. 4:16, Mark Lawrence wrote: It looks as if the upgrade from 3.3.4 to 3.3.5 has stolen my copies of py.exe and pyw.exe from c:\windows. Before I raise an issue on the bug tracker could someone please confirm this, as it wouldn't be the first time I've managed to screw something up. I just now ran into something that might explain this. You could have run your new installation as 'for the current user only'. That would not have placed the new py.exe executable in C:\Windows. Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
New submission from Jurko Gospodnetić: 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. As I understand it, whichever installation you use, you should be able to run a specific Python interpreter using the py.exe runner, as in: 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', although when running 'py.exe -3.4-32' the runner will make an extra check and reject running the Python executable if the 64-bit version was installed last. So: 1. If you install the 64-bit version first and then the 32-bit version, both 'py.exe -3.4' 'py.exe -3.4-32' run the 32-bit executable. 2. If you install the 32-bit version first and then the 64-bit version, 'py.exe -3.4' runs the 64-bit version, and 'py.exe -3.4-32' exits with an error. -- components: Installation, Windows messages: 213045 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Windows 'for current user' installation - 32/64-bit registrations overwrite each other versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: A possible solution would be to update installers and runners to use HKEY_CURRENT_USER\Software\Wow6432Node registry entries for 32-bit 'for current user only' installations on a 64-bit Windows OS. To preserve backward compatibility, runners could fall back to reading the 64-bit HKEY_CURRENT_USER\Software registry entries if their 32-bit counterparts can not be found directly. This way: - installations on 32-bit Windows are unaffected - new installations work with new runners correctly - old installations work with new runners as before - old installations work with old runners as before - new 64-bit installations work with old runners as before - new 32-bit installations do not work with old runners -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
New submission from Jurko Gospodnetić: 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. I believe this is a bug since the code expects the module loaded from importlib/__init__.py to always have a __file__ identifier set. 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__. A possible fix would be to skip setting the _bootstrap.__file__ attribute if the current module does not have a __file__ attribute set. I hope this can be resolved before the 3.4 final release or it will not be possible to use cxFreeze with Python 3.4 without additional workarounds in cxFreeze. Best regards, Jurko Gospodnetić -- components: Interpreter Core, Library (Lib) messages: 213047 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: David: Nope, the issue does not exist with 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: I'm against removing local user installation support because that is the only way Python can be installed without write access to shared system locations like the Windows system folder or the HKEY_LOCAL_MACHINE registry hive. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: And as for simultaneous 64/32-bit Python installations on a single 64-bit machine - as Paul said, whichever way Microsoft implemented its automatic registry key redirection, it is up to Python to decide how its installer should behave. So the question is - should it be possible to run 32-bit 64-bit Python installations on the same machine using the standard py.exe wrapper when those installations are done for the current user only? I know I found that useful in a scenario (done using installations 'for all users' though) where I had some scripts using 64-bit Python and needed to run several scripts automating a 32-bit Python extension module. I believe the problem was in the pstools module that at the time was not available as a 64-bit build (don't know if that situation has been resolved since). Personally, I just noticed the undocumented inconsistency and decided to report it. I don't really care all that much about whether it is resolved cleanly, as in my development setup I have other problems preventing me from using the py.exe wrapper all together - I need multiple parallel patch releases in the same system and the best way I found to achieve that is to: - do a 'local user installation' - version A, - rename the target folder for version A - do a 'local user installation' - version B, - ... and have my own version specific startup scripts like py243.cmd, py244.cmd, py276_x86.cmd, py276.cmd, py340.cmd, ... I really don't like it that different Python X.Y patch releases overwrite each other's installation registrations or uninstall each other automatically. :-( Or that you can not specify more detailed Python interpreter version information like 2.4.3 to the py.exe wrapper. :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20883] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Jurko Gospodnetić added the comment: Nor was Martin suggesting it as far as I can tell I'm sorry if I came across too strongly. I can assure you I meant no disrespect nor have I at any point felt affronted by anything anyone else said in this thread/issue. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Jurko Gospodnetić added the comment: I'll try to set up and post a reproducible use case tomorrow. Then you can decide. It could turn out that the use case we ran into has an easy workaround. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typo
New submission from Jurko Gospodnetić: Python unittest.mock documentation has typo: indvidually instead of individually Can be seen in the documentation source file at: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock-examples.rst#l429 -- assignee: docs@python components: Documentation messages: 212079 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: unittest.mock documentation typo versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typos
Jurko Gospodnetić added the comment: Another related documentation 'bug' - the following wording: Mock doesn’t create these but instead of raises an AttributeError. should be changed to something like: Mock doesn’t create these on demand and raises an AttributeError instead. Can be seen in the documentation source file at: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock.rst#l960 -- title: unittest.mock documentation typo - unittest.mock documentation typos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20759] unittest.mock documentation typos
Jurko Gospodnetić added the comment: And another one: 'setttings' should be spelled 'settings' in: http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock.rst#l1512 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [RELEASED] Python 3.4.0 release candidate 1
Hi. On 11.2.2014. 17:21, Terry Reedy wrote: The failed 64-bit installs somehow messed up the 32-bit install. With 3.4 completely removed, including the residual directories, the 32-bit install works but the 64-bit install still gives me the same message. I had a similar problem with the beta 3 release where x64 failed to install on my computer. Not sure if the underlying issue is the same as yours but my issue was resolved after uninstalling the Visual Studio C++ runtime, rebooting and doing a clean install. I wanted to report the issue then, but since I could not reproduce it, I had nothing exact to say other than 'did not work for me, now it does, don't know if it was me or you'. :-) Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: how to reduce bugs due to incorrect indentation
Hi, On 7.2.2014. 2:20, msus...@gmail.com wrote: Based on the responses I arrived to the conclusion that there is no better solution than trying to be careful and have good testing suites. It would be possible to disable the Tab key completely ...[snipped]... Maybe a coloring of the background based on tab position ...[snipped]... I also considered ...[snipped]... YMMV, but for me, just reading through this fun thread took more time then ever debugging issues caused by bad Python code indentation. :-D So, my suggestion would be to just ignore the problem and deal with any resulting issues as they occur. Clean coding development practices, some of which have been mentioned earlier in this thread and are useful for many other reasons as well, will additionally reduce the chance of such errors causing any non-trivial issues. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
[issue14228] It is impossible to catch sigint on startup in python code
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: -- components: +email -Interpreter Core nosy: +Jurko.Gospodnetić, barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
New submission from Jurko Gospodnetić: If you press Ctrl-C during Python startup on Windows you may get interpreter crashes with different Python tracebacks displayed on the standard system error output stream. Reproduced using: - Windows 7 SP1 x64 - Python 3.3.3 (64-bit) as downloaded from 'http://www.python.org/download/releases/3.3.3' (but seen with different earlier Python versions as well). - either a non-trivial Python script, one containing only a '#! python3' shabang line, or a completely empty one - default site.py To reproduce simply run the Python interpreter with a prepared Python script as input and press Ctrl-C immediately afterwards. Possible results: * Script finishes before your Ctrl-C kicks in. * You get a clean KeyboardInterrupt traceback and the script exits. * You get a KeyboardInterrupt traceback and the interpreter process crashes. I'm attaching more detailed information on specific crash instances. For some more information background see the devel mailing list thread started at: 'https://mail.python.org/pipermail/python-dev/2013-December/130750.html'. -- components: Interpreter Core, Windows files: crash-info-10.txt messages: 206212 nosy: Jurko.Gospodnetić priority: normal severity: normal status: open title: Ctrl-C causes startup crashes on Windows type: crash versions: Python 3.3 Added file: http://bugs.python.org/file33137/crash-info-10.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file33138/crash-info-1-9 - Python tracebacks only.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Jurko Gospodnetić added the comment: I can reproduce this most easily if I run a command like: clean.cmd run.py where clean.cmd is any short batch script and run.py is a file containing only the '#! python3' shabang line. The batch script in front is not necessary, and I've originally been reproducing the issue without it, but the problem seems much easier to reproduce with it, most likely because is slightly delays the Python startup and thus makes it easier for the Ctrl-C signal to kick in early enough during Python startup. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Jurko Gospodnetić added the comment: I reproduced the issue about 10 more times to see if I'd get some more useful C tracebacks in Visual Studio, but they seems to be the pretty much the same every time (as seen in the attached http://bugs.python.org/file33137/crash-info-10.txt file). I'm attaching another one, just for the record. The only difference I see between crash #10 and this one is that second thread has a bit different name, but that is most likely just some internal Windows API worker thread and not something explicitly started by Python or relevant to this report. -- Added file: http://bugs.python.org/file33139/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Removed file: http://bugs.python.org/file33139/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19983] Ctrl-C causes startup crashes on Windows
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com: Added file: http://bugs.python.org/file33140/crash-info-11.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
Jurko Gospodnetić added the comment: This issue is related to issue #19983 on Windows. Also, I do not think the suggested -z option implementation should be accepted 'as is'. 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Differences between obj.attribute and getattr(obj, attribute)
Hi. On 11.12.2013. 9:23, Johannes Schneider wrote: can somebody explain me the difference between accessing attributes via obj.attribute and getattr(obj, attribute)? Is there a special reason or advantage when using getattr? You can not use obj.attribute if you have the word 'attribute' as a string, e.g. if you read it from a configuration file. Also, you can not test whether an object has an attribute when using the object.attribute access method without raising/catching an exception and then it can be hard to make sure no other code caused the exception. But I suppose in most real-life cases both of the suggested access methods are equivalent, since most of the time you really do not have names of your attributes as strings and are free to simply assume the attribute exists. One example problem I had recently where I think you have to use getattr(): list the names of all global references in the __builtins__ module and, a the type of object each of those references points to. [Ran into this one by accident as a part of demonstrating to a new Python student what names Python recognizes in some module, and what names require additional imports.] Hope this helps. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 14:42, Jurko Gospodnetić wrote: So far all tests seem to indicate that things work out fine if we install to some dummy target folder, copy the target folder to some version specific location uninstall. That leaves us with a working Python folder sans the start menu and registry items, both of which we do not need for this. Everything I've played around with so far seems to use the correct Python data depending on the interpreter executable invoked, whether or not there is a regular Windows installation somewhere on the same machine. We can use the script suggested by Ned Batchelder to temporarily change the 'current installation' if needed for some external installer package to correctly recognize where to install its content. I'm still playing around with this, and will let you know how it goes. Just wanted to let you know that the usage I described above seems to work in all the cases I tried out. I added some batch scripts for running a specific Python interpreter as a convenience and everything works 'naturally' in our development environment. Packages can be easily installed to a specific targeted environment using for example: py243 -m easy_install pip py332 -m pip install pytest [not mentioning tweaks needed for specific ancient Python versions] Thank you all for all the suggestions. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi all. I was wondering what is the best way to install multiple Python installations on a single Windows machine. Regular Windows installer works great as long as all your installations have a separate major.minor version identifier. However, if you want to have let's say 2.4.3 2.4.4 installed at the same time it does not seem to work. I have not been able to find any prepackaged Python installation or really any solution to this. Most of the advice seems to boil down to 'do not use such versions together, use only the latest'. We would like to run automated tests on one of our projects (packaged as a Python library) with different Python versions, and since our code contains workarounds for several problems with specific Python patch versions, we'd really like to be able to run the tests with those specific versions and with as little fuss as possible. Looking at what the Python installer does, the only problematic part for working around this manually seems to be the registry entries under 'Software\Python\PythonCore\M.m' where 'M.n' is the major.minor version identifier. If Python interpreter expects to always find its entries there, then I guess there is no way to do what we need without building customized Python executables. Is there a way to force a specific Python interpreter to not read in this information, read it from an .ini file or something similar? Many thanks. Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 14:04, Chris Angelico wrote: Is it possible to set up virtualization to help you out? Create a virtual machine in something like VirtualBox, then clone it for every Python patch you want to support (you could have one VM that handles all the .0 releases and another that handles all the .1 releases, or you could have a separate VM for every Python you want to test). ... Thank you for the suggestion. Yup, we could do that, but at first glance it really smells like an overkill. Not to mention the potential licensing issues with Windows and an unlimited number of Windows installations. :-) So far all tests seem to indicate that things work out fine if we install to some dummy target folder, copy the target folder to some version specific location uninstall. That leaves us with a working Python folder sans the start menu and registry items, both of which we do not need for this. Everything I've played around with so far seems to use the correct Python data depending on the interpreter executable invoked, whether or not there is a regular Windows installation somewhere on the same machine. We can use the script suggested by Ned Batchelder to temporarily change the 'current installation' if needed for some external installer package to correctly recognize where to install its content. I'm still playing around with this, and will let you know how it goes. Thank you again for replying! Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 13:46, Ned Batchelder wrote: IIRC, Python itself doesn't read those registry entries, except when installing pre-compiled .msi or .exe kits. Once you have Python installed, you can move the directory someplace else, then install another version of Python. If you need to use many different Pythons of the same version, this script helps manage the registry: http://nedbatchelder.com/blog/201007/installing_python_packages_from_windows_installers_into.html Thank you for the information! As I mentioned in another reply, so far I think we can use this script to temporarily change the 'current installation' if needed for some external installer package to correctly recognize where to install its content. bike-sheddingIf we do use it, I'll most likely modify it to first make a backup copy of the original registry key and use that later on to restore the original registry state instead of reconstructing its content to what the script assumes it should be./bike-shedding Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 14:20, Albert-Jan Roskam wrote: Check out the following packages: virtualenv, virtualenvwrapper, tox virtualenv + wrapper make it very easy to switch from one python version to another. Stricly speaking you don't need virtualenvwrapper, but it makes working with virtualenv a whole lot easier.Tox also uses virtualenv. You can configure it to sdist your package under different python versions. Also, you can make it run nosetests for each python version and/or implementation (pypy and jython are supported) I'll look into using virtualenv and possibly tox once I get into issues with mismatched installed Python package versions, but for now I'm dealing with installing different Python interpreter versions and, unless I'm overlooking something here, virtualenv does not help with that. :-( Thanks for the suggestion though, I'm definitely going to read up on those packages soon. :-) Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 15:15, Albert-Jan Roskam wrote: Are you sure? http://stackoverflow.com/questions/1534210/use-different-python-version-with-virtualenv Yup, I'm pretty sure by now (based on reading the docs, not trying it out though). Virtualenv allows you to set up different environments, each of them having a separate Python folder structure and each possibly connected to a separate Python interpreter executable. However, it does not solve the problem of getting those separate Python interpreter executables installed in the first place, which is the problem I was attacking. :-) Still playing around with my multiple installations setup here. Will let you know how it goes... So far, one important thing I noticed is that you need to run all your installations 'for the current user only', or otherwise it moves at least one DLL file (python24.dll) into a Windows system folder and then the next installation deletes it from there, and overwrites it with its own. :-( But I can live with that... :-) Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python x.y.A and x.y.B installations on a single Windows machine
Hi. On 25.11.2013. 17:38, Terry Reedy wrote: So far all tests seem to indicate that things work out fine if we install to some dummy target folder, copy the target folder to some version specific location uninstall. If the dummy folder had 3.3.0, you should not need to uninstall to install 3.3.1 on top of it. But it is easy and probably safest. Without the uninstall step you get stuck with invalid registry and start menu items refering to an invalid path until you install another matching major.minor.X version. Just a reminder: you can run one file or set of files with multiple Pythons by putting 'project.pth' containing the same 'path-to-project' in the Lib/site-packages of each Python directory. I do this to test one file with 2.7 and 3.3 (and just added 3.4) without copying the file. Thanks for the tip. That might come in useful. At the moment I just run the pytest framework using different python interpreters, without having to install the package at all (possibly first running 'setup.py build' to get the sources converted to Python 3 format). Best regards, Jurko Gospodnetić -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: psutil 1.0.0 released
Hi. I'm pleased to announce the 1.0.0 release of psutil: http://code.google.com/p/psutil/ Great! :-) Btw. any change you can put up a prebuilt installer for a 64-bit built with Python 3.3? You have one for Python 3.2 (http://code.google.com/p/psutil/downloads/list), but the version for Python 3.3 is not there. Best regards, Jurko Gospodnetić -- http://mail.python.org/mailman/listinfo/python-list
Re: Top-posting c. (was Re: [ANNC] pybotwar-0.8)
Hi. As a lurker, I agree completely with Chris's sentiments. +1 Best regards, Jurko Gospodnetić -- http://mail.python.org/mailman/listinfo/python-list
Re: lambda in list comprehension acting funny
Hi. funcs = [ lambda x: x**i for i in range( 5 ) ] print funcs[0]( 2 ) This gives me 16 When I was excepting 1 Does anyone know why? Just the way Python lambda expressions bind their variable references. Inner 'i' references the outer scope's 'i' variable and not its value 'at the time the lambda got defined'. And more importantly, what's the simplest way to achieve the latter? :) Try giving the lambda a default parameter (they get calculated and have their value stored at the time the lambda is defined) like this: funcs = [ lambda x, i=i: x**i for i in range( 5 ) ] Hope this helps. Best regards, Jurko Gospodnetić -- http://mail.python.org/mailman/listinfo/python-list
os.path.realpath() and os.path.abspath()
Hi all. os.path.realpath() documentation states that it returns a 'canonical' path. Does that infer that it returns an absolute path? I have not found seen any implementation that does not return an absolute path, but can this be counted on? Or should we use os.path.abspath(os.path.realpath(x)) when we want to convert x to its full/canonical name? Best regards, Jurko Gospodnetić -- http://mail.python.org/mailman/listinfo/python-list
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Jurko Gospodnetić jurko.gospodne...@gmail.com added the comment: Also this class, because it defines __del__ too simply, will display a user-unfriendly error message when cleaning up a TemporaryDirectory object whose constructor raised an exception when attempting to create its temporary folder. For example try to create a TemporaryDirectory with prefix= on Windows. That should fail as folders there can not contain '' characters and later on in the program you should get an error message something like this one: Exception AttributeError: 'TemporaryDirectory' object has no attribute '_closed' in bound method TemporaryDirectory.cleanup of tempfile.TemporaryDirectory object at 0x00CE1E10 ignored Hope this helps. [Sorry, did not know whether to add this as a separate issue as it seemed kind of related to this one.] -- nosy: +Jurko.Gospodnetić ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Jurko Gospodnetić jurko.gospodne...@gmail.com added the comment: Clicked send too soon on the previous comment. :-( The simplest way I see you can fix the __del__ issue is to patch TemporaryDirectory.__init__() as follows: def __init__(self, suffix=, prefix=template, dir=None): self._closed = True self.name = mkdtemp(suffix, prefix, dir) self._closed = False This is based on the tempfile.py from the 3.2 beta 1 release on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com