[issue44406] Divergent sys.prefix behavior causes `python -m build` command to fail when in virtual environment

New submission from Dylan : Confirmed on 3.6 and 3.9. The issue can be found in venv\__init__.py where the sys.prefix is used to determine the parent path of the python executable (near the bottom of the symlink_or_copy method at about line 190). On the venv documentation page (https

[issue6997] python26 compiled on snow leopard x86_64

New submission from Dylan : Hi guys, I consider myself self-taught average geek. after a long time trying many things to get python2.6.2 to build with macports it fails every time until i used this specific argument in the work folder below cd /opt/local/var/macports/build

[issue6997] python26 compiled on snow leopard x86_64

Dylan added the comment: oops forgot to mention i realized it was defaulted to /usr/local so i tried compiling the same configuration except adding --prefix=/opt/local built fine try using sudo DEFAULT_ARCH=x86_64 MACOSX_DEPLOYMENT_TARGET=10.6 ./configure --with-universal-archs=64-bit

[issue6997] python26 compiled on snow leopard x86_64

Dylan added the comment: Thanks! compiled cleanly @/opt/local build is active. -- ___ Python tracker <http://bugs.python.org/issue6997> ___ ___ Python-bugs-list m

[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix

Changes by Dylan Grose <[EMAIL PROTECTED]>: -- nosy: +dkbg ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3394> ___ ___ Python-bugs

[issue43162] Enum regression: AttributeError when accessing class variables on instances

Dylan Baker added the comment: Author of said meson code here. I use this pattern when the enum names and values are implementation details, but the string values are user visible. In this case the enum itself is used internally to represent what kind of test we're doing, but

[issue12758] time.time() returns local time instead of UTC

Dylan Sarber added the comment: I patched this one up quickly. One has been changed using belopolsky's recommendation, which already reads well. -- keywords: +patch nosy: +dwsarber Added file: http://bugs.python.org/file24858/time_doc_fix.

[issue35557] Allow lowercase hexadecimal characters in base64.b16decode()

New submission from Dylan Houlihan : Currently, the `base64` method `b16decode` does not decode a hexadecimal string with lowercase characters by default. To do so requires passing `casefold=True` as the second argument. I propose a change to the `b16decode` method to allow it to accept

[issue35557] Allow lowercase hexadecimal characters in base64.b16decode()

Change by Dylan Houlihan : -- keywords: +patch pull_requests: +10512 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35557> ___ ___ Py

[issue35557] Allow lowercase hexadecimal characters in base64.b16decode()

Change by Dylan Houlihan : -- versions: -Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35557> ___ ___ Pytho

[issue35557] Allow lowercase hexadecimal characters in base64.b16decode()

Change by Dylan Houlihan : -- type: performance -> behavior ___ Python tracker <https://bugs.python.org/issue35557> ___ ___ Python-bugs-list mailing list Un

[issue35557] Allow lowercase hexadecimal characters in base64.b16decode()

Dylan Houlihan added the comment: Karthikeyan, Thank you for taking the time to respond so thoroughly. In particular, in the future I'll be more careful to qualify and quantify potential performance improvements using `timeit` or `perf`. That being said, as I mentioned the pr

[issue35968] lib2to3 cannot parse rf''

New submission from Dylan Lloyd : ``` #!/usr/bin/env python # -*- coding: utf-8 -*- regex_format = rf'' ``` ``` yapf poc.py ``` ``` Traceback (most recent call last): File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 115, in Pars

[issue35132] python-gdb error: Python Exception Type does not have a target

Dylan Cali added the comment: > Hum, Dylan: what is your gdb version? $ gdb --version GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > On Fedora 29 with gdb 8.2-6.fc29, it seems like .target() is useless I can confirm removing the .target() call in libpython.py resolved the issue for m

[issue36056] importlib does not support pathlib

New submission from Dylan Lloyd : ``` ❯ python -c 'import pathlib; import importlib; importlib.import_module(pathlib.Path("poc.py"))' Traceback (most recent call last): File "", line 1, in File "~/.conda/envs/py3.6/lib/python3.6/importlib/__init__.py&q

[issue36056] importlib does not support pathlib

Dylan Lloyd added the comment: Whoops, yes, that of course makes sense. My mistake. Thanks! -- resolution: not a bug -> status: closed -> open type: enhancement -> ___ Python tracker <https://bugs.python.or

[issue35132] python-gdb error: Python Exception Type does not have a target

Dylan Cali added the comment: Thank you! And thank you Lisa Roach for the investigation and fix. -- ___ Python tracker <https://bugs.python.org/issue35

[issue36581] __dir__ on unittest.mock not safe for all spec types

New submission from Dylan Semler : If a MagicMock is created with a spec or spec_set that is a non-list iterable of strings (like a tuple), calling dir() on said mock produces a Traceback. Here's a minimum example: 🡒 cat poc.py from unittest.mock import MagicMock mock = MagicMock(spe

[issue36581] __dir__ on unittest.mock not safe for all spec types

Dylan Semler added the comment: I agree docs only say "list of strings" and so this isn't a case where there's behavior that contrasts with the documentation. I merely ran into this issue in my project and found it difficult to get to the root of so wanted to fix it upst

[issue35132] python-gdb error: Python Exception Type does not have a target

New submission from Dylan Cali : Python version: 3.6.6-debug System: Kernel: 4.15.0-38-generic x86_64 Distro: Linux Mint 18.2 Sonya CPU:Quad core Intel Xeon E3-1505M Memory: 32018.6MB Expected: py-list and py-bt to print the current python frame and traceback when attaching to a

[issue18073] pickle.Unpickler may read too many bytes, causing hangs with blocking input stream

Dylan Radcliffe added the comment: What I see in gdb is that that read is occurring due to the unpickling thread reading peeking ahead in the stream due to buffered io being used. #0 0x77bcbcbd in read () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x0061f521 in

[issue8335] distutils test_build_ext's test_get_outputs fails in bootstrap environment

Dylan Canfield added the comment: I am having the exact same problem with test_distutils failing on a clean env. Did reverting the changes in r72637 fix your problem? -- nosy: +Canfield ___ Python tracker <http://bugs.python.org/issue8

[issue42158] guess_format() MIME type doesn't guess n-quads, n-triples, notation3 and TriG

New submission from Dylan Van Assche : guess_format() from lib/mimetypes.py doesn't guess correctly the following MIME types: - .nq: application/n-quads (specification: https://www.w3.org/TR/n-quads/) - .nt: application/n-triples (specification: https://www.w3.org/TR/n-triples/) - .n3:

[issue42158] http.server doesn't guess n-quads, n-triples, notation3 and TriG MIME types

Change by Dylan Van Assche : -- title: http.server MIME type doesn't guess n-quads, n-triples, notation3 and TriG MIME types -> http.server doesn't guess n-quads, n-triples, notation3 and TriG MIME types ___ Python tr

[issue42158] http.server MIME type doesn't guess n-quads, n-triples, notation3 and TriG MIME types

Change by Dylan Van Assche : -- title: guess_format() MIME type doesn't guess n-quads, n-triples, notation3 and TriG -> http.server MIME type doesn't guess n-quads, n-triples, notation3 and TriG MIME types ___ Python tr

[issue42158] http.server doesn't guess n-quads, n-triples, notation3 and TriG MIME types

Dylan Van Assche added the comment: Adding the MIME types to /etc/mime.types fixes this issue, but I'm not sure if that's the right 'fix' -- ___ Python tracker <https://bug

[issue42158] http.server doesn't guess n-quads, n-triples, notation3 and TriG MIME types

Change by Dylan Van Assche : -- keywords: +patch pull_requests: +22126 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23230 ___ Python tracker <https://bugs.python.org/issu

[issue33022] Floating Point Arithmetic Inconsistency (internal off-by-one)

New submission from Dylan Dmitri Gray : ``` >>> for i in (1,2,3,1.0,2.0,3.0): print(i, i+9007199254740991) ... 1 9007199254740992 2 9007199254740993 3 9007199254740994 1.0 9007199254740992.0 2.0 9007199254740992.0 # <-- !!! 3.0 9007199254740994.0 ``` Notably 900719925474099