[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-01-02 - 2015-01-09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4726 (+20)
closed 30244 (+37)
total 34970 (+57)
Open issues with patches: 2214
Issues opened (44)
==
#14099: ZipFile.open() should not reopen the underlying file
http://bugs.python.org/issue14099 reopened by serhiy.storchaka
#14853: test_file.py depends on sys.stdin being unseekable
http://bugs.python.org/issue14853 reopened by haypo
#16192: ctypes - documentation example
http://bugs.python.org/issue16192 reopened by berker.peksag
#19776: Provide expanduser() on Path objects
http://bugs.python.org/issue19776 reopened by haypo
#22919: Update PCBuild for VS 2015
http://bugs.python.org/issue22919 reopened by haypo
#23152: fstat64 required on Windows
http://bugs.python.org/issue23152 opened by steve.dower
#23155: unittest: object has no attribute '_removed_tests'
http://bugs.python.org/issue23155 opened by wiz
#23156: Update tix install information in tkinter tix chapter of doc
http://bugs.python.org/issue23156 opened by terry.reedy
#23159: argparse: Provide equivalent of optparse.OptionParser.{option_
http://bugs.python.org/issue23159 opened by emcd
#23160: Respect the environment variable SVNROOT in external-common.ba
http://bugs.python.org/issue23160 opened by anselm.kruis
#23162: collections.abc sequences don't check identity before equality
http://bugs.python.org/issue23162 opened by Devin Jeanpierre
#23163: pdb docs need to contain a statement on threads/multithreaded
http://bugs.python.org/issue23163 opened by krichter
#23164: "pydoc filter" documentation restrictive
http://bugs.python.org/issue23164 opened by lebigot
#23166: urllib2 ignores opener configuration under certain circumstanc
http://bugs.python.org/issue23166 opened by crazyjurich
#23169: Reflect that PreReq and BuildPreReq are deprecated in the late
http://bugs.python.org/issue23169 opened by radeksimko
#23171: csv.writer.writerow() does not accept generator (must be coerc
http://bugs.python.org/issue23171 opened by jdufresne
#23173: asyncio: kill the subprocess if the creation failed
http://bugs.python.org/issue23173 opened by haypo
#23174: shelve.open fails with error "anydbm.error: db type could not
http://bugs.python.org/issue23174 opened by krichter
#23176: socket.recvfrom(0) waits for data
http://bugs.python.org/issue23176 opened by Sworddragon
#23177: test_ssl: failures on OpenBSD with LibreSSL
http://bugs.python.org/issue23177 opened by haypo
#23180: Rename IDLE's "Windows" menu item to "Window"
http://bugs.python.org/issue23180 opened by Al.Sweigart
#23181: Unicode "code point" should be two words in documentation
http://bugs.python.org/issue23181 opened by Al.Sweigart
#23182: Update grammar tests to use new style for annotated function d
http://bugs.python.org/issue23182 opened by IanLee1521
#23183: timeit CLI best of 3: undocumented output format
http://bugs.python.org/issue23183 opened by hachat
#23184: Unused imports, variables, file in IDLE
http://bugs.python.org/issue23184 opened by Al.Sweigart
#23185: add inf and nan to math module
http://bugs.python.org/issue23185 opened by ethan.furman
#23187: Segmentation fault, possibly asyncio related
http://bugs.python.org/issue23187 opened by karamanolev
#23188: Exception chaining should trigger for non-normalised exception
http://bugs.python.org/issue23188 opened by ncoghlan
#23189: Set docstrings to empty string when optimizing with -OO.
http://bugs.python.org/issue23189 opened by jvs
#23191: fnmatch regex cache use is not threadsafe
http://bugs.python.org/issue23191 opened by mschmitzer
#23192: Generator return value ignored in lambda function
http://bugs.python.org/issue23192 opened by Rosuav
#23193: Please support "numeric_owner" in tarfile
http://bugs.python.org/issue23193 opened by mvo
#23195: Sorting with locale (strxfrm) does not work properly with Pyth
http://bugs.python.org/issue23195 opened by pnugues
#23197: asyncio: check if a future is cancelled before calling set_res
http://bugs.python.org/issue23197 opened by haypo
#23198: asyncio: refactor StreamReader
http://bugs.python.org/issue23198 opened by haypo
#23199: libpython27.a in amd64 release is 32-bit
http://bugs.python.org/issue23199 opened by zwelch
#23200: Clarify max_length and flush() for zlib decompression
http://bugs.python.org/issue23200 opened by vadmium
#23201: Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0
http://bugs.python.org/issue23201 opened by Devin Jeanpierre
#23202: pyvenv does not fail like documented when a venv already exist
http://bugs.python.org/issue23202 opened by The Compiler
#23203: Aliasing import of sub-{module,package} from the package raise
http://bugs.python.org/issue23203 opened by franck
#23205: Unit test needed for IDLE's GrepDialog.py's fin
Re: [Python-Dev] New Windows installer for Python 3.5
> Nothing is merged in yet and everything can still change, so I'm keen to hear whatever > feedback people have. I've tried to make improvements fairly for first-time users > through to sysadmins, but if I've missed something big I'd like to hear about it before > we get too close to alpha 1. It would be great if the new installer supported silent, portable installs. What I have in mind is a silent installation that drops all the necessary files for a working python into a folder, but does not put ANY file anywhere else and does not register anything anywhere on the system. So no PATH modification, no registering of this install as one of the available python interpreters, no uninstall entry or anything like that. By "all the necessary files" I mean that it drops things like the MSVC runtime dlls etc into that folder into which I'm installing python, but again doesn't try to install things like that system or even user wide. I'll give you my very specific use-case, but I think this might be useful for others as well: we are trying to build an installer for some other product X that internally requires a python instance to work. This python instance should NOT be visible to anything other than product X, i.e. no user should ever start it directly or anything like that, it really is an implementation detail of product X. If we had an official python installer that supported silent, portable installs, I could just call that python installer inside the setup program for X, and it would drop a fully working python installation into a sub-directory of the install directory of product X. And we would be happy :) The old MSI installer sort of had something like that with the MSI administrative install option. But it never really worked because the administrative install didn't drop the MSVC runtime dlls anywhere, as far as I could tell. At some point I hacked around that by modifying the MSI file in my setup program to also drop the MSVC runtime dlls, but that was VERY hacky... Thanks, David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 1/9/2015 12:34 PM, David Anthoff wrote: Nothing is merged in yet and everything can still change, so I'm keen to hear whatever feedback people have. I've tried to make improvements fairly for first-time users through to sysadmins, but if I've missed something big I'd like to hear about it before we get too close to alpha 1. It would be great if the new installer supported silent, portable installs. What I have in mind is a silent installation that drops all the necessary files for a working python into a folder, but does not put ANY file anywhere else and does not register anything anywhere on the system. So no PATH modification, no registering of this install as one of the available python interpreters, no uninstall entry or anything like that. By "all the necessary files" I mean that it drops things like the MSVC runtime dlls etc into that folder into which I'm installing python, but again doesn't try to install things like that system or even user wide. I'll give you my very specific use-case, but I think this might be useful for others as well: we are trying to build an installer for some other product X that internally requires a python instance to work. This python instance should NOT be visible to anything other than product X, i.e. no user should ever start it directly or anything like that, it really is an implementation detail of product X. If we had an official python installer that supported silent, portable installs, I could just call that python installer inside the setup program for X, and it would drop a fully working python installation into a sub-directory of the install directory of product X. And we would be happy :) The old MSI installer sort of had something like that with the MSI administrative install option. But it never really worked because the administrative install didn't drop the MSVC runtime dlls anywhere, as far as I could tell. At some point I hacked around that by modifying the MSI file in my setup program to also drop the MSVC runtime dlls, but that was VERY hacky... Thanks, David Sounds like a nice feature. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
David Anthoff wrote: > It would be great if the new installer supported silent, portable installs. > What I have in mind is a silent installation that drops all the necessary > files > for a working python into a folder, but does not put ANY file anywhere else > and > does not register anything anywhere on the system. So no PATH modification, no > registering of this install as one of the available python interpreters, no > uninstall entry or anything like that. By "all the necessary files" I mean > that > it drops things like the MSVC runtime dlls etc into that folder into which I'm > installing python, but again doesn't try to install things like that system or > even user wide. > > I'll give you my very specific use-case, but I think this might be useful for > others as well: we are trying to build an installer for some other product X > that internally requires a python instance to work. This python instance > should > NOT be visible to anything other than product X, i.e. no user should ever > start > it directly or anything like that, it really is an implementation detail of > product X. If we had an official python installer that supported silent, > portable installs, I could just call that python installer inside the setup > program for X, and it would drop a fully working python installation into a > sub-directory of the install directory of product X. And we would be happy :) I'll look into this, but it probably isn't going to work as part of the installer. I have previously looked into being able to install arbitrary side-by-side copies of Python, but that's near impossible as well. Windows Installer doesn't really let you just copy files - it isn't part of its intended functionality. It isn't too difficult to build custom MSIs with certain parts of Python (such as the DLLs and the standard library, but no docs, headers or EXEs) in a way that won't conflict with other installs, but you're still using an MSI here which is not necessarily ideal. The easiest way is still going to be to install a copy of Python without administrative privileges, which *currently* will drop all the files you want into the main install path (wherever you customise that to be), and then copy them directly into your installer, but that may change depending on the redistribution requirements of the CRT. There are still limitations within Python itself that would be nice to fix, such as looking at the registry too soon when it could resolve directories relative to its own location, but these are independent from the installer. If you don't need python.exe, then it should be fine as long as you put pythonXY.dll alongside the executable loading it (otherwise a system version may take priority). As you can see, this is a fairly deep hole with lots of caveats :) We could release a ZIP file containing all the Python files. The only reason I hesitate on this is that it could cause significant confusion for someone who doesn't really understand the implications, while people like yourself who have thought about this are also capable of finding workarounds and don't really need the ZIP file apart from convenience. Making some of the fixes to make python.exe more portable would relieve my concerns here. > The old MSI installer sort of had something like that with the MSI > administrative install option. But it never really worked because the > administrative install didn't drop the MSVC runtime dlls anywhere, as far as I > could tell. At some point I hacked around that by modifying the MSI file in my > setup program to also drop the MSVC runtime dlls, but that was VERY hacky... I'm a little surprised that worked at all for what you were trying to do. You'd be better off installing it once and then copying the files yourself. But overall, this is the sort of thing I do want to enable. I firmly believe that Python from python.org is for *developers*, and those who just want to run a Python application should be able to get a complete package. This is very different from the *nix approach, but it makes far more sense to Windows users. A good example is TortoiseHg, which bundles everything so that users never even know they have Python 2.7 or Mercurial installed on their machine. Making it easier for people to bundle Python into their own applications is a good thing, as far as I'm concerned. Cheers, Steve > Thanks, > David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
> I'll look into this, but it probably isn't going to work as part of the installer. I > have previously looked into being able to install arbitrary side-by-side copies > of Python, but that's near impossible as well. Windows Installer doesn't really > let you just copy files - it isn't part of its intended functionality. It isn't too > difficult to build custom MSIs with certain parts of Python (such as the DLLs > and the standard library, but no docs, headers or EXEs) in a way that won't > conflict with other installs, but you're still using an MSI here which is not > necessarily ideal. Are administrative MSI installs an option, though? They don't register anything but just drop files, right? But see my comments below about a zip drop, which would be a much, much nicer option in my opinion. > We could release a ZIP file containing all the Python files. That would be absolutely FANTASTIC and would solve all problems around this topic. In theory we could handle this ourselves on our end, but this is for a small open source project and we are really hesitant to take on another software packaging job. Doing this right just for our product would be a fair amount of work, we would have to do this with every new Python release, we might mix things up etc., and really we are more interested in our piece of software than packaging Python ;) I think it would be a much nicer model if there was a zip to download from python.org. There is another issue that keeps us from hosting our own files: we would have to figure out licensing issues, both related to python and to the msvcr*.dll and msvcp*.dll. I would feel much more comfortable if we didn't distribute python or other binaries, but just downloaded stuff from python.org as part of the setup process. > The only reason I > hesitate on this is that it could cause significant confusion for someone who > doesn't really understand the implications, while people like yourself who > have thought about this are also capable of finding workarounds and don't > really need the ZIP file apart from convenience. I was not clear in my previous email. I have NOT found a way to work around this. I have tried various hacks, but none really works. I got pretty far, but none really worked in all cases in a robust way. So I would certainly welcome a downloadable zip file a great deal. Is there maybe a compromise for now to have such a zip on the server, but not advertise it widely, and maybe put an "experimental"/"beta" moniker into the filename? I assume you would include the MS VC runtime files msvcr100.dll and msvcp100.dll in such a zip file? Is there any chance this might even be done (as an experimental version) for Python 3.4? > Making some of the fixes to > make python.exe more portable would relieve my concerns here. I see that. For our cases things seem to work, but I agree, it would be good if python.exe would try hard to work in a xcopy mode. > > The old MSI installer sort of had something like that with the MSI > > administrative install option. But it never really worked because the > > administrative install didn't drop the MSVC runtime dlls anywhere, as > > far as I could tell. At some point I hacked around that by modifying > > the MSI file in my setup program to also drop the MSVC runtime dlls, but > that was VERY hacky... > > I'm a little surprised that worked at all for what you were trying to do. You'd > be better off installing it once and then copying the files yourself. I got it to drop the msvcr100.dll, but haven't managed to get the msvcp100.dll out via an administrative install. The whole approach is a mess, I would MUCH prefer a zip file. > But overall, this is the sort of thing I do want to enable. I firmly believe that > Python from python.org is for *developers*, and those who just want to run > a Python application should be able to get a complete package. This is very > different from the *nix approach, but it makes far more sense to Windows > users. A good example is TortoiseHg, which bundles everything so that users > never even know they have Python 2.7 or Mercurial installed on their > machine. Making it easier for people to bundle Python into their own > applications is a good thing, as far as I'm concerned. Yes, those are good examples. Right now doing this in the way these guys do is too much work for our small project... Anything that makes this easier would be appreciated. Thanks! And the new installer looks great in general. Best, David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 01/09/2015 05:01 PM, David Anthoff wrote: > On 01/09/2015 04:09 PM, Steve Dower wrote: >> The only reason I hesitate on this is that it could cause significant >> confusion for someone who doesn't really understand the implications, >> while people like yourself who have thought about this are also capable >> of finding workarounds and don't really need the ZIP file apart from >> convenience. > > I was not clear in my previous email. I have NOT found a way to work around > this. > Is there any chance this might even be done (as an experimental version) for > Python 3.4? Couldn't this zip file be advertised in the embedded section of python.org? Or with a "for embedding in Windows apps" tag? (or whatever the proper verbiage is) -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
