[issue35990] ipaddress.IPv4Interface won't accept 2-tuple (address, mask)
Jack added the comment: confirmed in 3.7.3 -- nosy: +Jacktose ___ Python tracker <https://bugs.python.org/issue35990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27860] Improvements to ipaddress module
Change by Jack : -- nosy: +Jacktose ___ Python tracker <https://bugs.python.org/issue27860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27860] Improvements to ipaddress module
Jack added the comment: I for one have encountered #35990 in my work and would appreciate a backport. -- ___ Python tracker <https://bugs.python.org/issue27860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26226] Test failures with non-ascii character in hostname on Windows
Jack added the comment: Python not working.. -- nosy: +Jack01 ___ Python tracker <https://bugs.python.org/issue26226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
New submission from Jack: Currently using the package we can only define emails in the 'TO' as shown here: https://docs.python.org/2/library/email-examples.html#email-examples There is no support for email to be sent as CC or BCC which is useful quality in many emails. Please see if this can be added. -- messages: 289291 nosy: Nonickname priority: normal severity: normal status: open title: An email and MIME handling package - Add support to send CC of email type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
Jack added the comment: But this is what I mean.. It shouldn't be arbitrary. When you define CC you want him as CC not as another one in the TO. This is why I said this is enhancement request. -- ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
Changes by Jack : -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
Jack added the comment: I think you missundersttod. I showed the example page just so you would understand what I am talking about. Let me explain it better: msg['Subject'] = 'The contents of %s' % textfile msg['From'] = me msg['To'] = you Works. msg['Subject'] = 'The contents of %s' % textfile msg['From'] = me msg['To'] = you msg['CC'] = x msg['BCC'] = y won't work. It doesn't know what is CC and BCC. This is why I opened this request to modify the package to support it. -- ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
Jack added the comment: Please see the stack overflow question: http://stackoverflow.com/questions/42696100/python-smtp-send-email-with-cc -- ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29771] An email and MIME handling package - Add support to send CC of email
Jack added the comment: "I'm on the fence about including this in the examples." Think of it this way.. Including it in the docs would have prevented this question. It can be just a side note it doesn't have to be a whole example. Thx. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue29771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under "optional arguments"
Jack added the comment: I'd like to note that this also happens with a required mutually exclusive group: group = parser.add_mutually_exclusive_group(required=True) The arguments in the group are listed under “optional arguments:”. I'm guessing the mechanism is the same. -- nosy: +Jacktose ___ Python tracker <https://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
New submission from jack: I just installed Python 3.4.3 on a 32-bit machine, 2 GB memory, Win XP SP3. When I try to start IDLE, pythonw.exe appears briefly in the Windows Task Manager, then disappears, and nothing else happens. If I run just python.exe in a command window, that runs OK. The same behavior happens after installing version 2.7.10. This happens for both of these versions, regardless of whether the other one is installed or not. The same also happened for version 3.1.2. On the other hand, version 2.5 runs just fine. I tried all this also in Windows Safe Mode, where there were only about half a dozen core Windows processes in the task manager, with the same result. -- components: IDLE messages: 248593 nosy: jack priority: normal severity: normal status: open title: Python start type: crash versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue24868> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
jack added the comment: Thanks a lot for the tip. This revealed that Python 3.4.3 was looking for tcl from Python 2.2 on my machine. That version had been on my machine more than 10 years ago, but was no longer there. It had left behind a whole bunch of registry crumbs, which I removed. I then uninstalled all the versions on my machine and reinstalled 3.4.3. That did the trick. The question is, why would installing 3.4.3 or other versions be contaminated by stuff from another version, especially an ancient one? Jack On 8/14/2015 8:49 PM, Terry J. Reedy wrote: > Terry J. Reedy added the comment: > > For 3.4.3, run 'python -m idlelib' in the command window and you should see > some error message. But first run 'python' and at the>>> prompt, 'import > tkinter' to see if tkinter is working properly. > > -- > nosy: +terry.reedy > > ___ > Python tracker > <http://bugs.python.org/issue24868> > ___ > -- ___ Python tracker <http://bugs.python.org/issue24868> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24868] Python start
jack added the comment: If you zap all existing traces of Python and tcl it would affect users who need to run multiple versions. I would suggest completely encapsulating each version and all its dependencies, in order to avoid mutual interference. On 8/15/2015 2:55 PM, Steve Dower wrote: > Steve Dower added the comment: > > Actually, that's a pretty good idea (I'd certainly use it), though it would > come with a big fat warning sign. I'll add an issue for it. > > Whether it would fix this particular issue is unclear. I suspect this one is > due to environment variables (TCL_LIBRARY overrides tkinter's regular search) > which could not be aggressively cleaned up on uninstall. I have no idea > whether older installers used to set that environment variable, but recent > 2.7 and 3.5 don't. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue24868> > ___ > -- ___ Python tracker <http://bugs.python.org/issue24868> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Update: There is now a C version of the `blake3` Python module available at https://github.com/oconnor663/blake3-py/tree/master/c_impl. It's completely API-compatible with the Rust version, and it passes the same test suite. Multithreading (which is implemented in upstream Rust but not in upstream C) is exposed through a "max_threads" argument, as Larry Hastings suggested. The C implementation allows this argument but ignores it. Unlike my previous attempt, this setup.py build handles the full range of target platforms and optimized flavors: x86-64 assembly on Windows-MSVC and Unix, 32-bit x86 intrinsics on Windows-MSVC and Unix, NEON intrinsics on AArch64, and portable C for everyone else. I'm new to distutils/setuptools and not particular familiar with the MSVC toolchain either, so there's a good chance that others can suggest better/cleaner/more robust approaches than what I've got, but it's at least working on my machines and on GitHub CI. (I haven't tried to get any cross-compilation working though; is that a thing?) I haven't published this module to PyPI, partly to avoid confusion with the Rust-based implementation, which I think most applications should prefer. But if it would make a big difference to anyone who wants to review this code, we could certainly put it up as `experimental_blake3_c` or something? Let me know what's best. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Ah, good idea. I've published the new C implementation as: https://test.pypi.org/project/blake3-experimental-c/ You can install it with: pip install -i https://test.pypi.org/simple/ blake3-experimental-c Despite the package name change, the extension module is still "blake3", so we still "import blake3" to get at it. For example: $ pip install -i https://test.pypi.org/simple/ blake3-experimental-c $ python >>> from blake3 import blake3 >>> blake3(b"foo").hexdigest() '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a7502e9' >>> blake3(b"foo", max_threads=blake3.AUTO).hexdigest() '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a7502e9' To run the Rust implementation's test suite against this implementation, you could then: $ pip install pytest numpy $ git clone https://github.com/oconnor663/blake3-py $ python -m pytest blake3-py/tests/test_blake3.py = test session starts = platform linux -- Python 3.10.1, pytest-6.2.5, py-1.11.0, pluggy-0.13.1 rootdir: /tmp collected 24 items blake3-py/tests/test_blake3.py [100%] = 24 passed in 0.30s == -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment:
I was about to say the only missing feature was docstrings, but then I realized
I hadn't included releasing the GIL. I've added that and pushed an update just
now. Fingers crossed there's nothing else I've missed. I think it's in
reasonably good shape, and I'd like to propose it for inclusion in 3.11.
However, I'm not very experienced with setup.py or the Python C API, so I might
not be the best judge of shape. Here are some highlights for reviewers, where I
think the implementation (mostly the build) could be shaky:
- Platform detection. In setup.py I assume that the target platform of the
build is the same as the current interpreter's platform. So for example, if the
current interpreter has sys.maxsize==2**31-1, I assume we're compiling for
32-bit. This clearly doesn't allow for any sort of cross-compilation, and in
general I need feedback about whether there's a more correct way to obtain the
target platform.
- Compiling assembly files. On Unix this is easy, because we can supply *.S
files as `extra_objects` and GCC/Clang will do the right thing. But on Windows
this isn't easy. Currently I shell out to vswhere.exe, ask it for the path to
the latest version of the ml64.exe assembler, and then shell out to that to
build .obj files. Then I pass those assembled .obj files as `extra_objects`.
This feels awfully manual, and there's a good chance I've missed some
better-supported way to do it. I assume we don't want to check in the .obj
files?
- Does Python support the GNU ABI on Windows? We have assembly files for this
in vendor/, but I'm not currently building them.
- Compiling intrinsics files for 32-bit x86. In this case, I create a
`ccompiler.new_compiler()` for each intrinsics file, so that I can set the
appropriate flags for each. This is relatively clean, but it leads to things
getting rebuilt every single time, rather than participating in `setup.py
build` caching. Maybe nobody cares about this, but again it makes me think
there might be a better-supported way to do it.
- blake3module.c contains an awful lot of gotos to handle allocation failure
cases. Is this still considered a best practice? These are bug-prone, and I'm
not sure how to test them.
- Existing hashlib implementations include an optimization where they avoid
allocating an internal mutex until they see a long input and want to release
the GIL. As a quirky side effect of this, they handle allocation failures for
that mutex by falling back to the do-not-release-the-GIL codepath. That feels
kind of complicated to me, and in my code I'm always allocating the mutex
during initialization. This doesn't seem to make much of a performance
difference when I measure it, but there might be use cases I haven't considered.
Here are some other API details that might be worth bikeshedding:
- The `max_threads` parameter is currently defined to take a special value,
`blake3.AUTO`, to indicate that the implementation may use as many threads as
it likes. (The C implementation doesn't include multithreading support, but
it's API-compatible with the Rust implementation.) `blake3.AUTO` is currently a
class attribute equal to -1. We may want to bikeshed this name or propose some
other representation.
- BLAKE3 has three modes: regular hashing, keyed hashing, and key derivation.
The keyed hashing mode takes a 32-byte key, and the key derivation mode takes a
context string. Calling the 32-byte key `key` seems good. Calling the context
string `context` seems less good. Larry has pointed out before that lots of
random things are called `context`, and readers might not understand what
they're seeing. I currently call it `derive_key_context` instead, but we could
bikeshed this.
- I check `itemsize` on input Py_buffers and throw an exception if it's
anything other than 1. My test suite exercises this, see
`test_int_array_fails`. However, some (all?) standard hashes don't do this
check. For example:
>>> from hashlib import sha256
>>> import array
>>> a = array.array("i", [255])
>>> sha256(a).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'
>>> sha256(bytes([0xff, 0, 0, 0])).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'
Here we can see sha256() hashing an array of int. On my machine, an int is 4
little-endian bytes, but of course this sort of thing isn't portable. The same
array will result in a different SHA-256 output on a big-endian machine, or on
a machine with ints of a different size. This seems undesirable, and I'm
surprised that hashlib allows it. However, if there's some
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > As a first pass I say we merge the reference C implementation. Do you mean portable-only C code, or portable + intrinsics? If the assembly files are out, I'd advocate for the latter. The intrinsics implementations are nearly as fast as the assembly code, and both of those are several times faster than the portable code. You can test this configuration with my current setup.py by setting the env var FORCE_INTRINSICS=1. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Yeah by intrinsics I mean stuff like _mm256_add_epi32(). All of that stuff is in these vendored files: blake3_avx2.c blake3_avx512.c blake3_neon.c blake3_sse2.c blake3_sse41.c Also to Michał's question above, I'm not necessarily opposed to publishing something like "blake3-c" on PyPI once things stabilize. Even if we get BLAKE3 into hashlib in 3.11, PyPI modules will be useful to folks running older versions, and not everyone wants to install the Rust toolchain. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
New submission from Jack Nguyen : I noticed that the set.issubset cpython implementation casts its iterable argument to a set. In some cases, casting the whole iterable to a set is unnecessary (see https://bugs.python.org/issue18032). Although the latter suggestion is to perform early termination, my suggestion is to use the intersection instead. # PyAnySet_Check coming from the cpython source code. def issubset(self, other): # Intersection suggestion: if not PyAnySet_Check(other): return len(self.intersection(other)) == len(self) # Usual implementation for sets. else: return ... The main advantage that this implementation has is its memory performance, using only O(min(len(self), len(other))) memory, since it never stores elements it does not need. I'm assuming that set construction costs O(n) set.__contains__ calls. This implementation uses len(other) calls to self.__contains__ and tmp.__contains__, where tmp = set(other). The current implementation uses len(self) + len(other) calls to tmp.__contains__. Thus, I suspect the current implementation only has a chance at running noticeably faster when len(self) << len(other), where it performs fewer calls to set.__contains__. This is, however, also where the proposed implementation has significantly superior memory performance. -- components: Interpreter Core messages: 412966 nosy: panda1200 priority: normal severity: normal status: open title: Memory optimization for set.issubset type: performance versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Jack Nguyen added the comment: As you say, which implementation performs better likely depends on the nature of the sets. I would suspect that using set.difference won't be substantially faster than using set.intersection in the best case, but it would be much slower if len(self) is much larger than len(self.intersection(other)) e.g. set(range(1_000_000)).issubset(range(10)). Overall I think that using set.intersection will have more well-rounded performance. -- ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Jack Nguyen : -- keywords: +patch pull_requests: +29432 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31267 ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: What's the best way for me to help with the next steps of this? -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Yes, everything in https://github.com/BLAKE3-team/BLAKE3 and https://github.com/oconnor663/blake3-py is public domain via CC0, and dual licensed under Apache for good measure. Hopefully that makes it easy to use it anywhere. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Thanks Larry! Was any of the experimental C extension code under https://github.com/oconnor663/blake3-py/tree/master/c_impl useful to you? I was wondering if it could be possible to copy blake3module.c from there verbatim. The setup.py build there also has working Windows and NEON support. I've patched the blake3-py test suite (which both the production Rust-based extension and that experimental C-based extension currently pass) to invoke the new hashlib implementation from your branch. You can find the full test output, and the procedure I used to run the tests, in this Gist https://gist.github.com/oconnor663/533048580b1c0f4a01d1d55f57f92792. Here are some differences: - My derive_key_context parameter requires a string and refuses to accept bytes. This is consistent with our Rust and C APIs (though the C API does include a _raw version specifically for bindings, which we're using here). For a long discussion of why we prefer to do things this way, see https://github.com/BLAKE3-team/BLAKE3/issues/13. The short version is that any use case that requires arbitrary bytes for the context string is almost certainly violating the documented security requirement that the context string must be hardcoded. - I've included an `AUTO` constant that provides a special value (-1) for the `max_threads` argument, and I explicitly don't support `max_threads=0`. - I enforce that the `data` arguments are positional-only and that the other keyword arguments are keyword-only. I think this is consistent with the rest of hashlib. - I include a `.reset()` method. This isn't particularly useful in the default case, where you might as well create a new hasher. But when `max_threads` is greater than 1 in the Rust implementation, the hasher owns a thread pool, and `.reset()` is currently the only way to reuse that pool. (A BLAKE3 hasher is also ~2 KB, somewhat larger than other hashers, so callers who are pinching pennies with their allocator traffic might prefer to reuse the object.) - Unrelated to tests: I haven't made any attempt to zero memory in my `dealloc` function. But if that's what other hashlib functions do, then I'm certainly in favor of doing it here too. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1523] xdrlib fails to detect overflow (struct bug?)
New submission from Jack Lloyd:
The XDR format requires integers to fit into 4 byte values. However (at
least on x86-64) xdrlib will silently accept (and truncate) values
larger than this (up to 2**64-1). Taking a (very brief) look at the
xdrlib code, it appears this is actually a problem in the struct module,
but I don't have the time (or interest) to trace through the _struct
module code.
An example on an x86-64 machine (Python 2.4.3) of encoding 2**32 (which
will not fit in an XDR field) being silently truncated:
$ ./xdr.py
4294967296 -> -> 0
An example of struct itself not detecting overflow:
>>> struct.pack("!I", 2**32)
'\x00\x00\x00\x00'
struct.pack will only throw an overflow error if a value >= 2**64 is
used, even if it is encoding into a field that is much smaller.
--
components: Extension Modules
files: xdr.py
messages: 57939
nosy: lloyd
severity: normal
status: open
title: xdrlib fails to detect overflow (struct bug?)
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file8825/xdr.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1523>
__
xdr.py
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12272] Python 2.7.1 version conflict for package "Tcl" on Windows 7
New submission from Jack Eisenbach :
I wrote a Tkinter application that runs fine with Python 2.6.5 and 2.6.6 on a
Windows 7 (32-bit version) machine. The same app fails with 2.7.1. Below is the
debug output:
c:\ISS\ledmatrix>led-display.py
Traceback (most recent call last):
File "ledmatrix.py", line 2263, in
LEDMatrix()
File "ledmatrix.py", line 1427, in LEDMatrix
root = Tk()
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1643, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive,
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
{C:\Python27\tcl\tcl8.5} C:/Python26/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5
C:/library C:/library C:/tcl8.5.8/library C:/tcl8.5.8/library
C:/Python27/tcl/tcl8.5/init.tcl: version conflict for package "Tcl": have
8.5.8, need exactly 8.5.2
version conflict for package "Tcl": have 8.5.8, need exactly 8.5.2
while executing
"package require -exact Tcl 8.5.2"
(file "C:/Python27/tcl/tcl8.5/init.tcl" line 20)
invoked from within
"source C:/Python27/tcl/tcl8.5/init.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
--
components: Tkinter
messages: 137778
nosy: jackie3
priority: normal
severity: normal
status: open
title: Python 2.7.1 version conflict for package "Tcl" on Windows 7
type: crash
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12272>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7761] telnetlib Telnet.interact fails on Windows but not Linux
Jack Diederich added the comment: Thanks David, do you want to apply? Looks good to me. -- ___ Python tracker <http://bugs.python.org/issue7761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10176] telnetlib.Telnet.read_very_eager() performance
Jack Diederich added the comment: There was no test suite for telnetlib prior to 2.7/3.1 so it is easily possible that this is a regression. If you can post a test case that fails or - even better - a patch that passes where the current code fails I'd be very appreciative. -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue10176> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10245] Fix resource warnings in test_telnetlib
Changes by Jack Diederich : -- assignee: -> jackdied nosy: +jackdied versions: +Python 3.2 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue10245> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
New submission from Jack Jansen : Because VC++ cannot cross-link modules that have been built with debugging to those built without debugging (because of runtime system differences) it would be a boon for people embedding Python if there was a binary distribution of the DLL (and .lib) available that was built with debugging turned on. Right now, to build a debugging version of an application that has Python embedded you must also build Python from source... -- components: Build, Windows messages: 131934 nosy: jackjansen priority: normal severity: normal status: open title: Debug builds for Windows would be very helpful type: feature request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen added the comment: Sorry, I think I wasn't clear in my original message. I don't want to debug Python, I want to debug only my own code. But because it embeds Python I cannot debug my own code, because it needs to link to Python. Indeed, if it was only Python itself I would have build from source it would not be so much of an issue, but there's all the external stuff... Brian: if you have a reference I can check the reasoning. -- ___ Python tracker <http://bugs.python.org/issue11656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen added the comment: Martin, I agree about the Py_DEBUG issue. My reason for asking is really only a workaround for the VC++ problam that you can't link non-debug and debug builds together. You know what: if you think it isn't worth it just assign it to me and I'll try to go the extra step of doing the work and providing a patch. -- ___ Python tracker <http://bugs.python.org/issue11656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen added the comment: Martin, what I meant by "linking debug and non-debug builds together is impossible" is "you cannot link modules together if they code generation has been set to different runtime systems, for example one module using the debug runtime system and another using the non-debug runtime system". But: let's cut this short, if this isn't worth the extra load on the release manager then it isn't worth pursuing. I did the work for myself (and co-developers, more importantly) but then I won't try and shape things up for more general consumption. -- ___ Python tracker <http://bugs.python.org/issue11656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11812] transient test_telnetlib failure
Changes by Jack Diederich : -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue11812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] can cmd.py's API/docs for the use of an alternate stdin be improved?
Jack Andrews added the comment: hi guys, this makes Cmd a bit more useful. my use case is talking to pdb via pipe (ie. subprocess module). pdb doesn't behave very well if stdin is not a tty. === --- cmdpy.orig/cmd.py 2011-04-14 23:55:01.102867999 +1000 +++ cmdpy/cmd.py2011-04-14 23:55:16.272868002 +1000 @@ -92,6 +92,8 @@ self.stdin = stdin else: self.stdin = sys.stdin +if not stdin.isatty(): +self.use_rawinput = 0 if stdout is not None: self.stdout = stdout -- nosy: +Jack.Andrews ___ Python tracker <http://bugs.python.org/issue2571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] can cmd.py's API/docs for the use of an alternate stdin be improved?
Jack Andrews added the comment: > Terry J. Reedy added the comment: > > Jack, several questions. > Are you saying that when stdin is a pipe and not a tty, pdb works better with > use_rawinput set False? yes. well, at least i thought so. today, pdb works fine with no patch. i must have stumbled across my bug in the middle of patching cmd.py. if i notice anything strange, i'll let you know. -- ___ Python tracker <http://bugs.python.org/issue2571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich <[EMAIL PROTECTED]> added the comment: Thanks for the ping. I just rewrote the patch from scratch and it handles corner cases (of which there are many in the parse tree) better. I'll upload/checkin sometime today. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich <[EMAIL PROTECTED]> added the comment: The new patch works and handles all the corner cases I could think of. I tried to comment the heck out of it because it does a lot of manual walking and manipulation of the syntax tree. This only handles __metaclass__ inside classes. I wasn't sure what to do with __metaclass__ at the module level (which is now a NOP, I think). Added file: http://bugs.python.org/file11020/fix_metaclass.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2260] conditional jump to a POP_TOP optimization
Jack Diederich <[EMAIL PROTECTED]> added the comment: +0 * The peepholer comment promises "Optimizations are restricted to simple transformations occuring within a single basic block." and this goes beyond that. You could patch that comment. * This needs a matching patch to Lib/test/test_peepholer.py * Deeply nested "if"s suffer a flat penalty because the unconditional jump peepholer figures this out after the first extra POP_TOP (notice the JUMP_ABSOLUTE in your second disassembly). * I noticed the NOP assignment is commented out in your patch, was that unsafe? I searched for old threads on the peephole optimizer and came up with these: Skip Montanaro's paper http://www.webfast.com/~skip/python/spam7/optimizer.html Two old python-dev threads http://www.gossamer-threads.com/lists/python/dev/645669 http://www.gossamer-threads.com/lists/python/dev/645669 I was hoping to find out if writing a bytecode optimizer in python had been discussed because a generic version of your optimization would be really easy to write in pure python (using a dict for the jump table, for instance). I found nothing; my search terms might have been insufficient. -- nosy: +jackdied ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2260> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2676] email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input
Jack Diederich <[EMAIL PROTECTED]> added the comment: Augmented version of Daniel's patch. This makes an internal function that does the same work. It uses txt.find() instead of split() or partition() because for pathologically long strings find() is noticeably faster. It also does the strip() before the lower() which helps with evilly long strings. I didn't remove the module global "paramre" because an external module might be using it. I did update its comment. Do bugfixes get applied to 2.6 or 3.0? I'm a bit out of practice. -- nosy: +jackdied Added file: http://bugs.python.org/file11022/email.message.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2676> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2688] Error when nesting many while loops
Jack Diederich <[EMAIL PROTECTED]> added the comment: This was fixed in more recent versions of 2.5, it now raises a "SystemError: too many statically nested blocks" Thanks for the tip Guilherme. Marking closed. -- nosy: +jackdied resolution: -> out of date status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2935] rfc822.py line 395 strings connection
Jack Diederich <[EMAIL PROTECTED]> added the comment: This is a bug in the external ClientCookie module (and their website hasn't been updated since 2006). Marking closed. -- nosy: +jackdied resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3228] mailbox.mbox creates files with execute bit set
Jack Diederich <[EMAIL PROTECTED]> added the comment: mailbox.py uses os.open instead of the builtin open() because it wants to pass the exclusive flag (O_EXCL). As a result your 0077 umask gets combined with the default of 0777 like this: 0777 & ~0077 == 0700 == '-rwx--' So you probably want to change your default umask when creating mailboxes. Or submit a patch to mailbox.py to allow a different default mode ;) -- nosy: +jackdied ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2951] ElementTree parsing bus error (but only from mod_python)
Jack Diederich <[EMAIL PROTECTED]> added the comment: It is a common apache problem. Elementree imports an expat parser (presumably cElementree doesn't) and different versions of expat play together very poorly. Lots of apache modules load one xml lib version or another and they tend to step on each others toes .. and then segfault. IIRC the only way to resolve this is to figure out which loaded apache modules are using expat and recompile them all against the same version. Not fun. -- nosy: +jackdied resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2951> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2676] email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input
Jack Diederich <[EMAIL PROTECTED]> added the comment: Antoine, I looked at your patch and I'm not sure why you applied it instead of applying mine (or saying +1 on me applying my patch). Yours uses str.partition which I pointed out is sub-optimal (same big-Oh but with a larger constant factor) and also adds a function that returns two things, one of which is thrown away after having a str.strip performed on it. If my patch was deficient please let me know. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2676> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich <[EMAIL PROTECTED]> added the comment: Benjamin, the 2to3 parse tree straddles the 2.x Grammar and 3.x Grammar (it's its own thing) which is why fixup_parse_tree is there. From the docstring: one-line classes don't get a suite in the parse tree so we add one to normalize the tree The 2to3 parser is very line oriented - only the try/except logic uses blocks (I think). There haven't been any objection so I've assigned this to myself and I'll check it in and close it soonish. -- assignee: collinwinter -> jackdied ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
Jack Diederich added the comment:
I'm having some trouble wrapping my head around this one. It isn't obvious to
me that
my_method(*args):
print(args)
class A():
meth = partial(my_method, 'argA')
ob = A()
ob.meth('argB')
should print (, 'argA', 'argB') and not
('argA', , 'argB')
The patch seems to prefer the first form but if you are using a partial
shouldn't you expect 'argA' to always be the first argument to the partial-ized
function?
--
___
Python tracker
<http://bugs.python.org/issue4331>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX
Jack Diederich added the comment: -1, my Ubuntu laptop says "linux2" and not "ubuntu." This would also be an incompatible change that would cause headaches with little benefit to balance it out. -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue7850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7646] test_telnetlib fails in Windows XP
Jack Diederich added the comment: I was mistaken, the tests were backported to 3.1.x maint (In fact I was the one who did it). So this is fixed in the next point release of 3.1.x. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue7646> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7463] PyDateTime_IMPORT() causes compiler warnings
Jack Diederich added the comment: changing the definition to (const char *) seems like the right thing to do - a quick grep of the Python source and a search on google codesearch only shows uses with either string literals or string literals cast to (char *) in order to silence a warning. I tried changing it on the 2.x trunk and it compiles with no warnings. +1, any other opinions? -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue7463> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7366] weakref module example relies on behaviour not guaranteed by id()
Jack Diederich added the comment: This is true but /any/ key in the WeakValueDictionary could be reused and result in similar behavior, not just the id() of the inserted value. I'm closing at "won't fix" -- nosy: +jackdied resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue7366> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7196] Clarify str.split() behavior
Jack Diederich added the comment:
I suggest this be closed WONTFIX. The str.split() documentation accurately
describes str.split() but doesn't happen to do what the OP wanted which was
list(filter(None, '00010001'.split('0')))
Instead split(sep) is the reciprocal of sep.join(), that is
txt == sep.join(txt.split(sep))
--
nosy: +jackdied
___
Python tracker
<http://bugs.python.org/issue7196>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6886] cgi.py runs python, not python3
Jack Diederich added the comment: +0 I'm ambivalent. The script uses a reasonable default and pyhton3 is a reasonable default for the 3k branch. That said most people will have to edit the file anyway to use it: I had to chmod a+x the file and change the bang path to /usr/bin/python to get it to work on my machine. -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue6886> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6931] dreadful performance in difflib: ndiff and HtmlDiff
Jack Diederich added the comment: Here is a profile run of the 200 line case, run on the 3.x trunk, and with all the trivial functions removed. quick_ratio and __contains__ dominate the time. The process was CPU bound, memory usage stayed low. 17083154 function calls (17066360 primitive calls) in 248.779 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 10660375 70.5160.000 70.5160.000 :0(__contains__) 1144821.0480.0001.0480.000 :0(append) 4434776 29.2540.000 29.2540.000 :0(get) 685047/6850424.4000.0004.4000.000 :0(len) 1973491.5120.0001.5120.000 :0(min) 1971331.4520.0001.4520.000 difflib.py:228(set_seq1) 25001.6320.0013.0920.001 difflib.py:299(__chain_b) 10822.5200.0024.7680.004 difflib.py:350(find_longest_match) 3391432.5800.0002.5800.000 difflib.py:40(_calculate_ratio) 141727 120.5990.001 220.9700.002 difflib.py:661(quick_ratio) 1967366.9560.000 12.5490.000 difflib.py:690(real_quick_ratio) 8974/7945.0520.001 248.4310.313 difflib.py:945(_fancy_replace) -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue6931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6825] Minor documentation bug with os.path.split
Jack Diederich added the comment: how about "an equivalent path" instead of "equal path"? The result of ntpath.join(ntpath.split(path)) should point to the same location even if it isn't literally the same string. -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue6825> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6518] Enable 'with' statement in ossaudiodev module
Jack Diederich added the comment: +1, the C patch looks good to me. The test file needs a new test that checks the 'with' behavior. Also, what changed so that the test now needs to ignore AttributeErrors in play_sound_file()? -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue6518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
Jack Diederich added the comment: We talked about it at sprints and the semantics are ambiguous and there are alternatives. Ambiguous: def show_funcs(*args): print(args) class A(): run = partial(1) ob = A() ob.run(2,3) Should this print (self, 1, 2, 3) or (1, self, 2, 3)? And what about partial(ob.run, 2)(3) Alternatives: partial is a convenience function not an optimization (it doesn't offer a speedup. So you can write a lambda or named function that has the exact semantics you want without suffering a speed penalty. So unless there are a lot of good use cases with obvious behavior, we should refuse the temptation to guess and leave partial as-is. -- ___ Python tracker <http://bugs.python.org/issue4331> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
Jack Diederich added the comment: correction: run = partial(1) should have been run = partial(show_funcs, 1) -- ___ Python tracker <http://bugs.python.org/issue4331> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Jack Diederich added the comment: I've been digging into the patch. Is there a reason sendmsg() wants an iterable of buffers instead of just accepting a str? The list-of-buffers more closely matches the underlying syscall but I'm not sure what the python benefit is, especially when recvmsg() only returns a single value (it only creates 1 iovec under the covers). Python doesn't have "readv" like methods so making sendmsg/recvmsg work like recv/send (straight strings) seems like the way to go. Also, the "y*" format character for packing/unpacking tuples is no longer supported - I'm assuming it used to mean buffers. Does anyone have a good reference for using recvmsg/sendmsg? I read the man pages and googled around but couldn't find anything. I have no experience with using the calls in-the-wild. -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Jack Diederich added the comment: Additional data point: the perl version takes a single scalar (instead of a list of scalars) for use with sendmsg() http://search.cpan.org/~MJP/Socket-MsgHdr-0.01/MsgHdr.pm -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Jack Diederich added the comment: one of the other sprinters just pointed out that Modules/_multiprocessing.c (py3k branch) uses sendmsg/recvmsg internally to pass file descriptors back and forth. The code is very short and readable. -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6091] Curses segfaulting in FreeBSD/amd64
Jack Miller added the comment: The rest of my codebase is currently only 2.x compatible, but I saw identical symptoms about a month ago on Fedora/Mandriva when their 2.x packages were linked against non-widechar libraries so I imagine that is indeed the solution. I'll close the bug when I can either wrap the code for 3.x or get a 2.x FreeBSD build with those changes. Thanks! -- ___ Python tracker <http://bugs.python.org/issue6091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8708] OpenID blunder
New submission from Jack Diederich : I tried logging into the tracker using my gmail login and accidentally created a new user. Could someone either wipe out the OpenID for jackd...@gmail.com (but NOT the "jackdied" login with email addy of jackd...@gmail.com) or combine the two? In the end I just reset my password and logged in as the original "jackdied" TIA, -Jack -- messages: 105672 nosy: Jack.Diederich priority: normal severity: normal status: open title: OpenID blunder ___ Python tracker <http://bugs.python.org/issue8708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8707] Duplicated document in telnetlib.
Changes by Jack Diederich : -- assignee: d...@python -> jackdied nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue8707> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8708] OpenID blunder
Jack Diederich added the comment: Woops, didn't know that email would create a new bug. -- nosy: +jackdied ___ Python tracker <http://bugs.python.org/issue8708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1636] Execfile unable to take arguments beyond 255!
New submission from Jack Atkinson: I found this problem while using PySNMP and trying to load a custom MIB converted to python code. Inside the PySNMP, it uses execfile() to load the python MIBs, and I assume so it won't be put into a separate namespace. On one particular MIB, which I cannot modify because it's a company product MIB, this error of unable to take in more than 255 arguments occurs. The problem line is quite long, but surely in this day and age of 32 bit to 64 bit machines this 255 constraint could be done away with in the execfile function. I'm assuming the 255 constraint has something to do with unsigned 8 bit number. -- components: Interpreter Core messages: 58668 nosy: jgatkinsn severity: normal status: open title: Execfile unable to take arguments beyond 255! type: rfe versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1636> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1636] Execfile unable to take arguments beyond 255!
Jack Atkinson added the comment:
Error message from ipython console:
In [28]: mibBuilder2 = builder.MibBuilder().loadModules('ADTRAN-TC')
---
Traceback (most recent call last)
C:\Documents and Settings\Jack Atkinson\ in ()
c:\python25\lib\site-packages\pysnmp\v4\smi\builder.py in
loadModules(self, *mod
Names)
80 del self.__modPathsSeen[modPath]
81 raise error.SmiError(
---> 82 'MIB module \"%s\" load error: %s' %
(modPath, why)
83 )
84
: MIB module
"c:\python25\lib\site-packages\p
ysnmp\v4\smi\mibs\ADTRAN-TC.py" load error: more than 255 arguments
(ADTRAN-TC.p
y, line 33)
Here's the code that loads it:
try:
execfile(modPath, g)
except StandardError,
why: del self.__modPathsSeen[modPath]
raise error.SmiError( 'MIB module \"%s\" load error: %s' % (modPath, why) )
Added file: http://bugs.python.org/file8968/builder.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1636>
__# MIB modules loader
import os
from pysnmp.smi import error
try:
import pysnmp_mibs
except ImportError:
pysnmp_mibs = None
from pysnmp import debug
class MibBuilder:
def __init__(self):
self.lastBuildId = self._autoName = 0L
paths = (
os.path.join(os.path.split(error.__file__)[0], 'mibs','instances'),
os.path.join(os.path.split(error.__file__)[0], 'mibs')
)
if os.environ.has_key('PYSNMP_MIB_DIR'):
paths = paths + (
os.path.join(os.path.split(os.environ['PYSNMP_MIB_DIR'])[0]),
)
if pysnmp_mibs:
paths = paths + (
os.path.join(os.path.split(pysnmp_mibs.__file__)[0]),
)
self.mibSymbols = {}
self.__modSeen = {}
self.__modPathsSeen = {}
apply(self.setMibPath, paths)
# MIB modules management
def setMibPath(self, *mibPaths):
self.__mibPaths = map(os.path.normpath, mibPaths)
debug.logger & debug.flagBld and debug.logger('setMibPath: new MIB path
%s' % (self.__mibPaths,))
def getMibPath(self): return tuple(self.__mibPaths)
def loadModules(self, *modNames):
# Build a list of available modules
if not modNames:
modNames = {}
for mibPath in self.__mibPaths:
try:
for modName in os.listdir(mibPath):
if modName == '__init__.py' or modName[-3:] != '.py':
continue
modNames[modName[:-3]] = None
except OSError:
continue
modNames = modNames.keys()
if not modNames:
raise error.SmiError(
'No MIB module to load at %s' % (self,)
)
for modName in modNames:
for mibPath in self.__mibPaths:
modPath = os.path.join(
mibPath, modName + '.py'
)
debug.logger & debug.flagBld and debug.logger('loadModules:
trying %s' % modPath)
try:
open(modPath).close()
except IOError, why:
debug.logger & debug.flagBld and debug.logger('loadModules:
open() %s' % why)
continue
if self.__modPathsSeen.has_key(modPath):
debug.logger & debug.flagBld and debug.logger('loadModules:
seen %s' % modPath)
continue
else:
self.__modPathsSeen[modPath] = 1
g = { 'mibBuilder': self }
try:
execfile(modPath, g)
except StandardError, why:
del self.__modPathsSeen[modPath]
raise error.SmiError(
'MIB module \"%s\" load error: %s' % (modPath, why)
)
self.__modSeen[modName] = modPath
debug.logger & debug.flagBld and debug.logger('loadModules:
loaded %s' % modPath)
break
if not self.__modSeen.has_key(modName):
raise error.SmiError(
'MIB file \"%s.py\" not found in search path' % modName
)
return self
def unloadModules(self, *modNames):
if not modNames:
modNames = self.mibSymbols.keys()
for modName in modNames:
if not self
[issue2328] Class **kwds broken (PEP 3115)
New submission from Jack Diederich <[EMAIL PROTECTED]>: typeobject.c:type_new only allows 0 or 1 keyword arg in class creation instead of an arbitrary number as per PEP3115. I'm working on a patch. -- assignee: jackdied components: Interpreter Core messages: 63681 nosy: jackdied priority: normal severity: normal status: open title: Class **kwds broken (PEP 3115) type: behavior versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2328] Class **kwds broken (PEP 3115)
Jack Diederich <[EMAIL PROTECTED]> added the comment: Not a bug. If you pass arbitrary keywords in class construction you have to define __new__ and __init__ on the metaclass to handle them. -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Changes by Jack Diederich <[EMAIL PROTECTED]>: -- nosy: +jackdied __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2346] Py3K warn against using __members__
Jack Diederich <[EMAIL PROTECTED]> added the comment: This patch raises a py3k warning from inside the dir() machinery so it will only warn when dir() is called on an object with an old style __members__ or __methods__ attribute. It does not warn if there is an old style __members__ attribute that is not used. -- assignee: -> jackdied keywords: +patch nosy: +jackdied Added file: http://bugs.python.org/file9768/methods_members.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2346> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning
Jack Diederich <[EMAIL PROTECTED]> added the comment: Fixer patch works for me (both must be applied). A 3k warning for accessing is harder - it would have to copy the module type or dict type and supply a custom to_getattro that watches for accesses to exc_(type|values|traceback). I'll look into it. -- nosy: +jackdied __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2357> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich <[EMAIL PROTECTED]> added the comment: Here is a partial implementation. It doesn't warn about __metaclass__ at the module level and doesn't handle multiple __metaclass__ assignements in one class. tests pending. -- keywords: +patch Added file: http://bugs.python.org/file9778/fix_metaclass.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2366] Fixer for new metaclass syntax is needed
Jack Diederich <[EMAIL PROTECTED]> added the comment: New patch that does more. Collin, could you take a look at the fixer? I listed some stumbling blocks at the top (and at least one bug in 2to3). The fixer seems to work fine on actual files but the unit tests that use strings do nothing. Thanks. Added file: http://bugs.python.org/file9797/fix_metaclass.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2366> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning
Jack Diederich <[EMAIL PROTECTED]> added the comment: +1, I'll burn my _apply_evil(ModuleObject *) function patch to moduleobject.c which did a memcpy on a type object and several other heresies. On Tue, Mar 25, 2008 at 4:27 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Brett Cannon <[EMAIL PROTECTED]> added the comment: > > I agree with Georg; a 2to3 fixer is enough. > > > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2357> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2357> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > maintaining a complicated build process in-tree For what it's worth, if you have any sort of "in a perfect world" vision for what the upstream BLAKE3 project could do to make it trivially easy for you to integrate, I'd be very interested in getting that done. Making integration easy would benefit all callers. We have some issues on the backburner about committing CMake build files, but I assume those would be useless for us here. Is there anything that would be more useful? If we provided autotools build files, could you call into them? Fundamentally, BLAKE3 wants to build some code on x86 and some other code on ARM, and also some code on Unix and some other code on Windows. Currently we just ask the caller to do that for us, for lack of a common standard. (And if we're building intrinsics rather than assembly, we also need the compiler flags that enable our intrinsics.) But maybe we could handle more of that upstream, using the preprocessor? If the build instructions said "compile this one giant file on all platforms and don't worry about what it does", would that be better? Or would that be gross? Is a header-only library the gold standard? Or too C++-ish? Has anyone ever done a really good job of this? -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > Hardware accelerated SHAs are likely faster than blake3 single core. Surprisingly, they're not. Here's a quick measurement on my recent ThinkPad laptop (64 KiB of input, single-threaded, TurboBoost left on), which supports both AVX-512 and the SHA extensions: OpenSSL SHA-256: 1816 MB/s OpenSSL SHA-1: 2103 MB/s BLAKE3 SSE2: 2109 MB/s BLAKE3 SSE4.1: 2474 MB/s BLAKE3 AVX2: 4898 MB/s BLAKE3 AVX-512: 8754 MB/s The main reason SHA-1 and SHA-256 don't do better is that they're fundamentally serial algorithms. Hardware acceleration can speed up a single instance of their compression functions, but there's just no way for it to run more than one instance per message at a time. In contrast, AES-CTR can easily parallelize its blocks, and hardware accelerated AES does beat BLAKE3. > And certainly more efficient in terms of watt-secs/byte. I don't have any experience measuring power myself, so take this with a grain of salt: I think the difference in throughput shown above is large enough that, even accounting for the famously high power draw of AVX-512, BLAKE3 comes out ahead in terms of energy/byte. Probably not on ARM though. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > Truncated sha512 (sha512-256) typically performs 40% faster than sha256 on > X86_64. Without hardware acceleration, yes. But because SHA-NI includes only SHA-1 and SHA-256, and not SHA-512, it's no longer a level playing field. OpenSSL's SHA-512 and SHA-512/256 both get about 797 MB/s on my machine. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: I did reply to that point above with some baseless speculation, but now I can back up my baseless speculation with unscientific data :) https://gist.github.com/oconnor663/aed7016c9dbe5507510fc50faceaaa07 According to whatever `powerstat -R` measures on my laptop, running hardware-accelerated SHA-256 in a loop for a minute or so takes 26.86 Watts on average. Doing the same with AVX-512 BLAKE3 takes 29.53 Watts, 10% more. Factoring in the 4.69x difference in throughput reported by those loops, the overall energy/byte for BLAKE3 is 4.27x lower than SHA-256. This is my first time running a power benchmark, so if this sounds implausible hopefully someone can catch my mistakes. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32658] Metacharacter (\) documentation suggestion
Jack DeVries added the comment: Did you run ``make venv`` to setup your virtual environment? Sphynx themes are usually pip dependencies, so if you're getting a "missing theme" error, it sounds like your virtual environment is not setup right. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38668] Update os.path documentation regarding recommended types
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +30304 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32232 ___ Python tracker <https://bugs.python.org/issue38668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38411] SQLITE_MISUSE race condition in sqlite3 is misleadingly raised as a binding error
New submission from Jack Robison :
There is a race condition in the sqlite3 module that is misleadingly raised as
sqlite3.InterfaceError('Error binding parameter 0 - probably unsupported type.')
There are two issues here, one is the incorrectly raise error
(https://bugs.python.org/issue16379), the other is the underlying SQLITE_MISUSE
caused by the race condition. I believe this is a race between sqlite3 vs
python garbage collection due to the releasing of the GIL. If the GIL releasing
is removed from sqlite3, I cannot reproduce the race.
Here is a script to reproduce the error, as the number of runners or
queries_per_executemany is increased the error happens more frequently. The
minimal test case only needs two executemanys where each has two queries to run.
import asyncio
import sqlite3
from concurrent.futures.thread import ThreadPoolExecutor
async def misuse_sqlite(runners=2, queries_per_executemany=2):
loop = asyncio.get_event_loop()
expected_error = 'Error binding parameter 0 - probably unsupported type.'
exceptions = []
executor = ThreadPoolExecutor(1)
db = executor.submit(sqlite3.connect, ':memory:',
isolation_level=None).result()
executor.submit(db.executescript, "create table test (id text primary
key);")
def query_in_executor():
return asyncio.wrap_future(executor.submit(executemany))
def executemany():
try:
return db.executemany("select * from test where id=?", ((str(i),)
for i in range(queries_per_executemany)))
except Exception as err:
exceptions.append(err)
for _ in range(runners):
loop.call_soon(query_in_executor)
await asyncio.sleep(0.01)
assert all(str(err) == expected_error and isinstance(err,
sqlite3.InterfaceError) for err in exceptions)
executor.submit(db.close).result()
executor.shutdown()
return len(exceptions) > 0
attempts = 0
while True:
attempts += 1
if asyncio.run(misuse_sqlite()):
print('error hit on attempt', attempts)
break
--
components: Library (Lib)
messages: 354218
nosy: Jack Robison
priority: normal
severity: normal
status: open
title: SQLITE_MISUSE race condition in sqlite3 is misleadingly raised as a
binding error
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue38411>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38411] SQLITE_MISUSE race condition in sqlite3 is misleadingly raised as a binding error
Change by Jack Robison : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue38411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11588] Add "necessarily inclusive" groups to argparse
Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker <https://bugs.python.org/issue11588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: An update a year later: I have a proof-of-concept branch that adds BLAKE3 support to hashlib: https://github.com/oconnor663/cpython/tree/blake3. That branch is API compatible with the current master branch of https://github.com/oconnor663/blake3-py. Both that module and the upstream BLAKE3 repo are ready to be tagged 1.0, just waiting to see whether any integrations like this one end up requesting changes. Would anyone be interested in moving ahead with this? One of the open questions would be whether CPython would vendor the BLAKE3 optimized assembly files, or whether we'd prefer to stick to C intrinsics. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Hey Christian, yes these are new bindings, and also incomplete. See comments in https://github.com/oconnor663/cpython/commit/dc6f6163ad9754c9ad53e9e3f3613ca3891a77ba, but in short only x86-64 Unix is in working order. If 3.10 doesn't seem realistic, I'm happy to go the PyPI route. That said, this is my first time using the Python C API. (My code in that branch is going to make that pretty obvious.) Could you recommend any existing packages that I might be able to use as a model? For OpenSSL, I'm very interested in the abstract but less familiar with their project and their schedules. Who might be a good person to get in touch with? > I assume there's a completely generic platform-agnostic C implementation, for > build environments where the assembly won't work, yes? Yes, that's the vendored file blake3_portable.c. One TODO for my branch here is convincing the Python build system not to try to compile the x86-64-specific stuff on other platforms. The vendored file blake3_dispatch.c abstracts over all the different implementations and takes care of #ifdef'ing platform-specific function calls. (It also does runtime CPU feature detection on x86.) > written using the Rust implementation, which I understand is even more > performant A few details here: The upstream Rust and C implementations have been matched in single threaded performance for a while now. They share the same assembly files, and the rest is a direct port. The big difference is that Rust also includes multithreading support, using the Rayon work-stealing runtime. The blake3-py module based on the Rust crate exposes this with a simple boolean flag, though we've been thinking about ways to give the caller more control over the number of threads used. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44347] Unclear documentation for shutil.copytree()
Jack DeVries added the comment: I would like to submit a patch for this. This would be my first contribution :) I am starting on a patch now. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44347] Unclear documentation for shutil.copytree()
Change by Jack DeVries : -- keywords: +patch pull_requests: +25220 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26634 ___ Python tracker <https://bugs.python.org/issue44347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44347] Unclear documentation for shutil.copytree()
Jack DeVries added the comment: I've created a PR: https://github.com/python/cpython/pull/26634 I forgot to put a news entry, but hopefully that's ok since this is a very small change. -- ___ Python tracker <https://bugs.python.org/issue44347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44362] improve documentation of SSL deprecations
Jack DeVries added the comment: These changes are part of PEP 644; support for OpenSSL v1.1.1. The benefits are detailed in `the PEP <https://www.python.org/dev/peps/pep-0644/#benefits>`_. Later, the deprecation process began in `bpo-43880 <https://bugs.python.org/issue43880>`_. It seems like `PROTOCOL_TLS` is the only thing with a deprecation warning that does not have a suggested alternative. I'm confused as to how this can be deprecated; what will be the new mechanism for selecting a protocol? If someone can provide some brief clarification, I'd be more than happy to update the docs! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44347] Unclear documentation for shutil.copytree()
Change by Jack DeVries : -- pull_requests: +25229 pull_request: https://github.com/python/cpython/pull/26643 ___ Python tracker <https://bugs.python.org/issue44347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44362] improve documentation of SSL deprecations
Jack DeVries added the comment: Would you like me to submit a PR for this simple patch? https://github.com/jdevries3133/cpython/commit/42d9bd7f97f03b49d4fc89780616704998492ac1 -- ___ Python tracker <https://bugs.python.org/issue44362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44387] Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
Jack DeVries added the comment: Could it be that _locale throws an ImportError whenever LC_MESSAGES doesn't exist? Then, there are fall-backs defined here: https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L45-L85 -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44387] Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
Jack DeVries added the comment: Follow-up: nope! My hypothesis was incorrect. This is all that _localemodule.c has to say about LC_MESSAGES: #ifdef LC_MESSAGES ADD_INT(module, LC_MESSAGES); #endif /* LC_MESSAGES */ -- ___ Python tracker <https://bugs.python.org/issue44387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44382] Python 3.9+ on Windows 8.0
Jack DeVries added the comment: https://buildbot.python.org/all/#/waterfall?tags=win64 Buildbot is only running against 8.1, not 8.0. I'm guessing that means that the docs are correct and python.org main page is wrong. I'd open an issue over there: https://github.com/python/pythondotorg/issues -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44386] importlib and math.pi interact strangely
Jack DeVries added the comment:
That is because pi, along with other constants in the math module are defined
during module execution, not module creation:
https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Modules/cmathmodule.c#L1257-L1262
Taking the example right here
(https://docs.python.org/3/library/importlib.html#checking-if-a-module-can-be-imported)
from the docs, you can see how they call exec_module() after module_from_spec.
If you change your code to do that as well, you will find that pi is now
defined:
from importlib import util
mathmodule = util.find_spec("math")
math1 = util.module_from_spec(mathmodule)
mathmodule.loader.exec_module(math1)
print(math1.pi)
--
nosy: +jack__d
___
Python tracker
<https://bugs.python.org/issue44386>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
Change by Jack DeVries : -- nosy: +jack__d nosy_count: 10.0 -> 11.0 pull_requests: +25270 pull_request: https://github.com/python/cpython/pull/26643 ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37880] For argparse add_argument with action='store_const', const should default to None.
Jack DeVries added the comment: Hi Joannah, I'm a new contributor and happy to take a crack at this if you haven't already started on a fix / would like me to do that. Thanks! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue37880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
