[issue21427] installer not working
New submission from Uwe:
Installer fails to install 3.4 on win7 32 bit
Error: cannot register 64 bit component {BE22BD81-ECE5-45BD-83B8-84BA45846A2D}
on 32 bit system. KeyPath: C:\Windows\py.exe
--
messages: 217878
nosy: ellipso
priority: normal
severity: normal
status: open
title: installer not working
type: crash
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue21427>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: Of course, only official sources the file is named python-3.4.0.msi and 23,924KB the name is similar to that of earlier versions which worked fine So I am not sure, whether it is 32 or 64bit maybe it would be a good idea to use two different names such as x86 and x64? -- ___ Python tracker <http://bugs.python.org/issue21427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: I guess this is merely describing the problem and not the solution? (by the way I had no difficulties with the 64bit version on a 64bit win7 system) Would it be possible to produce the binairies myself using the mingw compiler? The readme says visual c++ is required. -- ___ Python tracker <http://bugs.python.org/issue21427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: not sure what you mean: the installer for 64 bit is working fine the installer for 32 bit is not working - this is true also for the new version 3.4.1 for those who may try: compiling is tricky with VC2010 pro -- ___ Python tracker <http://bugs.python.org/issue21427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: the installer went 2/3 through the process and was installing already something in the default dir c:\Python34 Then after a small pause the error message was shown and the installer removed all the files leaving an empty ..\lib in the default dir The behavior is quite reproducible with *.msi for python 3.4.0 and 3.4.1 Its independent on whether the prior installation dir is removed or not It is not an issue of the antivirus software (I am running win7 prof sp1 with the latest updates) It is not clear from the process but I am convinced this happens when the installer tries to register python in the registry It never happened with any of the prior python 3.0 to 3.3.5 For the own compiled version I can run python.exe of the 3.4.1 sources but haven tested whether its executing anything fine. So it does not seem to be a problem of python3.4.x on 32bit -- ___ Python tracker <http://bugs.python.org/issue21427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21427] installer not working
Uwe added the comment: problem is solved observation - installer problem only occurred on win7 32 bit with prior python installation (my working system) - When repeating the installer problem I noticed that a window was opened very shortly with python.exe running. An error message from this call resulted in the exit process of the installer - the window popped up only for about 1second. A was reading (taking a video) that it was complaining about an error in numpy when calling imp.py in /python33/lib (the old installation, something wrong with libtool, bootstrap) - I removed step by step all installed libraries, but the error still appeared - I removed the prior python 3.3.5 installation completely, now the installer worked - when opening the window with python, it was downloading something like setuptools (not absolutely sure about the name) - a test with nose 1.3.3, numpy 1.8.1, scipy 0.14.0 (all from Gohlkes web site) went ok. - unfortunately, the error message with the registry was not reflecting the problem Hence, the solution is to remove the prior installation of python. That was not necessary in older versions and not necessary for win7 64 bit: strange. -- ___ Python tracker <http://bugs.python.org/issue21427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3409] ElementPath.Path.findall problem with unicode input
New submission from Uwe Hoffmann <[EMAIL PROTECTED]>:
if you call Element.findall(u"...") some silent errors can
occure because of the isinstance(,type("")) check. I'm
not sure if it is even allowed to call findall with a unicode parameter.
The attached diff solves *my* problem.
--
components: Library (Lib), Unicode
files: ElementPath.diff
keywords: patch
messages: 69986
nosy: qual
severity: normal
status: open
title: ElementPath.Path.findall problem with unicode input
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10940/ElementPath.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3409>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2758] arg 2 of PyErr_SetFromErrnoWithFilename should be const
New submission from Uwe Kleine-König <[EMAIL PROTECTED]>: Compiling an extension I get the warning: warning: passing argument 2 of ‘PyErr_SetFromErrnoWithFilename’ discards qualifiers from pointer target type I passed a const char *, which should be OK from looking at the implementation of PyErr_SetFromErrnoWithFilename. Attached is a patch. I don't expect this to break any API or ABI, but you might know better. -- components: Interpreter Core files: make_PyErr_SetFromErrnoWithFilename_filename_const messages: 66220 nosy: ukleinek severity: normal status: open title: arg 2 of PyErr_SetFromErrnoWithFilename should be const type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10194/make_PyErr_SetFromErrnoWithFilename_filename_const __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2758> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40139] mimetypes module racy
New submission from Uwe Kleine-König :
Hello,
in a project using aiohttp with Python 3.5 as provided by Debian Stretch
(3.5.3) I sometimes see a wrong mimetype assigned to .css files. When trying to
create a minimal reproduction recipe a colleage and I came up with:
import asyncio
import sys
from mimetypes import guess_type
async def f():
t = guess_type('foo.css')
return t == ('text/css', None)
async def main():
done, pending = await asyncio.wait([
asyncio.ensure_future(f()),
asyncio.ensure_future(f()),
])
return all(d.result() for d in done)
if __name__ == '__main__':
loop = asyncio.get_event_loop()
if not loop.run_until_complete(main()):
print("FAIL")
exit(1)
We didn't see this exact code failing but something very similar and only once.
Up to now we only tested on Python 3.5 as this is what is used in production.
By code inspection I found a race: In the module's guess_type function there is:
if _db is None:
init()
return ...
It can happen here that init() is entered twice when the first context entered
init() but gets preempted before setting _db.
However I failed to see how this can result in guess_type returning None (which
is what we occasionally see in our production code).
Also the code in mimetypes.py is rather convoluted with two different guards
for not calling init (_db is None + not inited), init() updating various global
variables and instantiating a MimeTypes object that depends on these variables,
...
mimetypes.py changed in master a few times, as I didn't spot the actual problem
yet and the issue hardly reproduces I cannot tell if the problem still exists
in newer versions of Python.
There are also some bug reports that seem related, I found reading
https://bugs.python.org/issue38656 and https://bugs.python.org/issue4963
interesting.
Best regards
Uwe
--
components: Library (Lib)
messages: 365500
nosy: ukl
priority: normal
severity: normal
status: open
title: mimetypes module racy
type: behavior
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue40139>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40139] mimetypes module racy
Uwe Kleine-König added the comment: I agree that 3.5 is ancient and the focus should be to fix the newer versions of Python. But given that the problem seems to be hard to reproduce -- I have the reproducer script from the original report running under the tracer since over a week now without a hit -- it seems to be beneficial to me to understand the issue on 3.5 to then check if 3.8+ is also affected. Also note that Lib/mimetypes.py didn't change between 3.5.3 and 3.5.9. The difference between 3.5.x and 3.6.x in this file doesn't affect the code flow, in fact the first commit that has a change to actually change the behavior I saw between 3.5.0 and current master is bpo-4963 that only went into 3.9.x. I added dhess and steve.dower who were involved in bpo-4963 to the nosy list, maybe one of them remembers or is able to quickly spot the problem. -- nosy: +dhess, steve.dower ___ Python tracker <https://bugs.python.org/issue40139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30665] pass big values for arg to fcntl.ioctl
New submission from Uwe Kleine-König: When passing a big integer value to fcntl.ioctl this might result in OverflowError: signed integer is greater than maximum . Traditionally ioctl(3) takes a pointer as third argument. The fcntl module however uses an int (format specifier 'i') which is too small to hold a pointer on 64 bit architectures. The fix is to use 'k' (and an unsigned long) instead of 'i' (and an int). An unsigned long is suitable to hold a pointer value on AFAIK all platforms that matter today. (And it works on all platforms where int is already good enough, so the suggested change doesn't do any harm.) A patch is attached. -- files: unsigned-long-arg-for-ioctl.patch keywords: patch messages: 296008 nosy: ukl priority: normal severity: normal status: open title: pass big values for arg to fcntl.ioctl type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file46951/unsigned-long-arg-for-ioctl.patch ___ Python tracker <http://bugs.python.org/issue30665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30665] pass big values for arg to fcntl.ioctl
Uwe Kleine-König added the comment: So the only option to fix this is to determine the type of arg from the request parameter? I failed to find the implementation of ioctl for linux in glibc, the best I found is one that only seems to be used on powerpc[1] which seems to assume that the third argument is a pointer. The Linux kernel prototype takes an unsigned long[2] and encodes the size of the data pointed to in the request using _IOC[3]. On hurd there are different macros to determine the type. I'm not fluent in *BSD and Solaris (and other operating systems), so I cannot add specifics for them. I cannot even say which OS that runs Python can run in 64 bit BE mode. [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/powerpc/ioctl.c;h=e2e3d3357f9f5ee9ffe5e9f0588ebae9976c0dfd;hb=HEAD [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ioctl.c?h=v4.12-rc5#n691 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/ioctl.h -- ___ Python tracker <http://bugs.python.org/issue30665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32582] chr raises OverflowError
New submission from Uwe Kleine-König : Hello, the description for chr (from https://docs.python.org/3/library/functions.html#chr) reads as: Return the string representing a character whose Unicode code point is the integer i. [...] The valid range for the argument is from 0 through 1,114,111 (0x10 in base 16). ValueError will be raised if i is outside that range. If however a value > 0x7fff (or < -0x8000) is provided, the function raises an Overflow error: $ python3 -c 'print(chr(0x8000))' Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.) -- components: Interpreter Core files: chr-OverflowError.patch keywords: patch messages: 310178 nosy: ukl priority: normal severity: normal status: open title: chr raises OverflowError versions: Python 3.6 Added file: https://bugs.python.org/file47390/chr-OverflowError.patch ___ Python tracker <https://bugs.python.org/issue32582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21771] name of 2nd parameter to itertools.groupby()
New submission from Uwe Kleine-König: The name of the 2nd parameter to itertools.groupby() is documented inconsitently. Sometimes it's "key", sometimes "keyfunc". The code actually uses "key", so I adapted all occurences I found to "key". >>> from itertools import groupby >>> groupby.__doc__ 'groupby(iterable[, keyfunc]) -> create an iterator which returns\n(key, sub-iterator) grouped by each value of key(value).\n' >>> groupby([], keyfunc=lambda x: x) Traceback (most recent call last): File "", line 1, in TypeError: 'keyfunc' is an invalid keyword argument for this function >>> groupby([], key=lambda x: x) -- assignee: docs@python components: Documentation files: groupby-keyfunc.patch keywords: patch messages: 220639 nosy: docs@python, ukl priority: normal severity: normal status: open title: name of 2nd parameter to itertools.groupby() type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35645/groupby-keyfunc.patch ___ Python tracker <http://bugs.python.org/issue21771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12970] os.walk() consider some symlinks as dirs instead of non-dirs
Uwe Kleine-König added the comment: I like the function as it is documented, i.e. "filenames is a list of the names of the non-directory files in dirpath.". This includes all symlinks (in the followlinks=False cast at least). I'd say not including symlinks to directories but symlinks to files is a magnitude more surprising than treating a symlink to a directory as a file. And if you consider this as a short comming of the documentation this isn't (IMHO) a subtlety. The (my?) intuition says: all entries of a root (apart from . and .. as documented) are included in either dirnames or filenames. Yes, changing behaviour here might break some code, but this applies to all changes. For some usecases it might be right to just skip over symlinks-to-dirs, but if it's not you have to opendir + read all root entries again in the loop to find all symlinks which effectively means reimplementing os.walk. -- nosy: +ukl ___ Python tracker <http://bugs.python.org/issue12970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
