[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://docs.python.org/3/library/venv.html), it is noted that: When a virtual environment is active (i.e., the virtual environment’s Python interpreter is running), the attributes sys.prefix and sys.exec_prefix point to the base directory of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to the non-virtual environment Python installation which was used to create the virtual environment. If a virtual environment is not active, then sys.prefix is the same as sys.base_prefix and sys.exec_prefix is the same as sys.base_exec_prefix (they all point to a non-virtual environment Python installation). This code is called by lib\site-packages\build\env.py (venv.EnvBuilder...) which fails erroneously due to the divergent behavior of the sys.prefix as described in the documentation snippet above. Recommended fix: I'm not sure why that behavior diverges in the first place. Ideally, either the build lib\venv\__init__.py should be updated to not rely on sys.prefix, or the sys.prefix behavior should be changed. Additional Notes: - I am seeing this issue on Windows 10 - The venv instance is within an Anaconda directory. - The python -m build command I am running is from within a virtual environment - I've listed file paths in relation to the library path within the same directory as the python executable for convenience. Let me clarify, however, that there are multiple instances of the python lib folder: 1 global and 1 local copy. The venv path is located in the global instance within the Anaconda path whereas the build script is using the virtual environment instance of python. -- assignee: docs@python components: Build, Documentation, Windows messages: 395721 nosy: docs@python, dsmaccy, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Divergent sys.prefix behavior causes `python -m build` command to fail when in virtual environment versions: Python 3.6, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2 configure and make as followed (this is what i know works, i know there is possibly a shorter more proficient way to do this so don't blame me i just got this thing to compile is all.) sudo DEFAULT_ARCH=x86_64 MACOSX_DEPLOYMENT_TARGET=10.6 ./configure --with-universal-archs=64-bit Please share this among devs at macports Thought I'd mention my success here first. - Dylan Mahoney -- components: Build messages: 93128 nosy: monway severity: normal status: open title: python26 compiled on snow leopard x86_64 type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 --prefix=/opt/local -- ___ Python tracker <http://bugs.python.org/issue6997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 we're initializing it from user input. There might be reasons in the future that the names of the enum members and the string values being passed in aren't the same anymore, say because we map two string values to one enum value. I guess I could accomplish the same thing with a staticmethod or helper function, but the code is effectively an alternate initializer, and follows that pattern using a classmethod. -- nosy: +baker.dylan.c ___ Python tracker <https://bugs.python.org/issue43162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.patch ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 hexadecimal strings containing lowercase characters without requiring the `casefold` argument. The revision itself is straightforward. We simply have to amend the regular expression to match the lowercase characters a-f in addition to A-F. Likewise the corresponding tests in Lib/base64.py also need to be changed to account for the lack of a second argument. Therefore there are two files total which need to be refactored. In my view, there are several compelling reasons for this change: 1. There is a nontrivial performance improvement. I've already made the changes on my own test branch[1] and I see a mean decoding performance improvement of approximately 9.4% (tested by taking the average of 1,000,000 hexadecimal string encodings). The testing details are included in a file attached to this issue. 2. Hexadecimal strings are case insensitive, i.e. 8DEF is equivalent to 8def. This is the particularly motivating reason why I've written the patch - there have been many times when I've been momentarily confounded by a hexadecimal string that won't decode only to realize I'm yet again passing in a lowercase string. 3. The behavior of the underlying method in `binascii`, `unhexlify`, accepts both uppercase and lowercase characters by default without requiring a second parameter. From the perspective of code hygiene and language consistency, I think it's both more practical and more elegant for the language to behave in the same, predictable manner (particularly because `base64.py` simply calls `binascii.c` under the hood). Additionally, the `binascii` method `hexlify` actually outputs strings in lowercase encoding, meaning that any use of both `binascii` and `base64` in the same application will have to consistently do a `casefold` conversion if output from `binascii.hexlify` is fed back as input to `base64.b16decode` for some reason. There are two arguments against this patch, as far as I can see it: 1. In the relevant IETF reference documentation (RFC3548[2], referenced directly in the `b16decode` docstring; and RFC4648[3] with supersedes it), under Security Considerations the author Simon Josefsson claims that there exists a potential side channel security issue intrinsic to accepting case insensitive hexadecimal strings in a decoding function. While I'm not dismissing this out of hand, I personally do not find the claimed vulnerability compelling, and Josefsson does not clarify a real world attack scenario or threat model. I think it's important we challenge this assumption in light of the potential nontrivial improvements to both language consistency and performance. I would be very interested in hearing a real threat model here that would practically exist outside of a very contrived scenario. Moreover if this is such a security issue, why is the behavior already evident in `binascii.unhexlify`? 2. The other reason may be that there's simply no reason to make such a change. An argument can be put forward that a developer won't frequently have to deal with this issue because the opposite method, `b16encode`, produces hexadecimal strings with uppercase characters. However, in my experience hexadecimal strings with lowercase characters are extremely common in situations where developers haven't produced the strings themselves in the language. As I mentioned, I have already written the changes on my own patch branch. I'll open a pull request once this issue has been created and reference the issue in the pull request on GitHub. References: 1. https://github.com/djhoulihan/cpython/tree/base64_case_sensitivity 2. https://tools.ietf.org/html/rfc3548 3. https://tools.ietf.org/html/rfc4648 -- components: Library (Lib) files: testing_data.txt messages: 332319 nosy: djhoulihan priority: normal severity: normal status: open title: Allow lowercase hexadecimal characters in base64.b16decode() type: performance versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48013/testing_data.txt ___ Python tracker <https://bugs.python.org/issue35557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 primary motivation for this is not a performance improvement - I just felt that was a nice potential side effect. Rather, this enhancement brings `base64.b16decode` into behavioral consistency with `binascii.unhexlify`. The `binascii` method already accepts both uppercase and lowercase hexadecimal characters by default. However I can definitely understand what you and Serhiy are saying about this being a breaking change. Therefore I'd like to amend my proposal to the following: 1. Keep the `casefold` argument and corresponding logic, but keep the revised regex that will match against both uppercase and lowercase characters; and 2. Only put this change in for Python 3.8, this way existing code which uses the explicit argument on versions <= 3.7 does not break (but will still function normally). I've altered this issue to reflect my amended proposal, targeting only version 3.8 and editing the type to be behavior instead of performance. In this way, the change will still make `base64.b16decode` consistent with `binascii.unhexlify` (and the case insensitivity of hexadecimal encoding more generally) without breaking existing code or requiring developers to change workflows using `casefold`. Naturally there would be additional logic that *enforces* the case sensitivity if `casefold=false` is passed to the method, and this will likewise not break existing workflows either. If this change is considered agreeable, I will amend my open pull request to roll back the breaking change and refactor the way `casefold` is processed. From my perspective this amended proposal offers an upside in language consistency without any downside. -- ___ Python tracker <https://bugs.python.org/issue35557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
ParseCodeToTree
tree = parser_driver.parse_string(code, debug=False)
File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string
return self.parse_tokens(tokens, debug)
File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken
raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4,
17))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "bin/yapf", line 10, in
sys.exit(run_main())
File "lib/python3.6/site-packages/yapf/__init__.py", line 326, in run_main
sys.exit(main(sys.argv))
File "lib/python3.6/site-packages/yapf/__init__.py", line 213, in main
verbose=args.verbose)
File "lib/python3.6/site-packages/yapf/__init__.py", line 263, in FormatFiles
in_place, print_diff, verify, verbose)
File "lib/python3.6/site-packages/yapf/__init__.py", line 289, in _FormatFile
logger=logging.warning)
File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 91, in
FormatFile
verify=verify)
File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 129, in
FormatCode
tree = pytree_utils.ParseCodeToTree(unformatted_source)
File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 121, in
ParseCodeToTree
tree = parser_driver.parse_string(code, debug=False)
File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string
return self.parse_tokens(tokens, debug)
File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken
raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4,
17))
```
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 335238
nosy: majuscule
priority: normal
severity: normal
status: open
title: lib2to3 cannot parse rf''
type: crash
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue35968>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 me with no ill effects > You can try faulthandler has a workaround. I'll give this a try, thank you -- ___ Python tracker <https://bugs.python.org/issue35132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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", line 117, in
import_module
if name.startswith('.'):
AttributeError: 'PosixPath' object has no attribute 'startswith'
```
--
components: Library (Lib)
messages: 336136
nosy: majuscule
priority: normal
severity: normal
status: open
title: importlib does not support pathlib
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue36056>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue36056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue35132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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(spec=('a', 'tuple'))
dir(mock)
🡒 python3 poc.py
Traceback (most recent call last):
File "poc.py", line 4, in
dir(mock)
File "/usr/lib64/python3.6/unittest/mock.py", line 677, in __dir__
return sorted(set(extras + from_type + from_dict +
TypeError: can only concatenate tuple (not "list") to tuple
--
components: Library (Lib)
messages: 339813
nosy: Dylan Semler
priority: normal
severity: normal
status: open
title: __dir__ on unittest.mock not safe for all spec types
type: crash
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36581>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 upstream. I made a patch and reported this bug only as a formality to accompany my patch. -- ___ Python tracker <https://bugs.python.org/issue36581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 hung python process with gdb, a debug build of python, and
cpython/Tools/gdb/libpython.py loaded.
Actual:
py-list and py-bt fail with:
Python Exception Type does not have a target.:
Error occurred in Python command: Type does not have a target.
Invoking 'set python print-stack full' in gdb produces the more useful:
Traceback (most recent call last):
File "", line 1, in
File "~/git/cpython/Tools/gdb/libpython.py", line 916, in filename
File "~/git/cpython/Tools/gdb/libpython.py", line 1158, in proxyval
RuntimeError: Type does not have a target.
so it is failing at:
fields = gdb.lookup_type('PyUnicodeObject').target().fields()
in libpython.py [1].
Reproduce:
I haven't been able to create a simple standalone program that triggers the
failure. I am working on a PR for Keras to try and fix the multiprocessing
support in some of their utility classes. Currently the tests are sporadically
hanging and my intention was to use python's gdb integration to identify
exactly where and why the hangs are occuring... but I can't get that
information at the moment because of the error above when invoking py-list and
py-bt.
So, unfortunately, the shortest path to reproduce is to checkout the PR branch,
run the offending tests, connect with gdb, and invoke py-list/py-bt:
* install a debug version of 3.6.6 if one isn't already available
* git clone https://github.com/calid/keras.git -b fix-multiprocessing-hang
* cd keras
* pip install -e .[tests]
* pip install tensorflow
* py.test tests/keras/utils/data_utils_test.py
* wait for hang
* gdb -p
* invoke py-list or py-bt
I am happy to poke around in libpython.py and try to fix/submit a PR myself,
but I'm not at all familiar with the python internals so I would need some
guidance. And obviously let me know if this isn't actually a bug but rather
environment related/user error.
Thank you!
[1] https://github.com/python/cpython/blob/v3.6.6/Tools/gdb/libpython.py#L1158
--
components: Demos and Tools
messages: 329052
nosy: Dylan Cali
priority: normal
severity: normal
status: open
title: python-gdb error: Python Exception Type does not
have a target
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue35132>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 fileio_readinto (self=0x76491528, args=0x766dc190) at ./Modules/_io/fileio.c:541 #2 0x004b96f0 in PyCFunction_Call (func=0x7601d598, arg=0x766dc190, kw=0x0) at Objects/methodobject.c:90 #3 0x0045a0c2 in PyObject_Call (func=0x7601d598, arg=0x766dc190, kw=0x0) at Objects/abstract.c:2105 #4 0x0045ad3e in PyObject_CallMethodObjArgs (callable=0x7601d598, name=0x77f3ccf0) at Objects/abstract.c:2341 #5 0x00626e65 in _bufferedreader_raw_read (self=0x76777e58, start=0xa89210 ".\002X\367\017", len=4096) at ./Modules/_io/bufferedio.c:1438 #6 0x006270ed in _bufferedreader_fill_buffer (self=0x76777e59) at ./Modules/_io/bufferedio.c:1470 #7 0x00628474 in _bufferedreader_peek_unlocked (self=0x76777e58) at ./Modules/_io/bufferedio.c:1714 #8 0x00624b1d in buffered_peek (self=0x76777e58, args=0x766d4948) at ./Modules/_io/bufferedio.c:880 As a possible workaround if you disable buffering when opening your pipe for input it seems to prevent the problem (though I am not sure about performance implications). 22c22 < load = Unpickler(os.fdopen(r, 'rb')).load --- > load = Unpickler(os.fdopen(r, 'rb', 0)).load -- nosy: +dylanr ___ Python tracker <http://bugs.python.org/issue18073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue8335> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: text/n3 (specification: https://www.w3.org/TeamSubmission/n3/) - .trig: application/trig (specification: https://www.w3.org/TR/trig/) In these cases the default MIME type is returned: application/octet-stream -- components: Library (Lib) messages: 379676 nosy: DylanVanAssche priority: normal severity: normal status: open title: guess_format() MIME type doesn't guess n-quads, n-triples, notation3 and TriG type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker <https://bugs.python.org/issue42158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker <https://bugs.python.org/issue42158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue42158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue42158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 9007199254740991 = 2**53 -1 Probably an internal off by one? -- messages: 313420 nosy: ddg priority: normal severity: normal status: open title: Floating Point Arithmetic Inconsistency (internal off-by-one) versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33022> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
