[issue36859] sqlite3 dml statement detection does not account for CTEs
Charles added the comment: Yeah, go for it erlendaasland - I abandoned all hope of getting it merged, and have just been maintaining my own pysqlite3 which simplifies my life greatly. -- ___ Python tracker <https://bugs.python.org/issue36859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34916] Add create_window_function() to sqlite3.Connection
Charles added the comment: I've implemented this in a fork / standalone packaging of the Python 3.x sqlite3 module. You can find the relevant portions (and a couple unrelated changes) in this commit: https://github.com/coleifer/pysqlite3/commit/91c20016fd3fd3d1d7ade475893046958f7faa00 -- nosy: +coleifer ___ Python tracker <https://bugs.python.org/issue34916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16958] The sqlite3 context manager does not work with isolation_level=None
Charles added the comment: > With isolation_level set to None, the sqlite3 library is in autocommit mode, > so changes will get committed immediately inside the with, which is simply > broken. Not necessarily. When sqlite is in autocommit mode, you can still open transactions by executing a BEGIN query. In fact, that's the main reason to use isolation_level=None -- you can manage the transactions yourself. -- nosy: +coleifer ___ Python tracker <https://bugs.python.org/issue16958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36859] sqlite3 dml statement detection does not account for CTEs
New submission from Charles :
In statement.c, there is some logic which detects whether or not an incoming
statement is a DML-type. The logic, as of 2019-05-08, I am referring to is
here:
https://github.com/python/cpython/blob/fc662ac332443a316a120fa5287c235dc4f8739b/Modules/_sqlite/statement.c#L78-L93
To demonstrate the bug:
import sqlite3
conn = sqlite3.connect(':memory:')
conn.execute('create table kv ("key" text primary key, "value" integer)')
conn.execute('insert into kv (key, value) values (?, ?), (?, ?)',
('k1', 1, 'k2', 2))
assert conn.in_transaction # Yes we are in a transaction.
conn.commit()
assert not conn.in_transaction # Not anymore, as expected.
rc = conn.execute(
'with c(k, v) as (select key, value + 10 from kv) '
'update kv set value=(select v from c where k=kv.key)')
print(rc.rowcount) # Should be 2, prints "-1".
#assert conn.in_transaction # !!! Fails.
curs = conn.execute('select * from kv order by key;')
print(curs.fetchall()) # [('k1', 11), ('k2', 12)]
--
components: Library (Lib)
messages: 341949
nosy: coleifer
priority: normal
severity: normal
status: open
title: sqlite3 dml statement detection does not account for CTEs
type: behavior
___
Python tracker
<https://bugs.python.org/issue36859>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36859] sqlite3 dml statement detection does not account for CTEs
Charles added the comment: Sqlite since 3.7.11 provides sqlite3_stmt_readonly() API for determining if a prepared statement will affect the database. I made the change, removing the SQL scanning code and replacing it with: self->is_dml = !sqlite3_stmt_readonly(self->st); But then I see a number of test failures, mostly related to the fact that table-creation is now treated as "is_dml" with the above change. I don't know if the above API is going to be a workable path forward, since it seems like DML statements *not* automatically starting a transaction is a behavior a lot of people may have come to depend on (whether or not it is correct). I've attached a patch just-in-case anyone's interested. -- keywords: +patch Added file: https://bugs.python.org/file48319/36859.patch ___ Python tracker <https://bugs.python.org/issue36859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36859] sqlite3 dml statement detection does not account for CTEs
Charles added the comment: Oh, one more thing that is actually quite important -- since BEGIN IMMEDIATE and BEGIN EXCLUSIVE "modify" the database, these statements (intended to begin a transaction) are treated as "is_dml" when using the sqlite3_stmt_readonly API. -- ___ Python tracker <https://bugs.python.org/issue36859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36859] sqlite3 dml statement detection does not account for CTEs
Charles added the comment: I've got a patch working now that: - retains complete backwards-compatibility for DDL (as well as BEGIN EXCLUSIVE/IMMEDIATE) -- tests are passing locally. - retains previous behavior for old sqlite that do not have the sqlite3_stmt_readonly API. I think this should be good-to-go and I've in fact merged a similar patch on my own standalone pysqlite3 package. Also I will add that the little 'test script' I provided is working as-expected with this patch applied. -- Added file: https://bugs.python.org/file48320/36859-2.patch ___ Python tracker <https://bugs.python.org/issue36859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36859] sqlite3 dml statement detection does not account for CTEs
Change by Charles : -- pull_requests: +13127 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
New submission from Charles :
On macOS I could build python 2.7.14 with libressl 2.6.4 without any problems.
If I try to build that same version of python with libressl 2.7.0, I get the
failure pasted in below.
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:141:12:
error: static declaration of 'X509_NAME_ENTRY_set' follows non-static
declaration
static int X509_NAME_ENTRY_set(const X509_NAME_ENTRY *ne)
^
/usr/local/ssl/include/openssl/x509.h:1139:6: note: previous declaration is here
int X509_NAME_ENTRY_set(const X509_NAME_ENTRY *ne);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:153:25:
error: static declaration of 'SSL_CTX_get_default_passwd_cb' follows
non-static declaration
static pem_password_cb *SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx)
^
/usr/local/ssl/include/openssl/ssl.h:1368:18: note: previous declaration is here
pem_password_cb *SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:158:14:
error: static declaration of 'SSL_CTX_get_default_passwd_cb_userdata' follows
non-static declaration
static void *SSL_CTX_get_default_passwd_cb_userdata(SSL_CTX *ctx)
^
/usr/local/ssl/include/openssl/ssl.h:1370:7: note: previous declaration is here
void *SSL_CTX_get_default_passwd_cb_userdata(SSL_CTX *ctx);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:163:12:
error: static declaration of 'X509_OBJECT_get_type' follows non-static
declaration
static int X509_OBJECT_get_type(X509_OBJECT *x)
^
/usr/local/ssl/include/openssl/x509_vfy.h:428:5: note: previous declaration is
here
int X509_OBJECT_get_type(const X509_OBJECT *a);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:168:14:
error: static declaration of 'X509_OBJECT_get0_X509' follows non-static
declaration
static X509 *X509_OBJECT_get0_X509(X509_OBJECT *x)
^
/usr/local/ssl/include/openssl/x509_vfy.h:430:7: note: previous declaration is
here
X509 *X509_OBJECT_get0_X509(const X509_OBJECT *xo);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:173:31:
error: static declaration of 'X509_STORE_get0_objects' follows non-static
declaration
static STACK_OF(X509_OBJECT) *X509_STORE_get0_objects(X509_STORE *store) {
^
/usr/local/ssl/include/openssl/x509_vfy.h:438:24: note: previous declaration is
here
STACK_OF(X509_OBJECT) *X509_STORE_get0_objects(X509_STORE *xs);
^
/Users/chdiza/.tmp/tmpdir/python27-20180323-74284-f2auy2/Python-2.7.14/Modules/_ssl.c:177:27:
error: static declaration of 'X509_STORE_get0_param' follows non-static
declaration
static X509_VERIFY_PARAM *X509_STORE_get0_param(X509_STORE *store)
^
/usr/local/ssl/include/openssl/x509_vfy.h:450:20: note: previous declaration is
here
X509_VERIFY_PARAM *X509_STORE_get0_param(X509_STORE *ctx);
^
7 errors generated.
--
assignee: christian.heimes
components: SSL
messages: 314320
nosy: chdiza, christian.heimes
priority: normal
severity: normal
status: open
title: Python 2.7.14 won't build ssl module with Libressl 2.7.0
type: compile error
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue33127>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
Charles added the comment: I'm not sure it's a beta release. I think they just forgot to update on their homepage what the latest stable is. Nothing on the releases page or the release notes says it's a beta. -- ___ Python tracker <https://bugs.python.org/issue33127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
Charles added the comment: FYI, the 'cryptography' package from pypi no longer builds after this fix. (I applied the patch to the 2.7.14 source code tarball.) I don't know if that's because of the fix, or because LibreSSL 2.7.X broke 'cryptography' too: clang -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/slangs/py/include/python2.7 -c build/temp.macosx-10.13-x86_64-2.7/_openssl.c -o build/temp.macosx-10.13-x86_64-2.7/build/temp.macosx-10.13-x86_64-2.7/_openssl.o -Wconversion -Wno-error=sign-conversion build/temp.macosx-10.13-x86_64-2.7/_openssl.c:493:10: fatal error: 'openssl/opensslv.h' file not found #include ^~~~ 1 error generated. error: command 'clang' failed with exit status 1 -- ___ Python tracker <https://bugs.python.org/issue33127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] `eval("-"*3000000 + "4")` in cmd causes hard crash
New submission from Charles McMarrow :
`eval("-"*300 + "4")` in cmd causes hard crash
--
components: Parser
messages: 408753
nosy: charles.mcmarrow.4, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: `eval("-"*300 + "4")` in cmd causes hard crash
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46110>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Charles G. added the comment: My previous Windows version (Win 10 1803) does not have this crashing problem. It only crashed after upgrading to 21H1. So I replaced hhctrl.ocx in system32 (Win 10 21H1) with hhctrl.ocx from Windows.old. 2019/03/19 11:45 696.320 hhctrl.ocx 2021/09/23 03:29 729.600 hhctrl.ocx.old -- nosy: +Charles G. ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46742] Add '-d $fd' option to trace module, akin to bash -x feature
New submission from Charles Howes : The 'trace' module logs trace output to stdout, intermingled with regular program output. This is a problem when you want to read either the trace output or the normal output of the program separately. To separate the trace output, it could be written to a file or to another file descriptor. A pull request has been created that fixes this by mimicking bash's behaviour: bash can be told to write trace output to a different file descriptor using the BASH_XTRACEFD shell variable: `exec 42> xtrace.out; BASH_XTRACEFD=42; ...` Usage of this new feature: python -m trace -t -d 111 your_program.py 111> /tmp/your_trace.txt or: t = Trace(count=1, trace=1, trace_fd=1, countfuncs=0, countcallers=0, ignoremods=(), ignoredirs=(), infile=None, outfile=None, timing=False) Notes: * `bash -x` sends trace logs to stderr by default; `python -m trace -t` sends them to stdout. I wanted to change Python to match, but was worried that this might break existing code. * Also considered writing trace logs to the file specified with the `-f FILE` option, but worried that it would mess up the count file if `-t` and `-c` were used together. -- components: Library (Lib) messages: 413197 nosy: PenelopeFudd priority: normal severity: normal status: open title: Add '-d $fd' option to trace module, akin to bash -x feature type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46742] Add '-d $fd' option to trace module, akin to bash -x feature
Change by Charles Howes : -- keywords: +patch pull_requests: +29478 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31319 ___ Python tracker <https://bugs.python.org/issue46742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
Charles Solar added the comment: I just recompiled using your suggested flags and it is now properly linking my extensions. I guess using CFLAGS and LDFLAGS was causing the problem. Is specifying CC the recommended way to build 64 bit python? If so when I guess this issue is not really an issue at all. -- ___ Python tracker <http://bugs.python.org/issue9181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9181] Solaris extension building does not work with 64 bit python
Charles Solar added the comment: Hello again, I got a copy of the latest python from the 2.7 branch, recompiled with CFLAGS="-m64 -O3" and LDFLAGS="-m64" and my extension compiled just fine. So I can verify this bug fixed -- ___ Python tracker <http://bugs.python.org/issue9181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10613] gzip._PaddedFile calls getattr with arguments in reversed order
New submission from Charles Harris : The attached patch fixes the problem. -- components: Library (Lib) files: gzip.patch keywords: patch messages: 123171 nosy: charris44 priority: normal severity: normal status: open title: gzip._PaddedFile calls getattr with arguments in reversed order versions: Python 3.2 Added file: http://bugs.python.org/file19919/gzip.patch ___ Python tracker <http://bugs.python.org/issue10613> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10613] gzip._PaddedFile calls getattr with arguments in reversed order
Charles Harris added the comment: Hi Eric, On Thu, Dec 2, 2010 at 8:12 PM, Ãric Araujo wrote: Where are the guidelines for writing python tests? Chuck -- Added file: http://bugs.python.org/file19921/unnamed ___ Python tracker <http://bugs.python.org/issue10613> ___Hi Eric,On Thu, Dec 2, 2010 at 8:12 PM, Ãric Araujo <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Ãric Araujo <mailto:mer...@netwok.org";>mer...@netwok.org> added the comment: Thanks for the report and patch. Â Can you add a test, to prevent a regression? -- nosy: +eric.araujo stage: Â -> unit test needed type: Â -> behavior versions: +Python 2.7, Python 3.1 Where are the guidelines for writing python tests?Chuck ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10613] gzip._PaddedFile calls getattr with arguments in reversed order
Changes by Charles Harris : Removed file: http://bugs.python.org/file19921/unnamed ___ Python tracker <http://bugs.python.org/issue10613> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10613] gzip._PaddedFile calls getattr with arguments in reversed order
Charles Harris added the comment: Looks like this was fixed by r86555 and a test added. I think you can close the ticket. -- ___ Python tracker <http://bugs.python.org/issue10613> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2212] Cookie.BaseCookie has ambiguous unicode handling
Charles Duffy added the comment: Only the Comment field of a cookie is required by RFC2965 to support Unicode -- and several major browsers either mangle or discard cookies containing even high-ASCII values. Consequently, while some kind of unicode support is appropriate to implement, any program depending on end-to-end support for unicode-encoded cookies is in practice behaving perilously. -- nosy: +char...@dyfis.net ___ Python tracker <http://bugs.python.org/issue2212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included
Changes by Charles Cazabon : Removed file: http://bugs.python.org/file14987/worker-lifetime-python2.6.2.patch ___ Python tracker <http://bugs.python.org/issue6963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included
Charles Cazabon added the comment: No problem, Jesse, I realize you're busy. I've updated the patch very slightly to handle an issue I had where the worker maintainer hung once. -- Added file: http://bugs.python.org/file15940/worker-lifetime-python2.6.2.patch ___ Python tracker <http://bugs.python.org/issue6963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included
Charles Cazabon added the comment: Thanks, Jesse -- it looks good. If there are bugs remaining in the patch, they're mine and not yours. -- ___ Python tracker <http://bugs.python.org/issue6963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7970] email.Generator fails to flatten message parsed by email.Parser
New submission from Charles Cazabon :
email.Generator fails to flatten a message parsed by email.Parser; it throws an
exception with an odd (but apparently legal) message. First, the exception:
File "/usr/local/lib/python2.6/email/generator.py", line 84, in flatten
self._write(msg)
File "/usr/local/lib/python2.6/email/generator.py", line 109, in _write
self._dispatch(msg)
File "/usr/local/lib/python2.6/email/generator.py", line 135, in _dispatch
meth(msg)
File "/usr/local/lib/python2.6/email/generator.py", line 266, in
_handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File "/usr/local/lib/python2.6/email/message.py", line 189, in get_payload
raise TypeError('Expected list, got %s' % type(self._payload))
TypeError: Expected list, got
The oddity of the message its handling is that it's a single-part MIME message,
where the content-type is declared as message/rfc822. Most MUAs, when
forwarding message, create a multipart MIME message with a single attachment
part, and have the attachment be message/rfc822. But Groupwise, when
configured to forward messages to another address (without specifying an
additional text to insert with the forwarded message) creates these slightly
odd messages.
I've not seen them before, but a couple of getmail users have run into this
issue. I've confirmed the problem is the same in Python 2.3, 2.4, 2.5, and
2.6, and I presume it's the same in 2.7 but haven't tested yet.
I'll attach a minimal test script and a datafile which is a minimal message
showing the problem.
--
components: Library (Lib)
files: testcase.py
messages: 99606
nosy: charlesc
severity: normal
status: open
title: email.Generator fails to flatten message parsed by email.Parser
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file16262/testcase.py
___
Python tracker
<http://bugs.python.org/issue7970>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
New submission from Charles Merriam <[EMAIL PROTECTED]>:
About same as problem in 2.4 Issue1470422 closed without a test case on
MacOS X/Python 2.4.
Also same as
http://mail.python.org/pipermail/python-bugs-list/2004-July/024111.html
and so on back for years.
What happens:
[EMAIL PROTECTED]:~/py$ cat x.py
import logging
logging.basicConfig(level=logging.DEBUG,
format="%(levelname)s:%(pathname)s:%(lineno)d:%(message)s")
from logging import debug
if __name__ == "__main__":
debug("Hello")
[EMAIL PROTECTED]:~/py$ python x.py
DEBUG:logging/__init__.py:1327:Hello
What should happen:
It should print DEBUG: x.py:3:Hello
Why it fails:
Because logging guesses that the right sys._getframe(level) should be
level 3 in __init__.py:71, in currentFrame
if hasattr(sys, '_getframe'): currentframe = lambda: sys._getframe(3)
What should happen:
It shouldn't guess. In Python 2.5, the lambda might count. In any
case, the level is off by one (4). I suggest that it get set by walking
up the stack from until it exits the stack frame.
--
components: Library (Lib)
messages: 65743
nosy: CharlesMerriam
severity: normal
status: open
title: Logging Module still failing for %(filename)s, __init__
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2684>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
Charles Merriam <[EMAIL PROTECTED]> added the comment: oops, last line should be "exits the stack frames for the logging module. This should be a once-per-program-execution event" Hmm.. tracker should have a preview button. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2684> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
Charles Merriam <[EMAIL PROTECTED]> added the comment: In my installation, line 1327 is within the logging.debug() function, specifically at the call to apply(root.debug, (msg,)+args, kwargs) [EMAIL PROTECTED]:~/py$ rm *.pyc [EMAIL PROTECTED]:~/py$ python x.py DEBUG:logging/__init__.py:1327:Hello [EMAIL PROTECTED]:~/py$ uname -a Linux chasm-laptop 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux [EMAIL PROTECTED]:~/py$ python -V Python 2.5.1 -and then- [EMAIL PROTECTED]:/usr/lib/python2.5$ sudo rm -rf *.pyc *.pyo */*.pyc */*.pyo */*/*.pyc */*/*.pyo [EMAIL PROTECTED]:/usr/lib/python2.5$ cd ~/py [EMAIL PROTECTED]:~/py$ python x.py DEBUG:x.py:7:Hello [EMAIL PROTECTED]:~/py$ So it was somewhere in the library brunches. The uname -a translates to "Kbuntu Gutsy". Python, and extras like pylint, coverage, and nose, were installed via Kbuntu's package manager. -- Charles On Fri, Apr 25, 2008 at 3:27 AM, Vinay Sajip <[EMAIL PROTECTED]> wrote: > > Vinay Sajip <[EMAIL PROTECTED]> added the comment: > > Can you confirm whether this problem occurs even after deleting all .pyc > and .pyo files, including in the Python library folders and your > application folders? Also, which specific platform is this happening on? > > On your installation, is the line number 1327 the last line in > logging/__init__.py? > > -- > assignee: -> vsajip > nosy: +vsajip > > > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2684> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2684> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2734] 2to3 converts long(itude) argument to int
New submission from Charles McCreary <[EMAIL PROTECTED]>: The 2to3 converter converts variables named "long" to "int". Original: long is an argument (longitude) def add_test_qtrmin(tdb, lat, long, area_id, call_center=""): Converted: def add_test_qtrmin(tdb, lat, int, area_id, call_center=""): I can see what it is trying to do, but I definitely don't want this behavior! -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 66038 nosy: collinwinter, crmccreary severity: normal status: open title: 2to3 converts long(itude) argument to int versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2734> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4840] Compile dbm in Ubuntu
New submission from Charles Hans :
I tried and failed in compile python 3.0 in ubuntu 8.10. Then I found
the scripts in setup.py use "gdbm/ndbm.h" while in ubuntu 8.10 it should
be gdbm-ndbm.h. So I made the following change which make the compiling ok:
setup.py
787c787
< and find_file("gdbm/ndbm.h", inc_dirs, []) is not None):
---
> and find_file("gdbm-ndbm.h", inc_dirs, []) is not None):
790c790
<libraries = ['gdbm'] ) )
---
>libraries = ['gdbm',
'gdbm_compat'] ) )
Modules/_dbmodule.c
22c22
< #include
---
> #include
--
components: Library (Lib)
messages: 79107
nosy: cwhan
severity: normal
status: open
title: Compile dbm in Ubuntu
type: compile error
versions: Python 3.0
___
Python tracker
<http://bugs.python.org/issue4840>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38286] tarfile forgets set sgid when targetpath has it
New submission from Charles Coulombe : An archive that does not have sgid that is extracted in a directory with sgid set does not end up having its sgid set since the targetpath is chmod with the mode of the tarinfo. (Lib/tarfile.py#L2277) For comparison, an archive extracted with tar has the sgid bit set. I added a patch as attachment to gather comments before making this PR. -- components: Library (Lib) files: tarfile_sgid.patch keywords: patch messages: 353305 nosy: Charles Coulombe priority: normal severity: normal status: open title: tarfile forgets set sgid when targetpath has it type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48626/tarfile_sgid.patch ___ Python tracker <https://bugs.python.org/issue38286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38286] tarfile forgets set sgid when targetpath has it
Change by Charles Coulombe : Added file: https://bugs.python.org/file48678/tarfile_sgid.patch ___ Python tracker <https://bugs.python.org/issue38286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38286] tarfile forgets set sgid when targetpath has it
Change by Charles Coulombe : Removed file: https://bugs.python.org/file48626/tarfile_sgid.patch ___ Python tracker <https://bugs.python.org/issue38286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] [Linux] ctypes packs bitfields Incorrectly
Charles Machalow added the comment: Maybe we need to add a __packing__ option to specify how packing should work and default to legacy behavior. Then allow users to specify if they want similar behavior cross-os. Otherwise changing this does change packing for existing users and can lead to breakages. What exactly was the hit regression here? On Sun, Jul 11, 2021, 10:47 AM miss-islington wrote: > > miss-islington added the > comment: > > > New changeset 42da46ed522157b057d73e6b623615ef6427999e by Miss Islington > (bot) in branch '3.10': > bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085) > > https://github.com/python/cpython/commit/42da46ed522157b057d73e6b623615ef6427999e > > > -- > > ___ > Python tracker > <https://bugs.python.org/issue29753> > ___ > -- ___ Python tracker <https://bugs.python.org/issue29753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44600] match/case statements trace incorrectly in 3.10.0b4
Change by Charles Burkland : -- keywords: +patch nosy: +chaburkland nosy_count: 6.0 -> 7.0 pull_requests: +25887 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27346 ___ Python tracker <https://bugs.python.org/issue44600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux
Charles Coulombe added the comment: Any update on this issue? This would be helpful to HPC systems that don't have libraries installed in standard place, and to standardize find_library as well! -- nosy: +Charles Coulombe versions: -Python 3.6 ___ Python tracker <https://bugs.python.org/issue21042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38833] Issue with multiprocessing.Pool & multiprocessing.Queue
New submission from Charles Anderson : When calling mp.Pool().apply_async(), and passing a mp.Queue() instance as an argument the execution halts. This is contrasted by using mp.Manager().Queue() which when passed to apply_async() works as expected. -- components: Library (Lib) files: python_mp_pool_queue_issue.py messages: 356822 nosy: bigbizze priority: normal severity: normal status: open title: Issue with multiprocessing.Pool & multiprocessing.Queue type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48719/python_mp_pool_queue_issue.py ___ Python tracker <https://bugs.python.org/issue38833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39108] Documentation for "random.gauss" vs "random.normalvariate" is lacking
New submission from Charles Newey :
The Python 3 documentation for the "random" module mentions two possible ways
to generate a random variate drawn from a normal distribution - "random.gauss"
and "random.normalvariate" (see:
https://docs.python.org/3/library/random.html#random.gauss).
It's not clear what the distinction is other than apparently the "random.gauss"
function is faster. Digging through the source code, it eventually becomes
apparent that "random.gauss" is NOT thread safe... but this isn't mentioned in
the documentation anywhere.
Further, the documentation doesn't make explicit reference to the particular
method used for generating these Gaussian variates.
Basically what I'm getting at is that it's difficult to tell which function
("gauss" or "randomvariate") I should be using. I feel that the documentation
could be clarified here. I'm happy to do this in a PR at some point if required.
--
assignee: docs@python
components: Documentation
messages: 358703
nosy: cnewey, docs@python
priority: normal
severity: normal
status: open
title: Documentation for "random.gauss" vs "random.normalvariate" is lacking
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39108>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39920] Pathlib path methods do not work with Window Dos devices
New submission from Charles Machalow : I ran the following as admin in the Python interpreter (on Windows): >>> d = pathlib.Path(r'\\.\PHYSICALDRIVE0') >>> print(d) \\.\PHYSICALDRIVE0\ >>> d.exists() Traceback (most recent call last): File "", line 1, in File "C:\Python37\lib\pathlib.py", line 1318, in exists self.stat() File "C:\Python37\lib\pathlib.py", line 1140, in stat return self._accessor.stat(self) PermissionError: [WinError 31] A device attached to the system is not functioning: '.\\PHYSICALDRIVE0\\' >>> d.is_char_device() Traceback (most recent call last): File "", line 1, in File "C:\Python37\lib\pathlib.py", line 1403, in is_char_device return S_ISCHR(self.stat().st_mode) File "C:\Python37\lib\pathlib.py", line 1140, in stat return self._accessor.stat(self) PermissionError: [WinError 31] A device attached to the system is not functioning: '.\\PHYSICALDRIVE0\\' >>> d.is_block_device() Traceback (most recent call last): File "", line 1, in File "C:\Python37\lib\pathlib.py", line 1390, in is_block_device return S_ISBLK(self.stat().st_mode) File "C:\Python37\lib\pathlib.py", line 1140, in stat return self._accessor.stat(self) PermissionError: [WinError 31] A device attached to the system is not functioning: '.\\PHYSICALDRIVE0\\' I think that exists(), is_char_device(), and is_block_device() should be able to work on Windows in some form or fashion. At least without a traceback. -- messages: 363796 nosy: Charles Machalow priority: normal severity: normal status: open title: Pathlib path methods do not work with Window Dos devices type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36144] Dictionary union. (PEP 584)
Change by Charles Burkland : -- nosy: +chaburkland nosy_count: 12.0 -> 13.0 pull_requests: +18266 pull_request: https://github.com/python/cpython/pull/18911 ___ Python tracker <https://bugs.python.org/issue36144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42916] Support for DICOM image file format in imghdr module
New submission from Charles Law : DICOM is a file format used frequently in medical imaging (it is also a communications protocol). It has been used since the 80's, and is still widely used by modern medical equipment. It has a well defined format: http://dicom.nema.org/dicom/2013/output/chtml/part10/chapter_7.html This proposal is for the addiction of a check to imghdr module to detect DICOM files, with imghdr.what() and return 'dicom' if a dicom file is found. -- components: Library (Lib) messages: 384989 nosy: claw priority: normal severity: normal status: open title: Support for DICOM image file format in imghdr module type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43088] Regression in math.hypot
New submission from Charles Karney : It would be nice if math.hypot had the property If 0 < y1 < y2 then math.hypot(x, y1) <= math.hypot(x, y2) This is not the case in python3 with x = 0.6102683302836215 y1 = 0.7906090004346522 y2 = y1 + 1e-16 python2's implementation of math.hypot is OK with these inputs. -- components: Library (Lib) files: hypot_bug.py messages: 386043 nosy: cffk priority: normal severity: normal status: open title: Regression in math.hypot type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49783/hypot_bug.py ___ Python tracker <https://bugs.python.org/issue43088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43088] Regression in math.hypot
Charles Karney added the comment: Many thanks! Was the 3.9 version of hypot introduced in 3.0? I'm fixing my code to call sqrt(x**2 + y**2) if necessary and I'd like to know what range of versions this version should apply for. -- ___ Python tracker <https://bugs.python.org/issue43088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43088] Regression in math.hypot
Charles Karney added the comment: Thanks for the info. -- ___ Python tracker <https://bugs.python.org/issue43088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40972] Add a recurse flag to Path.rmdir()
New submission from Charles Machalow : I think it would make sense to add a recurse flag to the Path.rmdir() method. It would default to False (to allow for current behavior). If set to True, the method would act very similarly to shutil.rmtree() in that it would delete all files in the directory and then delete the directory itself. I understand that this behavior doesn't really line up with os.rmdir(), though I think it makes sense to allow this type of method to appear on the Path object for easy deletion of a directory with things still inside (while looking more object-oriented at the same time) If people think this makes sense, I may be able to provide a PR to just delegate to shutil.rmtree for the recurse=True operation. Thanks for thoughts. -- components: Library (Lib) messages: 371487 nosy: Charles Machalow priority: normal severity: normal status: open title: Add a recurse flag to Path.rmdir() type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33498] pathlib.Path wants an rmtree method
Charles Machalow added the comment: I'm disappointed to see this closed. For new (and old) users, it makes complete sense to have an rmtree method on the Path object itself. If I'm using pathlib, I try not to delegate to os. for file operations, since it also tends to seem more OO and clean to stick with the object methods. Same thought process for shutil for rmtree. We already have things like owner() and group() that explicitly go import grp, pwd to do their job on Path objects. Why is shutil special with regards to using another piece of the standard library from pathlib? To me this request falls in the same boat as those functions; they were likely added for convenience and since it made sense. I believe the very same holds true for the request to add rmtree(). -- nosy: +Charles Machalow ___ Python tracker <https://bugs.python.org/issue33498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41312] add !p to pprint.pformat() in str.format() an f-strings
New submission from Charles Machalow :
Right now in str.format(), we have !s, !r, and !a to allow us to call str(),
repr(), and ascii() respectively on the given expression.
I'm proposing that we add a !p conversion to have pprint.pformat() be called to
convert the given expression to a 'pretty' string.
Calling
```
print(f"My dict: {d!p}")
```
is a lot more concise than:
```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```
We may even be able to have a static attribute stored to change the various
default kwargs of pprint.pformat().
--
components: IO, Library (Lib)
messages: 373738
nosy: Charles Machalow
priority: normal
severity: normal
status: open
title: add !p to pprint.pformat() in str.format() an f-strings
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41312>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41312] add !p to pprint.pformat() in str.format() an f-strings
Charles Machalow added the comment: Fair enough. Didn't really know that list existed. Sent this there. Awaiting moderator approval. Thanks. -- ___ Python tracker <https://bugs.python.org/issue41312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41312] add !p to pprint.pformat() in str.format() an f-strings
Charles Machalow added the comment: One of the key things for ppformat here is to format long spanning dicts/lists to multiple lines, that look easy to read in a log. I feel as though that feature/usefulness outweigh potential indentation weirdness. A lot of the usage would probably be towards the end of an fstring. -- ___ Python tracker <https://bugs.python.org/issue41312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41312] add !p to pprint.pformat() in str.format() an f-strings
Charles Machalow added the comment: In terms of multiple parameters, I propose adding a method to control the defaults used by !p. Though the defaults would work more than well enough for basic log and print usage. -- ___ Python tracker <https://bugs.python.org/issue41312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42178] failed pickle hangs python on exit in CMD.exe only
New submission from Charles McMarrow : This bug only happens for me in Windows 10 when using cmd.exe. This bug does not happen IDLE. It sometimes happens in PowerShell. I ran mp_hang.py with 3.9.0 hangs on cmd/powershell 3.8.6 hangs on cmd 3.8.5 hangs on cmd/powershell Microsoft Windows [Version 10.0.19041.572] 3.8.6 error ``` Traceback (most recent call last): File "", line 1, in File "C:\Users\yoshi\AppData\Local\Programs\Python\Python38\lib\multiprocessing\spawn.py", line 102, in spawn_main source_process = _winapi.OpenProcess( OSError: [WinError 87] The parameter is incorrect ``` -- components: Windows files: mp_hang.py messages: 379803 nosy: charles.mcmarrow.4, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: failed pickle hangs python on exit in CMD.exe only type: crash versions: Python 3.9 Added file: https://bugs.python.org/file49543/mp_hang.py ___ Python tracker <https://bugs.python.org/issue42178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42335] Python Crashes Exception code 0xc0000374 ntdll.dll
New submission from Charles Staton : Hello, I am experiencing crashes of Python 3.8.5 (32 bit) on multiple identical Windows 10 x64 (Enterprise 2016 LTSB) machines. The Crashes are of the sort with the Windows popup "Python has stopped working" and there is no traceback. The crashes occur sporadically. My program might run several days or just an hour, but invariably Python will crash if you wait long enough. I have attached a zip file containing all of the information provided by Windows in Application Logs, as well as some AppVerifier logs. I do not believe the AppVerifier logs are relevant however, as running my program with AppVerifier turned on causes Python to crash immediately upon startup and the information provided by Windows in Application Logs seems to indicate that it's AppVerifier crashing, not Python. My program is quite large and is importing several libraries. It has a PyQt5 GUI, and I'm using PyQt5's QThreadpool() to run several threads concurrently which do various things like: communicate with a web API (rauth, requests), communicate with a PLC (pyModbusTCP), communicate with another PLC (python-Snap7), communicate with an RS485 printer (pySerial), write CSV logs to a network drive, et. al. I'm running this program in a venv setup by PyCharm. The full information is in the attached zip file but here's an excerpt: Faulting application name: python.exe, version: 3.8.5150.1013, time stamp: 0x5f15bc04 Faulting module name: ntdll.dll, version: 10.0.14393.206, time stamp: 0x57dacde1 Exception code: 0xc374 Fault offset: 0x000d9841 Faulting process id: 0x1550 Faulting application start time: 0x01d6b839c684e37d Faulting application path: C:\Users\Administrator\AppData\Local\Programs\Python\Python38-32\python.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 24636ab4-7c06-4cd6-b8f8-4e20bfc59dce Googling various clues has given me a vague clue that this is caused by Python attempting to access memory that it shouldn't. I have no idea how that happens or why. I'm clueless as to how I should go about troubleshooting this. If anyone can help I will be very grateful. -- components: Interpreter Core, Library (Lib), ctypes files: Python Crash Data.zip messages: 380847 nosy: strantor priority: normal severity: normal status: open title: Python Crashes Exception code 0xc374 ntdll.dll versions: Python 3.8 Added file: https://bugs.python.org/file49594/Python Crash Data.zip ___ Python tracker <https://bugs.python.org/issue42335> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42335] Python Crashes Exception code 0xc0000374 ntdll.dll
Charles Staton added the comment: I'm closing this. I have done a lot of research that seems to point to the way I'm handling threads as the cause, not Python itself. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42335> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
New submission from Charles Wohlganger: Sorry, I'm new to this, and I've done it out of order. Commit #2306 covers the following: In IDLE, parenmatch extension: Add highlighting left and right parens to styles. Make flash-delay setting independent of parens highlighting style. Currently, the flash-delay option only affects one of the two styles, but there is no good reason for it not to affect both. -- assignee: terry.reedy components: IDLE messages: 296554 nosy: terry.reedy, wohlganger priority: normal severity: normal status: open title: IDLE parenmatch - left and right highlighting, independent flash-delay type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Changes by Charles Wohlganger : -- pull_requests: +2362 ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Changes by Charles Wohlganger : -- pull_requests: -2362 ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Changes by Charles Wohlganger : -- pull_requests: +2363 ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Changes by Charles Wohlganger : -- pull_requests: +2366 ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Charles Wohlganger added the comment: There are two changes: First - The flash-delay option is for how until the parens that are highlighted will stop highlighting. The flash-delay option for the ParenMatch only affects the 'default' style. Similarly the 'expressions' style does not use the flash-delay option and will not stop highlighting until input is given to IDLE. Desired behavior is for the flash-delay option to work for both styles, and setting flash-delay to 0 will cause the input required behavior that is currently only used by the 'expressions' style. I couldn't find anything in the test suite for testing the delay behavior specific to styles, only that the timer works in general, so I'm not sure how to test it other than just observing it. The test did not seem to cover if 'default' style worked properly using the 'show surrounding parens' command. I have added that to all style tests. Second - There is no style for highlighting the opening and closing parens. The new behavior is to write 'parens' (without ticks) for the style option, apply/ok the options, restart IDLE, and make a statement with parens, and it highlights both parens. The uploaded parenmatch test file covers the parens style, ensuring it works correctly. -- Added file: http://bugs.python.org/file46967/test_parenmatch.py ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29910] Ctrl-D eats a character on IDLE
Changes by Charles Wohlganger : -- pull_requests: +2504 ___ Python tracker <http://bugs.python.org/issue29910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30723] IDLE parenmatch - left and right highlighting, independent flash-delay
Charles Wohlganger added the comment: 'opener' sounds fine to me. I agree it makes much more sense than 'default'. I don't know much about Emacs, and couldn't find what their parens highlighting styles were. I can't think of anything sensible that isn't in this extension with this enhancement; apart from highlighting whenever the cursor is beside a parens. -- ___ Python tracker <http://bugs.python.org/issue30723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
New submission from Charles Wohlganger: Current IDLE parenmatch highlighting uses the 'hilite' style when highlighting the parens/expression. Desired behavior is to use a user-setting based style that is independent from the hilite style (which is used for highlighting selected text). Desired selectable options are for foreground color, background color, underlining and font (which covers font type, size, bold, and italics) Apart from running IDLE and checking that the selections match, I don't know how to test. Testing would need a human to check for correct colors, etc. if it was made, so it couldn't be automated... -- assignee: terry.reedy components: IDLE messages: 297317 nosy: terry.reedy, wohlganger priority: normal severity: normal status: open title: IDLE parenmatch - highlighting options type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Changes by Charles Wohlganger : -- pull_requests: +2554 ___ Python tracker <http://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Charles Wohlganger added the comment: The pull request has been changed to only have the theme element able to be selected. #22705 hasn't had activity in a few years. Is there something I can do to move it along? -- ___ Python tracker <http://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Charles Wohlganger added the comment: Implimenting #27099 seems the more reasonable solution to me, so I'll work on that when I have free time. -- ___ Python tracker <http://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Progress Update: I've moved all of the basic functionality of the extensions into the regular parts of IDLE, including menus and keyboard shortcuts. parenmatch and codecontext have all of their settings now in the Highlighting settings tab. I have added theme elements for both, as that was both easier and more in-line with what the rest of the IDLE settings were doing than trying to have a separate color-picker for them. The attached image is what it looks like. What is left for me to do: add the configuration dialogs and proper setting saving for the remaining extensions/modules. Change help texts. Once the configdialog changes patch (#30779) goes through, I will of course, need to fix anything both touch, but that shouldn't be too difficult. -- nosy: +wohlganger Added file: http://bugs.python.org/file46996/2017-07-07 13_58_45-Settings.png ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Charles Wohlganger added the comment: I've rolled pretty much all this was going to do, other than underlining and font work into #27099. Trying to bring parenmatch into main otherwise would have been just as much of a hassle. -- ___ Python tracker <http://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Changes by Charles Wohlganger : -- pull_requests: +2718 ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Pull request won't pass build test, but passes the full idle test on my workstation. Primary cause seems to be: ImportError: cannot import name 'EditorWindow' from 'idlelib.editor' I can also import EditorWindow by itself on my workstation. None of the changes to EditorWindow seem like they should be causing this error. Any ideas? -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Thank you, Cheryl Sabella. I think I've found which tests I've missed running. Now to fix all the bugs... -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Pull Request is passing build tests. Please check for pushing to master at your convenience. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9262] IDLE: Use tabbed shell and edit windows
Charles Wohlganger added the comment: I modified Mark Rosen's newTabExtension to work with more recent versions of IDLE, as it wasn't working when I tried it on mine. It's not clear if it ever could when it was originally working, but I can't get it to move tabs between multiple window instances. -- nosy: +wohlganger Added file: http://bugs.python.org/file47011/TabExtension.py ___ Python tracker <http://bugs.python.org/issue9262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Charles Wohlganger added the comment: I've written an extension (see file) that does auto insertion of closing parens, brackets, braces, ticks, and quotes. It also (optionally) skips the closers when they are typed right next to the already exiting one. It also takes into account triple-ticks / triple-quotes. -- nosy: +wohlganger Added file: http://bugs.python.org/file47021/ParenClose.py ___ Python tracker <http://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Charles Wohlganger added the comment: I (foolishly) was committing to master for a different IDLE enhancement. Until that one is pulled, I don't think I can make a new PR without it also having all the changes from my previous one. New uploaded file has docstrings for the ParenClose class and I've run and fixed it against pep8 until it gave no errors. Namespaces should conform to PEP8, apart from the module name, which must match the class name due to how IDLE works with extensions. -- Added file: http://bugs.python.org/file47023/ParenClose.py ___ Python tracker <http://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Changes to master have introduced tests with hardcoded values for what extensions are expected to be loaded by IDLE. Given that this patch turn all current extensions into mainlined modules, none of them are loaded as extensions and all of the related tests fail. What should I do about this? -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Menus items were placed where they appeared as extensions. It would be no difficulty for me to move them around. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Changes by Charles Wohlganger : Added file: http://bugs.python.org/file47029/test_parenclose.py ___ Python tracker <http://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Charles Wohlganger added the comment: I've uploaded a test file and updated ParenClose. -- Added file: http://bugs.python.org/file47030/ParenClose.py ___ Python tracker <http://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Changes by Charles Wohlganger : Added file: http://bugs.python.org/file47031/test_parenclose.py ___ Python tracker <http://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Charles Machalow added the comment: Was browsing and found this. This option would be very useful as it could help avoid a current bug I've had to deal with : https://bugs.python.org/issue29753. My use case works with data/structs from another device all-together, so I can't control it's packing. However since GCC/Linux builds currently have the specified bug, I can't get around it. This option would have allowed me to just specify the MSVC strategy, which in general is what I want to not have to have OS-specific behavior. With the bug in mind, this could have almost be a bug-workaround for me. -- nosy: +Charles Machalow ___ Python tracker <http://bugs.python.org/issue12528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: The patch moves all config variables to config-main, config-highlight (for highlight colors), and config-keys (for keys). Keys and highlights are configurable in their respective tabs. Parens and Code Context options are in the Highlighting tab, Format Paragraph configurables are in the General tab. The sections in the main.def file where the options are saved are respective to their tab. If you want, I can change the modules so they also load from their old location if an overriding option isn't found in main.def . However, I would recommend cleanly breaking from the old extensions, with a notice somewhere of where the new options are. Changing the behavior of the extensions Tab / System is a separate issue that I think would be best handled after this, as this patch already makes a lot of changes. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: Unfortunately, it looks like config deletes settings for extensions when they are not found - which is what will happen with this patch. One solution would be to have separate config files for 2 and 3. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31021] Clarify programming faq.
Charles Wohlganger added the comment: Modulo is defined mathematically as the remainder of Euclidian division. I.E. a positive r where a % b = r is equivalent to a = b * x + r. I think it confuses the issue to say "-190 % 12 were the mathematical equivalent -10", when that is technically incorrect. Computer modulo uses truncated division, which is why -a % b != a % -b. "... compilers that truncate i // j need to make i % j have the same sign as i." i % j has the same sign as j, not i. I believe that is the typo that has caused the confusion. I would replace the last line with : "-190 % 12 == -10 is wrong according to the C definition for computer modulo arithmetic." -- nosy: +wohlganger ___ Python tracker <http://bugs.python.org/issue31021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31111] Python 3.6 has an inaccessible attribute on FileNotFoundError
New submission from Charles Ferguson:
Whilst debugging a problem in some of my code (which turned out to be a
misspelt filename), I found that I could not access one of the properties of
the FileNotFoundError object.
Essentially, if you get a 'FileNotFoundError' for opening a file that does not
exist, you expect to be able to enumerate the attributes on that object. And if
you try to access them, that they be accessible.
However, there is an attribute - 'characters_written' - which claims to be
present according to 'dir()' but not according to 'hasattr()' and trying to
access it with 'getattr()' confirms that it's not really there.
Looking at the documentation at
https://docs.python.org/3/library/exceptions.html#OSError I see that it is a
subclass of OSError(), and that the BlockingIOError can have this attribute.
But none of the other OSError subclasses are documented as having the attribute.
It is still reasonable that any attribute access could generate another
exception (including an AttributeError), as their implementation may have other
issues, but I do not feel that this applies here, as this is an internal
exception object that probably ought not to have an issue.
Since 'characters_written' doesn't seem to have any meaning in the context of
'FileNotFound', it seems like it's an oversight from the other exception
subclass.
What I conclude from this is that the documentation, hasattr() and getattr()
are correct, but dir() is acting wrongly. Principle of least surprise also
suggests that having inconsistent returns from these functions probably isn't
correct. I guess it could be the other way around, and the documentation,
hasattr and getattr could be returning incorrectly, but that feels like
something of a stretch.
I would wonder if the other OSError subclasses also suffer from this extraneous
attribute name, and that it's been implemented at the wrong level, but I have
no evidence to suggest that's the case (just that that's something I'd probably
look at if I had the time).
Reproduction code:
#!/usr/bin/python3.6
##
# Demonstrate oddity of FileNotFoundError.
#
try:
fh = open('/nothing/at/all', 'r')
except Exception as ex:
print("Exception: {}".format(ex))
for attrname in dir(ex):
if attrname.startswith('__'):
# Ignore dunders for the sake of brevity
continue
print(" Attribute name: {}".format(attrname))
if not hasattr(ex, attrname):
print(" hasattr: False - surprising!")
print(" value: {}".format(getattr(ex, attrname)))
On 3.6 this generates:
Charles@charlesmbp:~/Coding/terraspock-develop (develop)$ python
python3.6.2-filenotfound.py
Exception: [Errno 2] No such file or directory: '/nothing/at/all'
Attribute name: args
value: (2, 'No such file or directory')
Attribute name: characters_written
hasattr: False - surprising!
Traceback (most recent call last):
File "python3.6.2-filenotfound.py", line 7, in
fh = open('/nothing/at/all', 'r')
FileNotFoundError: [Errno 2] No such file or directory: '/nothing/at/all'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "python3.6.2-filenotfound.py", line 18, in
print(" value: {}".format(getattr(ex, attrname)))
AttributeError: characters_written
On 2.7 this works fine, but I've not tested the other 3.x series versions as I
don't have them to hand.
Testing performed on macOS using Python 3.6.2.
I find it hard to think that this is intended behaviour, but whether it's
something that debugging tools (and users) would expect or find useful I don't
know.
--
components: Library (Lib)
messages: 299669
nosy: gerph
priority: normal
severity: normal
status: open
title: Python 3.6 has an inaccessible attribute on FileNotFoundError
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue3>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: I am not sure I understand your concern. As part of mainlining the extensions, all of their keybindings were moved to config-keys.def . There is nothing to prevent users from changing the keybindings or preventing us from making the defaults different across the different default key sets. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27099] IDLE: turn builting extensions into regular modules
Charles Wohlganger added the comment: ZoomHeight has been put back into being an extension. This was because configdialog assumes autoexpand was an extension, and the idleconf tests all need at least one extension to exist to be useful. Zoomheight is pointless in almost any modern desktop environment, but it's very useful as an example extension and as a model extension for tests. I'm going to fix autocomplete and paragraph options. I had their options in the general tab in an earlier build, but it looks like I accidentally reverted it. The rest of the options are in the highlights tab. The bell was in the extension before I got to it. Fixing that and whatever bugs are in codecontext seems outside the scope of this patch. -- ___ Python tracker <http://bugs.python.org/issue27099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20580] IDLE should support platform-specific default config defaults
Changes by Charles Wohlganger : -- pull_requests: +3253 ___ Python tracker <http://bugs.python.org/issue20580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Changes by Charles Wohlganger : -- keywords: +patch pull_requests: +3517 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Changes by Charles Wohlganger : -- keywords: +patch pull_requests: +3565 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30809] IDLE parenmatch - highlighting options
Changes by Charles Wohlganger : -- pull_requests: -2554 ___ Python tracker <https://bugs.python.org/issue30809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces
Charles Wohlganger added the comment: The PR contains all the requested features, as well as mutual deletion (requested on PR page), and I have separated out the options for mutual deletion triggered by delete or triggered by backspace. I've found in usage that it was irritating to have both, but nice to only have one. Let users pick one, both, or none. -- ___ Python tracker <https://bugs.python.org/issue18875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Incorrectly - Linux
New submission from Charles Machalow:
There appears to be a bug related to sizing/packing of ctypes Structures on
Linux. I'm not quite sure how, but this structure:
class MyStructure(Structure):
_pack_ = 1
_fields_= [
("P", c_uint16),# 2 Bytes
("L", c_uint16, 9),
("Pro", c_uint16, 1),
("G", c_uint16, 1),
("IB", c_uint16, 1),
("IR", c_uint16, 1),
("R", c_uint16, 3), # 4 Bytes
("T", c_uint32, 10),
("C", c_uint32, 20),
("R2", c_uint32, 2) # 8 Bytes
]
Gives back a sizeof of 8 on Windows and 10 on Linux. The inconsistency makes it
difficult to have code work cross-platform.
Running the given test.py file will print out the size of the structure on your
platform.
Tested with Python 2.7.6 and Python 3.4.3 (builtin to Ubuntu 14.04), Python
2.7.13, (built from source) both on Ubuntu 14.04. On Linux all Python builds
were 32 bit.
On Windows I tried with 2.7.7 (both 32 and 64 bit).
I believe on both platforms it should return a sizeof 8.
--
components: ctypes
files: test.py
messages: 289193
nosy: Charles Machalow, amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
status: open
title: Ctypes Packing Incorrectly - Linux
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file46708/test.py
___
Python tracker
<http://bugs.python.org/issue29753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Incorrectly - Linux
Charles Machalow added the comment:
Took a quick look at the c code for this. The area at fault appears to be this
section in cfield.c:
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8 >= *pfield_size
&& (*pbitofs + bitsize) <= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif
The problem seems to be after the end of the 2nd c_uint16, it seems to think
that the next 10 bytes should extend that c_uint16 to a c_uint32 instead of
taking the type as the beginning of a new c_uint32. So I guess it is making the
structure something like this:
("P", c_uint16),
("L", c_uint32, 9),
("Pro", c_uint32, 1),
("G", c_uint32, 1),
("IB", c_uint32, 1),
("IR", c_uint32, 1),
("R", c_uint32, 3),
("T", c_uint32, 10),
# And now this needs an extra 6 bits of padding to fill
the c_uint32
("C", c_uint32, 20),
("R2", c_uint32, 2)
# And now this needs an extra 10 bits of padding to fill
the c_uint32.
I guess that is how we get to 10... instead of the expected 8 bytes. I don't
believe that this behavior is desired nor really makes logical sense.
--
___
Python tracker
<http://bugs.python.org/issue29753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Incorrectly - Linux
Charles Machalow added the comment:
Some more debug with print statements in the c code seems to confirm my
suspicion:
bitsize, pfield_size, bitofs, dict->size prints were added just above the if
chain to determine fieldtype and fieldtype was just after that if chain. That
code looks something like this:
printf("bitsize: %d\n" , (int)bitsize);
printf("pfield_size: %u\n", (size_t)*pfield_size);
printf("bitofs: %d\n", (int)*pbitofs);
printf("dict->size: %d\n", (int)dict->size);
if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
/* MSVC, GCC with -mms-bitfields */
&& dict->size * 8 == *pfield_size
#else
/* GCC */
&& dict->size * 8 <= *pfield_size
#endif
&& (*pbitofs + bitsize) <= *pfield_size) {
/* continue bit field */
fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8 >= *pfield_size
&& (*pbitofs + bitsize) <= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif
} else if (bitsize) {
/* start new bitfield */
fieldtype = NEW_BITFIELD;
*pbitofs = 0;
*pfield_size = dict->size * 8;
} else {
/* not a bit field */
fieldtype = NO_BITFIELD;
*pbitofs = 0;
*pfield_size = 0;
}
printf("Fieldtype: %d\n--\n", fieldtype);
And the run with the custom-built Python 2.7.13:
>>> from test import *
bitsize: 0
pfield_size: 0
bitofs: 255918304
dict->size: 2
Fieldtype: 0
--
bitsize: 9
pfield_size: 0
bitofs: 0
dict->size: 2
Fieldtype: 1
--
bitsize: 1
pfield_size: 16
bitofs: 9
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 10
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 11
dict->size: 2
Fieldtype: 2
--
bitsize: 1
pfield_size: 16
bitofs: 12
dict->size: 2
Fieldtype: 2
--
bitsize: 3
pfield_size: 16
bitofs: 13
dict->size: 2
Fieldtype: 2
--
bitsize: 10
pfield_size: 16
bitofs: 16
dict->size: 4
Fieldtype: 3
--
bitsize: 20
pfield_size: 32
bitofs: 26
dict->size: 4
Fieldtype: 1
--
bitsize: 2
pfield_size: 32
bitofs: 20
dict->size: 4
Fieldtype: 2
--
10
>>> MyStructure.P
>>> MyStructure.T
>>> MyStructure.R
>>> MyStructure.P
>>> MyStructure.L
>>> MyStructure.Pro
>>> MyStructure.R
>>> MyStructure.T
>>> MyStructure.C
--
___
Python tracker
<http://bugs.python.org/issue29753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30018] multiprocessing.Pool garbles call stack for __new__
New submission from Charles McEachern:
I'm calling the constructor of Foo, a subclass of str. Expected output:
Called Foo.__new__ with args = ('TIMESTAMP', 'INPUT0')
TIMESTAMP OUTPUT0
When I make the call using a multiprocessing.pool.ThreadPool, it works fine.
But when I make the call using a multiprocessing.Pool (using the apply or
apply_async method), I get:
Called Foo.__new__ with args = ('TIMESTAMP', 'INPUT0')
Called Foo.__new__ with args = ('TIMESTAMP OUTPUT0',)
Exception in thread Thread-3:
...
ValueError: Bad Foo input: ('TIMESTAMP OUTPUT0',)
That is, the object I just constructed seems to be getting shoved right back
into the constructor.
When I swap out the Foo class for the similar Goo class, which is not a str,
and uses __init__ instead of __new__, I again see no problems:
Called Goo.__init__ with args = ('TIMESTAMP', 'INPUT0')
I see this in 2.7.9 as well as 3.4.5. Looks like it's present in 2.7.2 and
3.5.2 as well:
https://github.com/charles-uno/python-new-pool-bug/issues/1
--
components: Library (Lib)
files: newpool.py
messages: 291278
nosy: Charles McEachern
priority: normal
severity: normal
status: open
title: multiprocessing.Pool garbles call stack for __new__
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file46790/newpool.py
___
Python tracker
<http://bugs.python.org/issue30018>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30018] multiprocessing.Pool garbles call stack for __new__
Charles McEachern added the comment: This caused me several hours of misery yesterday, trying to isolate what was going wrong. I am unfortunately not at liberty to share the code I'm working on. The example on GitHub has the general thrust of it: my constructor was always called in a specific way, and didn't expect to be given something that was already processed. Interesting to see that this is a product of pickling. That makes me think that "fixing" this corner case would probably be a lot of work. I suppose I should just work around it by checking right away if the input to my constructor has already been constructed! -- ___ Python tracker <http://bugs.python.org/issue30018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30018] multiprocessing.Pool garbles call stack for __new__
Charles McEachern added the comment: That seems to do it! Looks like the trick is to define __reduce__ to help out the serializer. Thanks! -- ___ Python tracker <http://bugs.python.org/issue30018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30161] Using `with` statement causes dict to start papering over attribute errors
New submission from Charles Cazabon:
This is a weird one. I've reproduced it with 3 versions of 2.7, including the
latest 2.7.13. I didn't find an open bug about this, but I had difficulty
crafting a search string for it, so I may have missed something.
Basically, using a `with` statement (maybe any such statement, but using an
open file definitely does it, even when I do nothing with it) causes the
built-in dict class to stop raising AttributeErrors, which can result in odd
bugs.
Example:
Python 2.7.13 (default, Apr 25 2017, 10:12:36)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> with sys.stderr as foo:
... pass
...
>>> {}.nosuchattribute
>>> {}.nosuchattribute is None
>>>
I haven't tried the latest 3.x, but it's definitely still there in 3.2.3:
Python 3.2.3 (default, Nov 17 2016, 01:04:00)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> with sys.stderr as foo:
... pass
...
>>> {}.nosuchattribute
>>> {}.nosuchattribute is None
>>>
--
components: Interpreter Core
messages: 292270
nosy: charlesc
priority: normal
severity: normal
status: open
title: Using `with` statement causes dict to start papering over attribute
errors
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue30161>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30161] Using `with` statement causes dict to start papering over attribute errors
Charles Cazabon added the comment: oh ffs ;) -- ___ Python tracker <http://bugs.python.org/issue30161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
