[issue11361] suggestion for os.kill(pid,CTRL_C_EVENT)
New submission from Igor :
Hello!
I see some 'skip' in test_os.py
@unittest.skip("subprocesses aren't inheriting CTRL+C property")
def test_CTRL_C_EVENT(self):
I think, problem with calling SetConsoleCtrlHandler(NULL,0) in parent process,
rather in child. If call SetConsoleCtrlHandler(NULL, 0).
Calling SetConsoleCtrlHandler(ctrl_handler, 1) is not enough. Need first call
SetConsoleCtrlHandler(NULL, 0).
My patch for this test fixture: (may be, not so good, but it works)
H:\usr\python27\Lib\test>diff win_console_handler.py win_console_handler.py_orig
26,27d25
< elif sig == signal.SIGINT:
< pass
34,35d31
< def ctrl_handler_int(sig, obj):
< sys.exit(1)
40d35
< NULL = ctypes.POINTER(ctypes.c_int)()
43,53d37
< # Calling this with NULL and FALSE causes the calling process to
< # handle CTRL+C, rather than ignore it. This property isn't inherited
< # by subprocesses, if it's created with CREATE_NEW_PROCESS_GROUP flag
< SetConsoleCtrlHandler.argtypes = (ctypes.POINTER(ctypes.c_int), wintypes.B
OOL)
< if not SetConsoleCtrlHandler(NULL, 0):
< print("Unable to restore SetConsoleCtrlHandler")
< exit(-1)
<
< signal.signal(signal.SIGINT, ctrl_handler_int)
<
< SetConsoleCtrlHandler.argtypes = (HandlerRoutine, wintypes.BOOL)
57a42
>
And on my machine (win2003 32bit):
...
test_CTRL_BREAK_EVENT (__main__.Win32KillTests) ... ok
test_CTRL_C_EVENT (__main__.Win32KillTests) ... ok
test_kill_int (__main__.Win32KillTests) ... ok
test_kill_sigterm (__main__.Win32KillTests) ... ok
--
Ran 61 tests in 2.344s
OK
--
components: IO
messages: 129761
nosy: iigor
priority: normal
severity: normal
status: open
title: suggestion for os.kill(pid,CTRL_C_EVENT)
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue11361>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11361] suggestion for os.kill(pid,CTRL_C_EVENT)
Changes by Igor : -- keywords: +patch Added file: http://bugs.python.org/file20958/1.patch ___ Python tracker <http://bugs.python.org/issue11361> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2291] Catching all exceptions with 'object'
New submission from Igor <[EMAIL PROTECTED]>:
I have discovered the following behaviour in 2.5, which I cannot explain:
>>> try:
... raise ValueError("foo")
... except object:
... print "aiee!"
...
Traceback (most recent call last):
File "", line 2, in
ValueError: foo
>>> sys.version
'2.5.1 (r251:54863, Jan 23 2008, 16:53:41) \n[GCC 4.2.2 (Gentoo 4.2.2
p1.0)]'
>>> isinstance(ValueError("foo"), object)
True
At first I thought I misunderstood something about exceptions, but the
wording of the try-statement leads me to believe that this should work.
ValueError is a subclass of object and thus, I think, should be a match,
thus catching the exception.
I realize that all exceptions should inherit from Exception
(BaseException?), but for the sake of consistence, shouldn't "except
object" catch *anything* in python 2.5? I.e. be the equivalent of "except:".
Is this a bug? If so, should this be fixed?
--
components: None
messages: 63538
nosy: zotbar1234
severity: normal
status: open
title: Catching all exceptions with 'object'
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2291>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16865] ctypes arrays >=2GB in length causes exception
Changes by Igor : -- nosy: +i3v ___ Python tracker <http://bugs.python.org/issue16865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29843] errors raised by ctypes.Array for invalid _length_ attribute
Igor added the comment: Oren, won't the "too large _length_" case vanish, if https://github.com/python/cpython/pull/3006 would be accepted ? ( http://bugs.python.org/issue16865 ) -- nosy: +i3v ___ Python tracker <http://bugs.python.org/issue29843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29843] errors raised by ctypes.Array for invalid _length_ attribute
Igor added the comment: Oren, 1) I might be completely wrong, but, personally, I think about OverflowError vs ValueError difference like this: if the value couldn't be handled because method's logic cannot handle it - it's a ValueError; if it could not be handled because of a low-level platform-dependent limitation - it's an OverflowError. Before that PR, the _length_ maximum value was hard-coded in the method itself, thus one might say that it was "a part of logic". With this PR, you just need a system with a large enough size_t. (May be, after a thousand years, it would even handle 2**1000. But negative values would be still logically incorrect. Thus, I'm only talking about "too large" case.) 2) It would be much more difficult to run into this limitation in a daily practice (e.g. by passing a very long string). -- ___ Python tracker <http://bugs.python.org/issue29843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29875] IDLE quit unexpectedly
New submission from Igor: Hi! I'm a newbie, both in this community and with Python. I downloaded Python today (March 22, 2017, version 3.6.1) and as I was following a tutorial on how to build my first program (the classical Hello World) with Python, the IDLE window closed and my Mac showed the following message: "IDLE quit unexpectedly". It happens every time I type the ' (single quotation mark).I've tried 10 times so far and it keeps happening. Thank you! -- assignee: terry.reedy components: IDLE messages: 289970 nosy: igorafm, terry.reedy priority: normal severity: normal status: open title: IDLE quit unexpectedly versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17560] problem using multiprocessing with really big objects?
Changes by Igor : -- nosy: +i3v ___ Python tracker <http://bugs.python.org/issue17560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28053] parameterize what serialization is used in multiprocessing
Change by Igor : -- nosy: +i3v ___ Python tracker <https://bugs.python.org/issue28053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25370] Add support of pickling very large bytes and str objects with protocol < 4
Change by Igor : -- nosy: +i3v ___ Python tracker <https://bugs.python.org/issue25370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13746] ast.Tuple's have an inconsistent "col_offset" value
New submission from Igor Bronshteyn :
Consider the following snippet (the file is attached):
code starts
a = [1, 3.14, 'abc', u'XYZ']
b = (1, 3.14, 'abc', u'XYZ')
c = {1 : 3.14, 'abc' : u'XYZ'}
= code ends =
The list has correct position: (1,4), the dict has correct position too: (3,4).
But the position of tuple node (ast.Tuple) has wrong or inconsistent
"col_offset" = 5: (2,5).
--
files: sample01.py
messages: 150950
nosy: bronikkk
priority: normal
severity: normal
status: open
title: ast.Tuple's have an inconsistent "col_offset" value
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file24187/sample01.py
___
Python tracker
<http://bugs.python.org/issue13746>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13746] ast.Tuple's have an inconsistent "col_offset" value
Igor Bronshteyn added the comment: I mean, that AST generated with standard "ast.parse" has nodes with confusing positions. Sorry for the first indistinct message. -- ___ Python tracker <http://bugs.python.org/issue13746> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43650] MemoryError on zip.read in shutil._unpack_zipfile
New submission from igor voltaic : MemoryError: null ... File "", line 13, in repack__file shutil.unpack_archive(local_file_path, local_dir) File "python3.6/shutil.py", line 983, in unpack_archive func(filename, extract_dir, **kwargs) File "python3.6/shutil.py", line 901, in _unpack_zipfile data = zip.read(info.filename) File "python3.6/zipfile.py", line 1338, in read return fp.read() File "python3.6/zipfile.py", line 858, in read buf += self._read1(self.MAX_N) File "python3.6/zipfile.py", line 948, in _read1 data = self._decompressor.decompress(data, n) shutil.unpack_archive tries to read the whole file into memory, making use of any buffer at all. Python crashes for really large files. In my case — archive: ~1.7G, unpacked: ~10G. Interestingly zipfile.ZipFile.extractall handles this case more effective. -- components: Library (Lib) messages: 389652 nosy: igorvoltaic priority: normal severity: normal status: open title: MemoryError on zip.read in shutil._unpack_zipfile type: crash versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43650] MemoryError on zip.read in shutil._unpack_zipfile
Igor Bolshakov added the comment: pls review -- resolution: -> remind ___ Python tracker <https://bugs.python.org/issue43650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported.
New submission from Igor Ceh : While trying to build Python 3.8.1 from source with Sqlite 3.30.1 on a CentOS 6.10 I get the following warning: *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.8/_sqlite3.cpython-38-x86_64-linux-gnu.so: undefined symbol: sqlite3_close_v2 The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Failed to build these modules: _uuid Following modules built successfully but were removed because they could not be imported: _sqlite3 If I try to import sqlite in python: [vagrant@centos6 Python-3.8.1]$ ./python Python 3.8.1 (default, Jan 21 2020, 04:22:59) [GCC 4.4.7 20120313 (Red Hat 4.4.7-23)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sqlite3 Traceback (most recent call last): File "", line 1, in File "/usr/local/src/Python-3.8.1/Lib/sqlite3/__init__.py", line 23, in from sqlite3.dbapi2 import * File "/usr/local/src/Python-3.8.1/Lib/sqlite3/dbapi2.py", line 27, in from _sqlite3 import * ModuleNotFoundError: No module named '_sqlite3' >>> Also tried building with SQLite version 3.7.9 from atomic repository with same error. -- messages: 360395 nosy: cehovski priority: normal severity: normal status: open title: CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported. type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported.
Igor Ceh added the comment: I've changed ./Modules/_sqlite/util.h //#if SQLITE_VERSION_NUMBER >= 3007014 #if SQLITE_VERSION_NUMBER >= 3107014 // Change #define SQLITE3_CLOSE sqlite3_close_v2 #else #define SQLITE3_CLOSE sqlite3_close #endif #endif And tried to recompile with a new error: *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.8/_sqlite3.cpython-38-x86_64-linux-gnu.so: undefined symbol: sqlite3_errstr The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Failed to build these modules: _uuid Following modules built successfully but were removed because they could not be imported: _sqlite3 Went into ./Modules/_sqlite/connection.c and also changed: //#if SQLITE_VERSION_NUMBER > 3007015 #if SQLITE_VERSION_NUMBER > 3107015 // Change PyErr_SetString(pysqlite_OperationalError, sqlite3_errstr(rc)); With these changes the build was successful and I can import sqlite3. But I have no idea if this has any unforeseen consequences. -- ___ Python tracker <https://bugs.python.org/issue39410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Hi All, It seems this patch removes some functions provided by the Stable ABI (PEP 384), most notably Py_CompileString. Was this the intention? If not, is there still a chance to reintroduce it before the release? -- nosy: +Igor.Skochinsky ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: > But Py_CompileString() function was not removed, it's still in the master > branch (future Python 3.10). Why do you think that it has been removed? Thank you. It looked that way because of the removed block of lines in the commit 1ed83adb0e95305af858bd41af531e487f54fee7 (pythonrun.c). We were also getting a missing symbol error. We'll check again to be sure. -- ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Attached is a sample program which works on 3.9 but fails linking with 3.10.0a2 The .so is missing the symbol: igor@LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.9.so | grep Py_CompileString 00212720 T Py_CompileString 0020fe30 T Py_CompileStringExFlags 00212730 T Py_CompileStringFlags 0020fd40 T Py_CompileStringObject igor@LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.10.so | grep Py_CompileString 00201a40 T Py_CompileStringExFlags 00201980 T Py_CompileStringObject Please stop breaking the Stable ABI :/ -- Added file: https://bugs.python.org/file49642/py_limited_api_example.zip ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Thanks for the fix! I'd like to submit a test to avoid this and similar issues in future. Are there any guidelines for this? Sorry if this is a wrong place to ask. -- ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: > I am currently working on test that checks that the stable API symbols are > correctly exported. Thank you very much! For added motivation, the 3.8.0 release was unusable thanks to issue37633 which was somewhat similar (also in pythonrun). For reference, I've attached a list of symbols we currently use (a few more we have to import dynamically since they're not in the stable ABI but we'd like to keep that list as short as possible). -- Added file: https://bugs.python.org/file49647/py3.txt ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42545] Check that all symbols in the limited ABI are exported
Change by Igor Skochinsky : -- nosy: +Igor.Skochinsky ___ Python tracker <https://bugs.python.org/issue42545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43375] memory leak in threading ?
Igor Mandrichenko added the comment: You are right. When I add join(), the memory does not grow any more. Thanks ! -- ___ Python tracker <https://bugs.python.org/issue43375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43375] memory leak in threading ?
Change by Igor Mandrichenko : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43375] memory leak in threading ?
New submission from Igor Mandrichenko : There is an apparent memory leak in threading. It looks like memory grows when I create, run and destroy threads. The memory keeps adding at the rate of about 100 bytes per thread. I am attaching the code, which works for Linux. getMemory() function is Linux-specific, it gets current process memory utilization -- components: Extension Modules files: memleak.py messages: 387948 nosy: igorvm priority: normal severity: normal status: open title: memory leak in threading ? type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49846/memleak.py ___ Python tracker <https://bugs.python.org/issue43375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43375] memory leak in threading ?
Igor Mandrichenko added the comment: Since Timer thread is never joined, should not it be a daemon ? -- ___ Python tracker <https://bugs.python.org/issue43375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31351] ensurepip discards pip's return code which leads to broken venvs
New submission from Igor Filatov: ensurepip runs pip with a function that discards the result code that pip produces: def _run_pip(args, additional_paths=None): # ... pip.main(args) pip.main() is designed not to raise command exceptions. Instead it returns exit codes which are to be passed to sys.exit(). Since ensurepip does not process the return value of pip.main() in any way, python -m ensurepip always exits with 0 on such exceptions (even though there's a stack trace, printing of which is handled by pip). EC should be 0 only in case of success. This is an issue in venv because it runs ensurepip in a subprocess and cannot detect a failure: def _setup_pip(self, context): # ... cmd = [context.env_exe, '-Im', 'ensurepip', '--upgrade', '--default-pip'] subprocess.check_output(cmd, stderr=subprocess.STDOUT) And this leads to broken venvs in some cases. The easiest way to reproduce: $ mkdir venv-test $ cd venv-test/ $ echo garbage > setup.cfg $ python3 -m venv broken $ broken/bin/pip bash: broken/bin/pip: No such file or directory There are no errors until you need pip. The culprit is this: $ broken/bin/python -Im ensurepip --upgrade --default-pip Ignoring indexes: https://pypi.python.org/simple Collecting setuptools Collecting pip Collecting pkg_resources Installing collected packages: setuptools, pip, pkg-resources Exception: Traceback (most recent call last): File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/basecommand.py", line 209, in main status = self.run(options, args) File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/commands/install.py", line 335, in run prefix=options.prefix_path, File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/req/req_set.py", line 732, in install **kwargs File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/req/req_install.py", line 837, in install self.move_wheel_files(self.source_dir, root=root, prefix=prefix) File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/req/req_install.py", line 1039, in move_wheel_files isolated=self.isolated, File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/wheel.py", line 247, in move_wheel_files prefix=prefix, File "/tmp/tmpgjpdbf_e/pip-8.1.1-py2.py3-none-any.whl/pip/locations.py", line 141, in distutils_scheme d.parse_config_files() File "/usr/lib/python3.5/distutils/dist.py", line 395, in parse_config_files parser.read(filename) File "/usr/lib/python3.5/configparser.py", line 696, in read self._read(fp, filename) File "/usr/lib/python3.5/configparser.py", line 1077, in _read raise MissingSectionHeaderError(fpname, lineno, line) configparser.MissingSectionHeaderError: File contains no section headers. file: 'setup.cfg', line: 1 'garbage\n' But any other exception during pip any_command would've had the same effect. This is hard to diagnose because no output is produced by subprocess due to the exception. ensurepip should propagate the code returned by pip and pass it to sys.exit(). Alternatively ensurepip can have it's own EC for cases when pip.main(args) != 0. -- components: Library (Lib) messages: 301367 nosy: Igor Filatov priority: normal severity: normal status: open title: ensurepip discards pip's return code which leads to broken venvs type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31351] ensurepip discards pip's return code which leads to broken venvs
Changes by Igor Filatov : -- keywords: +patch pull_requests: +3615 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35729] XML.etree bug
New submission from Igor Nowicki : Consider we have big XML file and we can't load it all into memory. We use then `iterparse` function from XML.etree.ElementTree module to parse it element by element. Problem is, XML doesn't allow to run this smoothly and starts outputing wrong data after loading 16 kb (16*1024, found it after looking into source code). Having large number of children, we get the information that we have just a few. To reproduce the problem, I created this example program. It makes simple xml file with progressively bigger files and tracks how many children of main objects there are counted. For small objects we have actual number, 100 children. For bigger and bigger sizes we have smaller numbers, going down to just few. -- components: Library (Lib) files: find_records.py messages: 333549 nosy: Igor Nowicki priority: normal severity: normal status: open title: XML.etree bug type: performance versions: Python 3.6 Added file: https://bugs.python.org/file48046/find_records.py ___ Python tracker <https://bugs.python.org/issue35729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35822] _queue _queuemodule.c is missing inside the Setup file
New submission from Igor Z : I had to install manually new urllib3 (zip archive) module inside python 3.7 and got and error that module "_queue" is missing. I did not find anything related to such module inside the Setup file. Then I found this module in the github and manually added: _queue _queuemodule.c and did "make" once again to get new "libpython3.7m.so.1.0" that I needed for the project. The problem was solved. -- assignee: docs@python components: Build, Documentation, Library (Lib) messages: 334329 nosy: Igor Z, docs@python priority: normal severity: normal status: open title: _queue _queuemodule.c is missing inside the Setup file type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33096] ttk.Treeview.insert() does not allow to insert item with "False" iid
New submission from Igor Yakovchenko : ttk.Treeview.insert(... iid=None, ...) method has a check: if iid: res = self.tk.call(self._w, "insert", parent, index, "-id", iid, *opts) else: res = self.tk.call(self._w, "insert", parent, index, *opts) Documentation says that "If iid is specified, it is used as the item identifier", but as you can see from code, iid is used only if it's "True". It means that you cannot use iids like 0, 0.0 etc. -- components: Tkinter messages: 314032 nosy: gpolo, serhiy.storchaka, truestarecat priority: normal severity: normal status: open title: ttk.Treeview.insert() does not allow to insert item with "False" iid type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31351] ensurepip discards pip's return code which leads to broken venvs
Changes by Igor Filatov : -- pull_requests: +3720 stage: backport needed -> patch review ___ Python tracker <https://bugs.python.org/issue31351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31351] ensurepip discards pip's return code which leads to broken venvs
Igor Filatov added the comment: Thanks for the reviews, Nick! -- ___ Python tracker <https://bugs.python.org/issue31351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols
New submission from Igor Skochinsky : Trying to install 3.6.3 on Windows 10 and getting this error. Repro steps: 1. Download python-3.6.3.exe or python-3.6.3-amd64.exe, run it 2. Select "Customize Installation" 3. Next 4. In Advanced Options, select [x] Install for all users (not sure if important) [x] Download debugging symbols change path to F:\Python36 (not sure if it matters but my system drive is F: and C: is missing except for when I plug in a USB drive) Ucheck [ ] Associate files with Python Click Install and accept elevation prompt. After a while it fails with Error 0x80091007 - Hash value not correct. Interestingly, "log file" link does not work. I had to go hunt for the log in %temp% myself. The relevant parts: Error 0x80091007: Hash mismatch for path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, expected: A4B6E4A818E49F000513774F034EC98A194E3C3D, actual: 36C7B852E586D26F4D239ED72EFE5FFBEBA21825 Error 0x80091007: Failed to verify hash of payload: core_AllUsers_pdb Failed to verify payload: core_AllUsers_pdb at path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, error: 0x80091007. Deleting file. Application requested retry of payload: core_AllUsers_pdb, encountered error: 0x80091007. Retrying... There are a few more retries basically with the same result. However, this one is interesting: Acquiring package: core_AllUsers_pdb, payload: core_AllUsers_pdb, copy from: F:\Users\Igor\Downloads\core_pdb.msi I don't have such a file there, just the installer .exe -- components: Installation messages: 304182 nosy: Igor.Skochinsky priority: normal severity: normal status: open title: Windows Installer fails with error 0x80091007 when trying to install debugging symbols type: security versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue31767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols
Igor Skochinsky added the comment: Hi Steve, Thanks for the suggestion! I tried that and while it did not succeed it gave me an idea of what went wrong last time since it complained about lack of disk space. I have *not* run the /layout but now that I checked I indeed had core_d.msi and core_pdb.msi (and a few more) in the Downloads directory, so I think maybe the installer tried to download them but ran out of space and the download was incomplete. Another possibility is that the .msi was for the wrong installer - I first tried installing the x86 version but later changed my mind but since I did not expect it to download extra files into the same directory I did not clean them. Also it seems the downloaded .msi files have the original timestamp (16-09-27) so I did not notice them when sorting my downloads by date until I tried to look for .msi files specifically. In the end I guess this could be closed as PEBKAC but I think maybe some more testing in low-disk-space conditions and/or installing x86 then x64 from the same directory could uncover some real issues. In general, I found the 3.3 install experience not very straightforward compared to 2.7 - I expected that the installer contains everything necessary (since I did *not* pick "webinstall" one) and won't download extra files (with the exception of the PDB option which did say "download"). If the .msi files came from the .exe itself, I'd expect them to be extracted into a unique temporary directory and not next to the exe. I will work on freeing some space and then try again. > Steve Dower added the comment: > > Can you try moving the installer exe to its own (empty) directory before > running it? > -- ___ Python tracker <https://bugs.python.org/issue31767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17213] ctypes loads wrong version of C runtime, leading to error message box from system
Igor Skochinsky added the comment: Just had this issue when using networkx (which imports uuid). One keyword that would help visibility is R6034 (the runtime error number). A couple of reports related to this: https://projects.blender.org/tracker/index.php?func=detail&aid=27666 http://forums.boxee.tv/showthread.php?t=15425 The proper solution is to fix ctypes, but in the meantime we can at least fix uuid. The error seems to be triggered by this snippet: # The uuid_generate_* routines are provided by libuuid on at least # Linux and FreeBSD, and provided by libc on Mac OS X. for libname in ['uuid', 'c']: try: lib = ctypes.CDLL(ctypes.util.find_library(libname)) except: continue if hasattr(lib, 'uuid_generate_random'): _uuid_generate_random = lib.uuid_generate_random if hasattr(lib, 'uuid_generate_time'): _uuid_generate_time = lib.uuid_generate_time Since this code is useless on Windows, protecting it in "if os.name not in ['nt', 'ce']" does the trick. BTW, instead of going all way with activation context etc., a simpler solution would be to add to ctypes something like this in CDLL.__init__: if os.name in ['nt', 'ce'] and name == util.find_msvcrt(): # TODO: handle the extension self._handle = windll.kernel32.GetModuleHandleA(self._name) i.e. use the already present runtime DLL instead of trying to load it again. -- nosy: +Igor.Skochinsky ___ Python tracker <http://bugs.python.org/issue17213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods
Igor Sobreira added the comment: Hello. I've attached a patch to cleanup self._top_level_dir in the end of discover(). Is that the expected behavior or I'm on the wrong track? -- keywords: +patch nosy: +igorsobreira Added file: http://bugs.python.org/file26442/restore_top_level_dir.patch ___ Python tracker <http://bugs.python.org/issue15010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods
Igor Sobreira added the comment: My previous patch is incorrect, talking to voidspace on irc self._top_leve_dir should be reverted to it's previous value "so when discover is called the original value should be stored, then discovery done, and then the original restored" I'll work on this one. He also pointed out that this bugfix should be backported to 2.7 and 3.2 -- ___ Python tracker <http://bugs.python.org/issue15010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods
Igor Sobreira added the comment: Updated patch to restore previous value of ._top_level_dir on discover() done. And added a unit test. -- Added file: http://bugs.python.org/file26458/restore_top_level_dir_to_previous_value.patch ___ Python tracker <http://bugs.python.org/issue15010> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Changes by Igor Pashev : Added file: http://bugs.python.org/file34961/dyson-socketmodule-ifindex.patch ___ Python tracker <http://bugs.python.org/issue21287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Igor Pashev added the comment: Related to http://bugs.python.org/issue8852 -- ___ Python tracker <http://bugs.python.org/issue21287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Changes by Igor Pashev : Removed file: http://bugs.python.org/file34952/dyson-socketmodule-ifindex.patch ___ Python tracker <http://bugs.python.org/issue21287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function)
Igor Franchuk added the comment: Confirmed as fixed at least in Python 3.3.5 Successfully compiled at Linux gw 2.6.33-gentoo #1 SMP Mon Mar 8 23:29:59 MSK 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux -- versions: -Python 3.4 ___ Python tracker <http://bugs.python.org/issue20065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21992] New AST node Else() should be introduced
New submission from Igor Bronshteyn: Quoting Collin Winter: "I'd like there to be an Else() node for If.orelse, While.orelse, etc. My motivation is that I need the lineno and col_offset values of the "else" statement for a code-coverage utility; as it is, I have to find the last lineno of the if/while/etc suite and the first lineno of the "else" suite and then search between those two for the "else" statement." from: http://bugs.python.org/issue1659410 Lack of position for "else" token hampers implementing of even simple static analysis checker that calculates NCNB (non-comment non-blank) lines (e.g. in a function). -- components: Interpreter Core messages: 223229 nosy: Igor.Bronshteyn priority: normal severity: normal status: open title: New AST node Else() should be introduced type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
New submission from Igor Pashev: I've found on illumos-based OS that under some conditions python is unable to open any files because set_inheritable() fails. This happens even when building python when it cannot find (open) _sysconfigdata.py. The problem is that set_inheritable() first checks for FIOCLEX/FIONCLEX ioctls and tries to use them if such macros are defined. These macros can be defined at illumos, but kernel does not support them (inappropriate ioctl). Since other pieces of python already use FD_CLOEXEC unconditionally, including get_inheritable() I patched set_inheritable() to use FD_CLOEXEC. See attached patch. -- components: Build, IO files: dyson-set_inheritable.patch keywords: patch messages: 225745 nosy: igor.pashev priority: normal severity: normal status: open title: Use FD_CLOEXEC in Python/fileutils.c type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36443/dyson-set_inheritable.patch ___ Python tracker <http://bugs.python.org/issue22258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
Igor Pashev added the comment: errno is 25 (#define ENOTTY 25 /* Inappropriate ioctl for device */) It does not make sense to me to call unworkable ioctl() each time before other methods :-) I would consider adding a configure check for working ioctl() (but it won't work for cross compilation). -- ___ Python tracker <http://bugs.python.org/issue22258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
Igor Pashev added the comment: Yes, Victor. Your patch works. All os tests are passed :-) -- ___ Python tracker <http://bugs.python.org/issue22258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function)
New submission from Igor Franchuk: Missing CAN_RAW check in Python 3.3.3 Python 3.3.3 assumes that if AF_CAN is defined then CAN_RAW is defined as well. It won't assemble with old kernels. Either an additional check for CAN_RAW should be applied in the configuration script or Python 3.3.3 dependence on the newest kernels should be made mandatory (configure check). It could be back to normal if a CAN_RAW check is applied and the problematic part of code is excluded. Python 3.3.3 can work with sockets without full CAN support but it won't. Environment: System uname: Linux-2.6.33-gentoo-i686-Intel-R-_Pentium-R-_D_CPU_3.00GHz-with-gentoo-1.12.1 Timestamp of tree: Sun, 22 Dec 2013 09:30:01 + ld GNU ld (GNU Binutils) 2.21 app-shells/bash: 4.2_p37 dev-lang/python: 2.4.3-r1::, 2.6.8, 2.7.3-r3, 3.1.1-r1, 3.2.3-r2 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 1.12.1:: sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13::, 2.69 sys-devel/automake: 1.4_p6::, 1.5::, 1.6.3::, 1.7.9-r1::, 1.8.5-r3::, 1.9.6-r2::, 1.10::, 1.11.1, 1.13.1 sys-devel/binutils: 2.21 sys-devel/gcc:4.1.1::, 4.2.4-r1, 4.4.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool:1.5.23b::, 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 2.6.21:: (virtual/os-headers) sys-libs/glibc: 2.10.1-r1 Repositories: gentoo ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org"; LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl alsa arts avi berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups cxx dbus dlloader dri dvd dvdr eds emboss encode esd fam fortran gdbm gif gnutls gpm gstreamer gtk hal iconv isdnlog jpeg kde ldap libg++ mad mikmod modules mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg symlink tcpd truetype truetype-fonts type1-fonts udev unicode vorbis win32codecs x86 xml xorg xv zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS=&
[issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function)
Changes by Igor Franchuk : -- type: -> compile error ___ Python tracker <http://bugs.python.org/issue20065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7189] struct.calcsize returns strange size
New submission from Igor Mikushkin :
I think in second case struct size should be 53.
In [31]: struct.calcsize('ihhi35scc')
Out[31]: 49
In [32]: struct.calcsize('ihhi35scci')
Out[32]: 56
--
components: Library (Lib)
messages: 94379
nosy: igor.mikushkin
severity: normal
status: open
title: struct.calcsize returns strange size
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue7189>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
New submission from Igor Kudrin:
It looks like resolving https://bugs.python.org/issue20160 didn't fix all the
issues. When a large struct is used as a parameter, a reference to the object
itself is passed to the function, not a reference to a temporary copy, as it is
required in https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx.
Here is the reproduction sample:
=== Sample.c: ===
typedef struct
{
int v[3];
} Data;
__declspec(dllexport) void Cripple(Data data)
{
data.v[0] = 0;
}
=== Sample.py ===
from ctypes import *
class Data(Structure):
_fields_ = [("v", c_int * 3)]
lib = cdll.LoadLibrary('Sample.dll')
getattr(lib, 'Cripple').argtypes = [Data]
data = Data()
data.v[0] = 42
lib.Cripple(data)
assert data.v[0] == 42
print "OK"
=== repro.cmd ===
call "%VS140COMNTOOLS%/../../VC/vcvarsall.bat" x86_amd64
cl /LD Sample.c
python Sample.py
------
components: Windows, ctypes
messages: 287831
nosy: Igor Kudrin, christian.heimes, doko, mark.dickinson, meador.inge,
paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
status: open
title: Still broken ctypes calling convention on MSVC / 64-bit Windows (large
structs)
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue29565>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall
New submission from Igor Skochinsky:
It's somewhat my fault but I think it's not such an uncommon scenario.
I had installed 2.7.10 x64 some time ago into C:\Python27_64 but then had to
delete it to save space. Rather foolishly instead of using the uninstaller, I
just trashed the directory and now I have a problem: neither the Control Panel
uninstall item, nor the fresh 2.7.12 installer work. The latter fails when it
tries to use the nonexisting Python to remove pip:
MSI (s) (04:B0) [11:00:09:881]: Product: Python 2.7.10 (64-bit) -- Error 1721.
There is a problem with this Windows Installer package. A program required for
this install to complete could not be run. Contact your support personnel or
package vendor. Action: RemovePip, location: C:\Python27_64\python.exe,
command: -B -m ensurepip._uninstall
In the UI just the first message is shown, without the failed commandline, so
it's not at all clear what went wrong.
I think at the very least the user should be informed about the failed command
so they can clean up the old installer's remains, or maybe the installation
should be allowed to proceed anyway, replacing the bad paths in the registry.
In the end, I had to use "Msizap TWA {E2B51919-207A-43EB-AE78-733F9C6797C3}"
after which I could install 2.7.12 into a separate directory
--
components: Installation
messages: 280747
nosy: Igor.Skochinsky
priority: normal
severity: normal
status: open
title: Python 2.7.12 windows x64 installer fails after previous bad uninstall
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue28687>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30554] Inaccessible attribute characters_written on OSError instances
New submission from Igor Kozyrenko (ikseek): If I enumerate attributes on OSError instance with dir dir(OSError()) I see an 'characters_written' attribute (which is supposed to be defined on BlockingIOError according to docs). If I try to access it getattr(OSError(), 'characters_written') I get an AttributeError -- components: Library (Lib) messages: 295030 nosy: Igor Kozyrenko (ikseek) priority: normal severity: normal status: open title: Inaccessible attribute characters_written on OSError instances type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30554] Inaccessible attribute characters_written on OSError instances
Igor Kozyrenko (ikseek) added the comment: So is it by design? cgitb library fails to create report if there are links to exceptions based on OSError on the stack because it tries to enumerate all it's attributes. -- ___ Python tracker <http://bugs.python.org/issue30554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346] Error using >>> from OpenGL.GLUT import *
Igor do Valle Campbell <[EMAIL PROTECTED]> added the comment: You have to put the glut32.dll in Windows/system32 folder. You can get glut32.dll here: http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip extract the glut32.dll to the Windows/system32 folder and voila. -- nosy: +igorcamp type: compile error -> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1346> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
