[issue24873] Add full cleanup checkbox to uninstaller
Terry J. Reedy added the comment: There are two problem scenarios, which might meed different solutions. 1. Cannot install x.y(.z) for the first time, or if it does install, it does not run. Zap all may be appropriate. 2, Cannot upgrade installed x.y.z. This seems to be due to corruption of z.y.z. The current solution seem to be to re-download x.y.z installer (if deleted), which means remembering .z. Then fixing (maybe). Or zapping x.y.z and maybe fiddling with the registry? I went through this once and it is mess, and not something for non-expert users. Would it be sensible for installer to check for TCL_LIBRARY and if found, display value and mention that it might interfere with install? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg248657 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Raymond Hettinger added the comment:
When a cycle object has fully consumed its input iterable, __reduce__ method
uses the returns a space-inefficient result when space-efficient alternative is
available.
# Current way of restoring a cycle object with excess info in setstate:
c = cycle(iter('de'))
c.__setstate__((['a', 'b', 'c', 'd', 'e'], 1))
''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'
# The same result can be achieved with less information:
c = cycle(iter('de'))
c.__setstate__((['a', 'b', 'c'], 0))
''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24874
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24873] Add full cleanup checkbox to uninstaller
Steve Dower added the comment: #2 should be fixed with the new installer (not necessarily the 3.5.0a/b/rc versions, but final 3.5.0-3.5.1 and upwards should be fine). The problems with 3.4's installer seem to be largely due to the pip bootstrap being a critical part of uninstall. I've deliberately made the 3.5 uninstaller not fail if pip won't uninstall cleanly, which should allow upgrades to occur even if the previous install is corrupt. Another workaround here is to go through Programs and Features, though sometimes it is possible for the entry to not appear. That should be fixed with 3.5 (at least through the supported ways of installing it), but as I'm not 100% sure what causes the issue with earlier versions I can't guarantee it yet. There's actually a sizable list of environment variables that could cause problems (PYTHONPATH, PYTHONHOME, etc.), worse on Windows because it's so much more common to have multiple versions installed and to set system-level environment variables. Maybe adding a Compatibility Check page to the installer could be handy? It could check these, maybe look for build tools or runtime dependencies and provide links or help for fixing/getting them. Another great idea, but not sure when I'll personally have the time to implement it :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
R. David Murray added the comment: Here's the pull request: https://bitbucket.org/larry/cpython350/pull-requests/4/21167-fix-definition-of-nan-when-icc-used/diff -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module
Brett Cannon added the comment: Here is a pure Python patch that skips any frames that mentions 'importlib' and '_bootstrap' in the filename (it also skips _warnings.warn for easy testing since I didn't implement the C part). The only side-effect is that negative stack levels won't be the same because of the change in line numbers, but in that instance I'm not going to worry about it. It also causes test_venv and test_warnings to fail but I have not looked into why. And still need a call by Larry as to whether this will go into 3.5.0. -- components: +Library (Lib) keywords: +patch stage: - patch review Added file: http://bugs.python.org/file40187/issue24305.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Raymond Hettinger added the comment: Added an updated patch that passes all tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Steve Dower added the comment: I've made a build of rc1 with the installer fix that's currently being considered for 3.5.0: https://pythonbuilds.blob.core.windows.net/temp/python-24847-1.exe (This is a test-marked build that *should not* affect another 3.5 install, but if it does please tell me so I can fix it. After removing it, a Repair on 3.5.0rc1 should fix any issues.) Currently working on a test build of the fix based on the attached patches, which is the correct fix for this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] Optimize coding with surrogateescape and surrogatepass error handlers
STINNER Victor added the comment: Oh. I restored the old title because i replied by email with an old email. -- title: surrogateescape is too slow - Optimize coding with surrogateescape and surrogatepass error handlers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Steve Dower added the comment: A second test build with the attached patches applied directly to 3.5.0rc1. (You'll need to remove the first test build before installing this). https://pythonbuilds.blob.core.windows.net/temp/python-24847-2.exe Any confirmation that these work would be appreciated. I don't think we should rewrite the tcl/tk build for 3.5.0 completely at this stage, so this one is my preferred fix for 3.5.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Raymond Hettinger added the comment: Also, looking at the source for itertools.cycle(), it looks like the overall speed could be boosted considerably by looping over the saved list directly rather than allocating a new list iterator every time the cycle loops around. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
New submission from Nicolas Demarchi: When Envbuilder creates a new virtualenv with system_site_packages=True, in the process of installing pip itself it actually doesn't install it inside the virtualenv because it is already there in the system. However when you do it manually using virtualenv it does install pip inside the virtualenv as you would expect to. ``` (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 pwd /home/gilgamezh/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ll total 16 drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 bin drwxr-xr-x 2 gilgamezh users 4096 Aug 16 00:05 include drwxr-xr-x 3 gilgamezh users 4096 Aug 16 00:05 lib lrwxrwxrwx 1 gilgamezh users3 Aug 16 00:05 lib64 - lib -rw-r--r-- 1 gilgamezh users 68 Aug 16 00:05 pyvenv.cfg (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ll bin total 12 -rw-r--r-- 1 gilgamezh users 2251 Aug 16 00:05 activate -rw-r--r-- 1 gilgamezh users 1367 Aug 16 00:05 activate.csh -rw-r--r-- 1 gilgamezh users 2503 Aug 16 00:05 activate.fish lrwxrwxrwx 1 gilgamezh users7 Aug 16 00:05 python - python3 lrwxrwxrwx 1 gilgamezh users 16 Aug 16 00:05 python3 - /usr/bin/python3 (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 bin/python -Im ensurepip --upgrade --default-pip -v Ignoring indexes: https://pypi.python.org/simple URLs to search for versions for setuptools in /usr/lib/python3.4/site-packages: Skipping link /tmp/tmpe8rbjkcq (from -f); not a file Skipping link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl; wrong project name (not setuptools) Found link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl, version: 12.0.5 Local files found: /tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl Installed version (18.1) is most up-to-date (past versions: 12.0.5) Requirement already up-to-date: setuptools in /usr/lib/python3.4/site-packages URLs to search for versions for pip in /usr/lib/python3.4/site-packages: Found link file:///tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl, version: 6.0.8 Skipping link file:///tmp/tmpe8rbjkcq/setuptools-12.0.5-py2.py3-none-any.whl; wrong project name (not pip) Local files found: /tmp/tmpe8rbjkcq/pip-6.0.8-py2.py3-none-any.whl Installed version (7.1.0) is most up-to-date (past versions: 6.0.8) Requirement already up-to-date: pip in /usr/lib/python3.4/site-packages Cleaning up... (22d667c6-e383-47be-9785-ec044008b654) ~/.local/share/fades/22d667c6-e383-47be-9785-ec044008b654 ``` bin/python -Im ensurepip --upgrade --default-pip -v is from /usr/lib/python3.4/venv/__init__.py line 255 -- components: Library (Lib) messages: 248673 nosy: gilgamezh priority: normal severity: normal status: open title: pyvenv doesn´t install PIP inside a new venv with --system-site-package type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24875 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file40188/cycle9.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Raymond Hettinger added the comment: Attaching a partial patch: * More than doubles the speed of cycle() * Cuts size of __reduce__ result by about a third (on average) * Still needs work on __setstate__ for a correct restore. -- keywords: +patch Added file: http://bugs.python.org/file40186/cycle5_brokensetstate.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
New submission from Raymond Hettinger:
When a cycle object has fully consumed its input iterable, __reduce__ method
uses the returns a space-inefficient result when space-efficient alternative is
available.
# Current way of restoring a cycle object with excess info in setstate:
c = cycle(iter('de'))
c.__setstate__((['a', 'b', 'c', 'd', 'e'], 1))
''.join(next(c) for i in range(20)) # next 20 values
'deabcdeabcdeabcdeabc'
# The same result can be achieved in less info in setstate:
c = cycle(iter('de'))
c.__setstate__((['a', 'b', 'c'], 0))
''.join(next(c) for i in range(20)) # next 20 values
--
assignee: rhettinger
components: Extension Modules
messages: 248657
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve pickling efficiency of itertools.cycle
type: resource usage
versions: Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24874
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24859] ctypes.Structure bit order is reversed - counts from right
eryksun added the comment: No, ctypes.Structure should use native endianness. So on a little-endian it's the same as ctypes.LittleEndianStructure, and on a big-endian system it's the same as ctypes.BigEndianStructure. ARM processors can work in either mode. IIRC, the Raspberry Pi is built as a little-endian system. Check sys.byteorder to be sure. -- stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Steve Dower added the comment: Yeah, should have mentioned the smartscreen warning. The official builds are Authenticode signed, which prevents that warning appearing. I promise the installers are safe :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment: What if you run: bt ? On August 15, 2015 7:32:37 PM CDT, Cyd Haselton rep...@bugs.python.org wrote: Cyd Haselton added the comment: I thought porting gdb would be the difficult part of getting debug info. I was so wrong. Here is what I have so far, after lengthy consultation of the gdb manual. Bear with me...it's basically a copy paste of gdb session output: (gdb) run Starting program: /bld/pyt/cpython-android/python setpgrp failed in child: No such process warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGILL, Illegal instruction. 0xb6a63cc8 in ?? () (gdb) f #0 0xb6a63cc8 in ?? () (gdb) info f Stack level 0, frame at 0xbefff618: pc = 0xb6a63cc8; saved pc = 0xb6a5feb0 called by frame at 0xbefff618 Arglist at 0xbefff618, args: Locals at 0xbefff618, Previous frame's sp is 0xbefff618 (gdb) info args No symbol table info available. (gdb) info local No symbol table info available. (gdb) info source Current source file is ./Modules/python.c Compilation directory is /bld/pyt/cpython-android Located in /bld/pyt/cpython-android/Modules/python.c Contains 80 lines. Source language is c. Compiled with DWARF 2 debugging format. Does not include preprocessor macro info. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] surrogateescape is too slow
STINNER Victor added the comment: Serhiy: maybe we can start with ascii? -- title: Optimize coding with surrogateescape and surrogatepass error handlers - surrogateescape is too slow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files
Tal Einat added the comment: I'll commit #3 (unicodeobject.c) when I first get the chance, which should be in a few days. I'll be happy to improve the rest as needed if someone can find the time to review them! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20180 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file40185/time_cycle.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: I thought porting gdb would be the difficult part of getting debug info. I was so wrong. Here is what I have so far, after lengthy consultation of the gdb manual. Bear with me...it's basically a copy paste of gdb session output: (gdb) run Starting program: /bld/pyt/cpython-android/python setpgrp failed in child: No such process warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGILL, Illegal instruction. 0xb6a63cc8 in ?? () (gdb) f #0 0xb6a63cc8 in ?? () (gdb) info f Stack level 0, frame at 0xbefff618: pc = 0xb6a63cc8; saved pc = 0xb6a5feb0 called by frame at 0xbefff618 Arglist at 0xbefff618, args: Locals at 0xbefff618, Previous frame's sp is 0xbefff618 (gdb) info args No symbol table info available. (gdb) info local No symbol table info available. (gdb) info source Current source file is ./Modules/python.c Compilation directory is /bld/pyt/cpython-android Located in /bld/pyt/cpython-android/Modules/python.c Contains 80 lines. Source language is c. Compiled with DWARF 2 debugging format. Does not include preprocessor macro info. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24874] Improve pickling efficiency of itertools.cycle
Serhiy Storchaka added the comment: Current cycle implementation is simple and clever, but can be optimized. The part about iterating LGTM (but looks the firstpass field can be eliminated at all). But __reduce__ doesn't look so optimal. It makes a copy of a list and makes iterating an unpickled cycle object slow. It would be more optimal if create new list with rotated content or even rotate original list inplace. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24874 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Matthew Barnett added the comment: On running the installer, Windows reports: Windows SmartScreen prevented an unrecognised application from starting. Running this application might put your PC at risk. Application: Python-24847-2.exe Publisher: Unknown Publisher When installed, Tkinter appears to work without a problem. This is on Windows 10 Home (64-bit) without VS 2015. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module
Nathaniel Smith added the comment: Yeah, yours is probably better in fact, I was just trying to make the semantics as obvious as explicit as possible for a comment :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
jack added the comment: Thanks a lot for the tip. This revealed that Python 3.4.3 was looking for tcl from Python 2.2 on my machine. That version had been on my machine more than 10 years ago, but was no longer there. It had left behind a whole bunch of registry crumbs, which I removed. I then uninstalled all the versions on my machine and reinstalled 3.4.3. That did the trick. The question is, why would installing 3.4.3 or other versions be contaminated by stuff from another version, especially an ancient one? Jack On 8/14/2015 8:49 PM, Terry J. Reedy wrote: Terry J. Reedy added the comment: For 3.4.3, run 'python -m idlelib' in the command window and you should see some error message. But first run 'python' and at the prompt, 'import tkinter' to see if tkinter is working properly. -- nosy: +terry.reedy ___ Python trackerrep...@bugs.python.org http://bugs.python.org/issue24868 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24868 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Steve Dower added the comment: Rereading the discussion, there seems to be agreement that this is an enhancement. It does not apply for Python 3.5 (which requires a compiler without the bug that causes this), and Python 3.4 is no longer eligible for enhancements. I'm closing this as out of date. The patches will be here, so anyone who is rebuilding Python 3.4 or earlier for their own use with VS 2012 is welcome to apply the patch themselves. -- resolution: fixed - out of date status: open - closed type: - enhancement versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24859] ctypes.Structure bit order is reversed - counts from right
eryksun added the comment:
It seems you want a BigEndianStructure:
from ctypes import *
class SAEJ1939MsgId(BigEndianStructure):
_fields_ = (('reserved', c_uint8, 3),
('priority', c_uint8, 3),
('extended_data_page', c_uint8, 1),
('data_page', c_uint8, 1),
('pdu_format', c_uint8),
('pdu_specific', c_uint8),
('source_address', c_uint8))
def __init__(self, *args, pgn=0, **kwds):
super().__init__(*args, **kwds)
if pgn 0:
self.pgn = pgn
def __int__(self):
return int.from_bytes(self, 'big')
@property
def pgn(self):
pgn is an 18-bit number consisting of EDP, DP, PF, and PS
return (int(self) 8) 0x3
@pgn.setter
def pgn(self, value):
value |= self.priority 18
view = (c_char * 3).from_buffer(self)
view[:] = value.to_bytes(3, 'big')
@classmethod
def from_bytes(cls, msg_id):
return cls.from_buffer_copy(msg_id)
@classmethod
def from_integer(cls, msg_id):
msg_id_bytes = msg_id.to_bytes(sizeof(cls), 'big')
return cls.from_buffer_copy(msg_id_bytes)
Example:
a = SAEJ1939MsgId(priority=7, source_address=3)
hex(int(a))
'0x1c03'
b = SAEJ1939MsgId(pgn=0xf004, priority=7, source_address=3)
hex(int(b))
'0x1cf00403'
b.priority
7
b.pdu_format
240
b.pdu_specific
4
b.source_address
3
c = SAEJ1939MsgId.from_integer(int(b))
hex(int(c))
'0x1cf00403'
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24859
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] surrogateescape is too slow
Serhiy Storchaka added the comment: Few months ago I wrote a patch that drastically speeds up encoding and decoding with surrogateescape and surrogatepass error handlers. However it causes 25% regression in decoding some UTF-8 data (U+0100-U+07FF if I remember correct) with strict error handler, so it needs some work. I hope that it is possible to rewrite UTF-8 decoder so that avoid a regression. The patch was postponed until 3.5 is released. In any case the patch is large and complex enough to be new feature that can appear only in 3.6. -- assignee: - serhiy.storchaka nosy: +serhiy.storchaka versions: -Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] surrogateescape is too slow
R. David Murray added the comment: Why are bytes being escaped in a binary blob? The reason to use surrogateescape is when you have data that is mostly text, should be processed as text, but can have occasional binary data. That wouldn't seem to apply to a database binary blob. But that aside, if you want to submit a patch to speed up surrogateescape without changing its functionality, I'm sure it would be considered. It would certainly be useful for the email library, which currently does do the stupid thing of encoding binary message attachments using surrogateescape (and I'm guessing the reason pymysql does it is something similar to why email does it: the code would need to be significantly reorganized to do things right). -- nosy: +r.david.murray versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection
Changes by R. David Murray rdmur...@bitdance.com: -- stage: commit review - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21718 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection
R. David Murray added the comment: Attached is the patch ported to python2.7. However, the test doesn't fail for me before I apply (compile) the fix. -- Added file: http://bugs.python.org/file40184/f67fa9c898a4713850e16934046f0fe2cba8c44c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21718 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24862] subprocess.Popen behaves incorrect when moved in process tree
Andre Merzky added the comment: Looking a little further, it seems indeed to be a problem with ignoring SIGCHLD. The behavior has been introduced with [1] at [2] AFAICS, which is a response to issue15756 [3]. IMHO, that issue should have been resolved with raising an exception instead of assuming that the child exited successfully (neither is true in this case, not the 'exited' nor the 'successfully'). [1] https://hg.python.org/cpython/rev/484c50bf445c/ [2] https://github.com/python/cpython/blob/2.7/Lib/subprocess.py#L1370 [3] http://bugs.python.org/issue15756 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24862 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] Optimize coding with surrogateescape and surrogatepass error handlers
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch title: surrogateescape is too slow - Optimize coding with surrogateescape and surrogatepass error handlers Added file: http://bugs.python.org/file40183/faster_surrogates_hadling.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24862] subprocess.Popen behaves incorrect when moved in process tree
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24862 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Ilya Kulakov added the comment: I see issue to be fixed but patch wasn't applied yet. Is it still supposed to be included in 3.5 or there is something wrong? -- nosy: +Ilya.Kulakov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24859] ctypes.Structure bit order is reversed - counts from right
zeero added the comment: Thanks for the advise. I'll give it a try. So ctypes.Structure is always little endian regardless from the underlying architecture. I just checked on a raspberry pi 2 that should be a big endian device, and got the same results as before. I'm still not sure if it's right that ctypes.Structure swaps the order of the bit items but apparently it's the intended behaviour. I'll close the issue then. Thanks again. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
Terry J. Reedy added the comment: ... why would installing 3.4.3 or other versions be contaminated by stuff from another version, especially an ancient one? I don't know. Steve has revamped the installer for 3.5. Steve: This issue is solved and I am closing it, but I hope you either have or are able to make the installer more robust against this sort of situation. It seems to be fairly common. Could a 'purge all traces of tcl and python' option be added? -- nosy: +steve.dower resolution: - not a bug stage: - resolved status: open - closed type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24868 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Changes by Steve Dower steve.do...@python.org: -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
New submission from Steve Dower: The C Runtime used for Python 3.5 and later consists of two DLLs. One, ucrtbase.dll, is an operating system component that can be assumed to be available and up to date (or will be installed by the Python installer). The second DLL is vcruntimeXXX.dll, where XXX is a version number that is directly tied to the version of the compiler that was used to build. In order to maintain version-independence from the C Runtime, vcruntime should be statically, rather than dynamically, linked. This ensures that extensions linking to a different vcruntime will run on machines with builds of Python prior to that version being available (i.e. we'd have needed a time machine to be able to ensure all future versions of vcruntime are available). This would essentially put us back in a place where you need to match compilers to build extensions. To achieve this semi-static linking, the following options must be used. cl /c /MT /GL file.c link file.obj /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib Building with /MT links everything statically, and the last two linker options substitute the non-static ucrtbase.dll. /GL and /LTCG (link-time code generation) ensures the correct stubs for dynamic linking are created - compiling with /MD instead of /MT generates these at compile time instead of link time. One problem appears to be including custom-built static libraries that compiled objects with /MD instead of /MT: cl /C testlib.c /MD lib testlib.c cl /C test.c /MT /GL link test.obj testlib.lib /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib linker errors occur These are because testlib.lib pulls in the MSVCRT library (which indirectly includes the dynamic vcruntime.lib and ucrt.lib) instead of the LIBCMT library (which indirectly includes the static libvcruntime.lib and libucrt.lib). Building test.c with /MT pulls in LIBCMT and conflicts ensue. This may be fixed by using /MD for test.c, but this causes a dependency on vcruntimeXXX.dll. It appears that it can also be fixed by excluding MSVCRT from the final link step: link test.obj testlib.lib /LTCG **/NODEFAULTLIB:msvcrt.lib** /NODEFAULTLIB:libucrt.lib ucrt.lib Christoph - I know you've already patched your _msvccompiler.py to use /MD instead of /MT, but I wonder if you could try reverting that and adding the /NODEFAULTLIB:msvcrt.lib linker option instead and see if that helps? For my test cases it's been fine, but you have a much larger collection of libraries to work with. I'm very keen to see if this is a satisfactory solution. FWIW, I've spent a lot of time considering ways we could actually include vcruntime*.dll such that old Python versions would include or get future versions of the DLL and have come up with nothing. Requiring users to install every VC redistributable that is released is unacceptable to me, and I would much rather help extension builders to create extensions that do not require extra DLLs. -- assignee: steve.dower components: Windows messages: 248646 nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware priority: release blocker severity: normal status: open title: Add /NODEFAULTLIB:MSVCRT to _msvccompiler type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
Steve Dower added the comment: Actually, that's a pretty good idea (I'd certainly use it), though it would come with a big fat warning sign. I'll add an issue for it. Whether it would fix this particular issue is unclear. I suspect this one is due to environment variables (TCL_LIBRARY overrides tkinter's regular search) which could not be aggressively cleaned up on uninstall. I have no idea whether older installers used to set that environment variable, but recent 2.7 and 3.5 don't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24868 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24873] Add full cleanup checkbox to uninstaller
New submission from Steve Dower: On uninstallation, we should display a checkbox to aggressively clean up the install. This would include: * delete the main registry key and all children, regardless of whether we created them or not * delete the main install directory and all subdirectories and files This may corrupt some programs, essentially those that install packages directly into a Python install or register their own search paths in the registry (which is actually a valid thing for them to do). There will be an extra confirmation prompt if the checkbox is selected, but it'll still be easier than finding all the paths and deleting them manually. -- components: Installation, Windows messages: 248649 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add full cleanup checkbox to uninstaller type: enhancement versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
jack added the comment: If you zap all existing traces of Python and tcl it would affect users who need to run multiple versions. I would suggest completely encapsulating each version and all its dependencies, in order to avoid mutual interference. On 8/15/2015 2:55 PM, Steve Dower wrote: Steve Dower added the comment: Actually, that's a pretty good idea (I'd certainly use it), though it would come with a big fat warning sign. I'll add an issue for it. Whether it would fix this particular issue is unclear. I suspect this one is due to environment variables (TCL_LIBRARY overrides tkinter's regular search) which could not be aggressively cleaned up on uninstall. I have no idea whether older installers used to set that environment variable, but recent 2.7 and 3.5 don't. -- ___ Python trackerrep...@bugs.python.org http://bugs.python.org/issue24868 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24868 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24873] Add full cleanup checkbox to uninstaller
Steve Dower added the comment: (Terry - FYI as it was your suggestion, but feel free to un-nosy yourself if you want.) -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24873 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Thank you for looking into this. I just tried '/NODEFAULTLIB:msvcrt.lib' with Pillow and matplotlib but still get the linker errors: tiff.lib(jbig.obj) : error LNK2001: unresolved external symbol __imp_memchr freetype.lib(ftbase.obj) : error LNK2001: unresolved external symbol __imp_strrchr freetype.lib(truetype.obj) : error LNK2001: unresolved external symbol __imp_strstr freetype.lib(type1.obj) : error LNK2001: unresolved external symbol __imp_memchr freetype.lib(sfnt.obj) : error LNK2001: unresolved external symbol __imp_memchr Looks like I'll have to rebuild all the 3rd party libraries with '/MT' and link DLLs with '/NODEFAULTLIB:libucrt.lib ucrt.lib' to remove the dependency on vcruntimeXXX.dll. This change should probably be mentioned in the release notes. Maybe also bring it to the attention of Ilan Schnell (ilan) and Cournapeau David (cdavid) who build packages for Anaconda and Canopy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Marc-Andre Lemburg added the comment: What effect does this static linking of the VC runtime have on libraries that extension modules link at dynamically ? E.g. say I have an extension which links against an ODBC driver DLL using a different VC runtime than the one used to build Python. In the past, the has never been an issue, so adding a requirement to rebuild external libraries is pretty much a no-go for Python extension writing. You often have the case where you cannot rebuild the external libraries you want to link against. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
Steve Dower added the comment: I can't vouch for Python 2.2, but Python 3.5 and later should not have any interference with other Python versions unless you choose to add it to PATH. We have kept all installed files and registry keys in their own versioned paths for a long time now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24868 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Steve Dower added the comment: I guess those imports are expected to come from vcruntime. Rebuilding the static libraries may be the only option then, sorry (on the bright side, VC 14 has much better C99 support than earlier versions, so things should be better once we get past the problems caused by change). Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes. * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves) * CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management. * potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself) The parts of the new CRT that will be statically linked are (broadly): * process/DLL initialization * exception handling * some functions that are also compiler intrinsics The first two don't apply for C static libraries, and even seem to be okay if the static lib is the one declaring main(). I did make the argument that they should be statically linked by default, but the response was that security patches may need to be applied to those parts of the code (particularly exception handling - corrupting the stack and then raising an exception is a great way to jump to whatever code you like). If Python shipped this DLL, it would not be updateable anyway, so static linking is a considered risk that could cause us to someday ship a security update due to a change in the CRT (exactly as has been the case for every other version of Python - nothing new here). The last item is what Christoph just hit - because the compiler may partially inline those functions (memchr, strchr, etc.) for fast paths, it needs intimate knowledge about how they are implemented. As a result, they go in the compiler-version specific DLL and not the generic one. This lets the implementations make assumptions about what conditions the compiler has already tested and/or proven, but since this could change with compiler version the implementation may also change. Since the functions are stateless, there's no issue if they happen to be included in a final DLL multiple times for different versions, but that will only happen if the original library is compiled with /MT (I checked - there's no way to override the code generated here under /MD other than to change the compiler option, but link-time code generation should be able to take /MT-compiled libraries and dynamically link them). So basically, there are no new restrictions on linking to dynamic libraries. The biggest concern would be if those libraries depend on msvcr100.dll and worked with Python 3.4 (which shipped msvcr100), they may not work on Python 3.5 unless the user has obtained msvcr100.dll some other way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
