[issue45665] Problems caused by isinstance(list[int], type) returning True
Joseph Perez added the comment: There is also https://bugs.python.org/issue44293 about inspect.isclass -- nosy: +joperez ___ Python tracker <https://bugs.python.org/issue45665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
Joseph Fox-Rabinovitz added the comment: I closed the issue (it's already been rejected), primarily based on > a.__index__ = is an unauthorized use of a *reserved* word and the > effect of such usage is not and need not be documented. > The entry for __*__ does include "*Any* use of __*__ names, in any context, > that does not follow explicitly documented use, is subject to breakage > without warning." To me, that says that the effect of the reserved-word > assignment is undefined. It could be made to raise an exception. It's like filing a bug report for UB in C. -- stage: needs patch -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44174] Unclear meaning of _Private__names in enum docs.
Joseph Riddle added the comment: _Private__names seems to no longer exist in the Python 3.11 documentation. https://docs.python.org/3.11/library/enum.html#private-names It appears to have been removed in this PR https://github.com/python/cpython/pull/23748/files Should this issue be updated to remove Python 3.11 from the Versions? -- nosy: +joeriddles ___ Python tracker <https://bugs.python.org/issue44174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45418] types.UnionType is not subscriptable
Joseph Perez added the comment: Indeed, sorry, my example was bad. My library was raising at several place, and I've extrapolated about generic substitution. I've indeed other substitutions (without `TypeVar`), and because they were failing, I've assumed that all of my substitutions were failing; I was wrong about generic one. For example, if I want to substitute `int | Collection[int]` to `int | list[int]`, I will have to replace `types.UnionType` by `typing.Union` or use `reduce`, while it was not necessary in 3.9 where I could just write `get_origin(tp)[new_args]`. So I'll have to add some `if` in my code. -- stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue45418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45418] types.UnionType is not subscriptable
New submission from Joseph Perez : `types.UnionType` is not subscriptable, and this is an issue when type manipulations are done. A common maniputation I've to do is to substitute all the `TypeVar` of a potential generic type by their specialization in the given context. For example, given a class: ```python @dataclass class Foo(Generic[T]): bar: list[T] baz: T | None ``` in the case of `Foo[int]`, I want to compute the effective type of the fields, which will be `list[int]` and `int | None`. It could be done pretty easily by a recursive function: ```python def substitute(tp, type_vars: dict): origin, args = get_origin(tp), get_args(tp) if isinstance(tp, TypeVar): return type_vars.get(tp, tp) elif origin is Annotated: return Annotated[(substitute(args[0], type_vars), *args[1:])] else: return origin[tuple(substitute(arg) for arg in args)] # this line fails for types.UnionType ``` And this is not the only manipulation I've to do on generic types. In fact, all my library (apischema) is broken in Python 3.10 because of `types.UnionType`. I've to substitute `types.UnionType` by `typing.Union` everywhere to make things work; `types.UnionType` is just not usable for dynamic manipulations. I've read PEP 604 and it doesn't mention if `types.UnionType` should be subscriptable or not. Is there a reason for not making it subscriptable? -- messages: 403554 nosy: joperez priority: normal severity: normal status: open title: types.UnionType is not subscriptable versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44866] Inconsistent Behavior of int()
New submission from John Joseph Morelli :
I first noticed this and reported it on the W3 Schools Tutorial, the section
entitled "Add Two Numbers with User Input"
There were many behaviors that I did not understand, but for this bug report, I
will state that the input statements present seem to return a string and under
most situations will return an error if the user inputs a real number like 2.8.
However, under a very specific situation, it will truncate 2.8 to 2 without
error.
After further investigation, I believe the following session in the IDLE's
output window and editor illustrates this inconsistent behavior. Note that I
have added comments after copying the session here...
>>> print(x) #want to ensure new session has x as undefined
Traceback (most recent call last):
File "", line 1, in
print(x)
NameError: name 'x' is not defined # confirmed x is undefined
>>> x="2" # define x as the string "2"
>>> print(x)
2
>>> print(type(x)) # confirm that x is a string value of "2"
>>> y=int(x) # convert string value of "2" to integer of 2 -
# according to documentation this should work - see "If x is not a
# number or if base is given, then x must be a string, bytes, or
# bytearray instance representing an integer literal in radix base."
# at link --> https://docs.python.org/3.9/library/functions.html#int
>>> print(type(y)) # ensure y is type int
>>> print(y)
2
>>> z=x+".8" # create z to be the concatenation of two strings "2" and ".8" =
>>> "2.8", a string representation of the real number 2.8
>>> print(z)
2.8
>>> print(type(z)) # ensure z is a string
>>> aa=int(z) # convert z to an integer (as descried in the link
# above, this should NOT work
Traceback (most recent call last):
File "", line 1, in
aa=int(z)
ValueError: invalid literal for int() with base 10: '2.8'
>>> w="2.8" # Define w directly as the string value of 2.8 = "2.8"
>>> bb=int(w) # This should also produce an error
Traceback (most recent call last):
File "", line 1, in
bb=int(w)
ValueError: invalid literal for int() with base 10: '2.8'
>>> a='2.8'
>>> b=int(a)
Traceback (most recent call last):
File "", line 1, in
b=int(a)
ValueError: invalid literal for int() with base 10: '2.8'
>>> print(type(a)) # Ensure a is a string
>>> w="2"
>>> bb=int(w)
>>> print(bb)
2
>>> print(type(bb))
>>> test=int(input("What is test value? ")) #lets try inputting a
# real number but as an argument to int and assigning it to test
What is test value? 2.8 # this should not work either
Traceback (most recent call last):
File "", line 1, in
test=int(input("What is test value? "))
ValueError: invalid literal for int() with base 10: '2.8'
>>> # So everything here is working as expected, but...
Here is code from the IDLE editor... a file called testinput1.py
x = int(1)
y = input("Type a number: ")
print(type(y))
int_y = int(2.8) #conver y to an integer 2 and assign to int_y
z = int("3")
print(x)
print(y)
print(int_y)
print(z)
# I can find no documentation to suggest this should work, but it does. Here
is the output in IDLE's shell
Type a number: 2.8
1
2.8
2
3
Now, if I immediately go into the shell while the variables remain untouched
and defined...
>>> a=int(y) # Correctly, this produces the expected error
Traceback (most recent call last):
File "", line 1, in
a=int(y)
ValueError: invalid literal for int() with base 10: '2.8'
After extensive testing, I conclude that after input, you may immediately apply
the int() function to the resulting string, but you quickly lose that ability,
resulting in the expected error. I can find no documentation to explain this
behavior.
If I am not overlooking something, I think this should either be in the
documentation of the function int(), if it is intended to behaviour this way,
or as a bug, should be corrected.
NOTE, I just started learning Pytyon this weekend, so I may be just ignorant of
the behavior, but I have searched a good bit and found nothing suggesting this
is how int() should behalf. I have also not studied the other constructor
functions.
--
assignee: docs@python
components: Build, Documentation, IDLE, Library (Lib), Windows
files: function_int_08Aug21.txt
messages: 399224
nosy: TheDoctor165, docs@python, paul.moore, steve.dower, terry.reedy,
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent Behavior of int()
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50205/function_int_08Aug21.txt
___
Python tracker
<https://bugs.python.org/issue44866>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44353] PEP 604 NewType
New submission from Joseph Perez :
`typing.NewType` doesn't support PEP 604.
```
>>> import typing
>>> A = typing.NewType("A", int)
>>> B = typing.NewType("B", str)
>>> A | B
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for |: 'function' and 'function'
```
--
messages: 395359
nosy: joperez
priority: normal
severity: normal
status: open
title: PEP 604 NewType
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44353>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44293] PEP 585 breaks inspect.isclass
Joseph Perez added the comment: @Jelle Zijlstra Thank you for the explanation. > The current implementation of GenericAlias has been around for a few releases > by now, though, so that change might break some use cases. I agree that a "fix" could have unexpected side-effect, my issue comes quite late indeed. By the way, Python typing is so much unstable (every version breaks the previous one), it's very complicated to write code that support multiple versions, so whatever the typing internal implementation, we must adapt. > This is not true; it is the same for e.g. `set[int]`. Unless you meant > something else here. I have chosen `list[int]` as an example of `types.GenericAlias` introduced by PEP 585 (i could have chosen `set[int]` or `collections.abc.Collection[int]`). But other generic aliases, e.g. `typing.List[int]` or `MyClass[int]` (where `MyClass` inherits `Generic[T]`), are not instances of `type`. > @Joseph Perez, is there a specific library or pattern that is broken by this? Because `issubclass` requires a "class" as arg 1, I use the pattern `if isinstance(tp, type) and issubclass(tp, SomeClass)` (`isinstance` check being equivalent to `inspect.isclass`). With PEP 585, it breaks for `list[int]` and other builtin generic aliases. > FWIW I did think rather carefully about which attributes to delegate or not, > and delegating __class__ was intentional. I don't have the context of the decision, so I can quite understand that delegating `__class__` was the right thing to do, especially when `__mro__` and other `type` attributes are also delegated. I mainly wanted to highlight this side effect, especially on the pattern mentioned above. (My issue title is a little bit excessive in this regard) But as I've written, I've already so many wrappers to maintain compatibility between Python versions of typing that I can write a new one to handle this particularity of PEP 585. So this issue is not critical to me. -- ___ Python tracker <https://bugs.python.org/issue44293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44293] PEP 585 breaks inspect.isclass
New submission from Joseph Perez : PEP 585 has the side-effect of making `list[int]` an instance of `type`. This is not the case for other generic aliases. It also implies that `inspect.isclass(list[int]) is True`, while `list[int]` is not a class; as a proof of this statement `issubclass(list[int], collections.abc.Collection)` raises `TypeError: issubclass() arg 1 must be a class`. By the way, there is the awkward thing of having `isinstance(list[int], type) is True` while `issubclass(type(list[int]), type) is False`. -- messages: 394950 nosy: joperez priority: normal severity: normal status: open title: PEP 585 breaks inspect.isclass versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44183] Can't install certificates if GUI tools are not installed on macOS
New submission from Joseph Trask Still : This issue occurs on my M1 MacBook Pro running macOS 11.3.1. Steps to reproduce: 1. Open the Python installation package 2. When asked where to install the package, click "Customize" at the bottom of the dialog 3. Uncheck the GUI Tools option 4. Proceed through the installation as normal 5. At the conclusion of the installation, when offered to install certificates, click either the Finder link, or the link to the ReadMe. The system will play the error sound, and nothing will open. The issue appears to occur due to the fact the Python 3.9 folder is not created in Applications if the GUI Tools are not installed. -- components: Installation messages: 393998 nosy: thetechconspiracy priority: normal severity: normal status: open title: Can't install certificates if GUI tools are not installed on macOS type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43818] Email does not apply policy to multipart messages with defects
New submission from Joseph Ishac : I have noticed an issue (Python 3.8.5) where an email can be read in as bytes, but will not be returned as such with the as_bytes() call if the message is multipart, has a boundary which is not properly quoted, and the message has non-ascii text. It seems to be a result of how multipart messages are treated if the NoBoundaryInMultipartDefect is encountered [See Test #1]. I would argue that attempting to output the test message in the sample script with an 8bit, utf-8 enabled policy should return the original bytes as the 8bit policy should be applied to the "body" portion (any part after the null lines) of the email (as would be the case if it were not multipart) [See Test #4] Currently it appears that the entire message is treated as headers, applying the strict 7bit, ascii requirement to the entire contents of the message. Furthermore, the msg.preamble is None. I am also uncertain that attempting to leverage the handle_defect hooks would be helpful as correcting the boundary doesn't seem to work unless you re-parse the message [See Tests #2 and #3] So the requested change would be to apply the encoding output policy to all portions of a message after the null line ending the headers. -- components: email files: email.multipart.test.py messages: 390897 nosy: barry, jishac, r.david.murray priority: normal severity: normal status: open title: Email does not apply policy to multipart messages with defects versions: Python 3.8 Added file: https://bugs.python.org/file49955/email.multipart.test.py ___ Python tracker <https://bugs.python.org/issue43818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Change by Joseph Shen : -- nosy: +benjamin.peterson ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Joseph Shen added the comment: Right now there is no need to keep this limits, and the __version__ info from GCC is quite simple. Pls the attached snapshot image. Therefor I don't think we should keep a commit from 2000. -- ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Change by Joseph Shen : -- title: Inconsistent behavior of Py_GetCompiler() -> unnecessary leading '\n' from Py_GetCompiler() when build with different complier ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] Inconsistent behavior of Py_GetCompiler()
Change by Joseph Shen : -- keywords: +patch pull_requests: +23384 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24606 ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] Inconsistent behavior of Py_GetCompiler()
New submission from Joseph Shen : The function Py_GetCompiler() return the version info with a leading '\n' when build with GCC/clang, while without this on other compilers. This inconsistent make the REPL print the 'welcome message' quit different, which I think is not we expect. >From the snapshot images, we can see, when compiler with MSVC, the 'welcome >message' has two lines, but with GCC it is 3 lines, which two lines is what >expected. Patch is given in the github rp, thanks for review. -- components: C API files: explorer_lN3ARB7gnj.png messages: 387417 nosy: josephsmeng priority: normal pull_requests: 23377 severity: normal status: open title: Inconsistent behavior of Py_GetCompiler() type: behavior Added file: https://bugs.python.org/file49824/explorer_lN3ARB7gnj.png ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42921] Inferred Optional type of wrapper function arguments
New submission from Joseph Perez :
`typing.get_type_hints` gives a different result for a wrapper created with
`functools.wraps` in case of inferred `Optional` arguments (when the default
value of the argument is None)
```python
from functools import wraps
from typing import get_type_hints
def foo(bar: int = None): ...
@wraps(foo)
def foo2(*args, **kwargs): ...
print(get_type_hints(foo)) # {'bar': typing.Optional[int]}
print(get_type_hints(foo2)) # {'bar': }
```
This is because `get_type_hints` use the defauts of the wrapper (`foo2`) and
not those of the wrapped function (`foo`).
This is not consistent with some other tools like `inspect.signature` which
gives the same signature (and thus same default argument) for the wrapped
function and its wrapper.
I think this case has simply been forgotten in the resolution of
https://bugs.python.org/issue37838 (fixing `get_type_hints` not taking `wraps`
in account at all), because inferred `Optional` is a kind deprecated feature
(https://github.com/python/typing/issues/275).
--
messages: 385005
nosy: joperez
priority: normal
severity: normal
status: open
title: Inferred Optional type of wrapper function arguments
type: behavior
___
Python tracker
<https://bugs.python.org/issue42921>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Joseph Fox-Rabinovitz added the comment:
Last attempt before I give up:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `winmode` parameter, `mode` was passed
in diretly, and `ctypes.DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
Link to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Joseph Fox-Rabinovitz added the comment:
Company firewall mutilated the text. Here is another attempt:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `parameter, and `mode` was passed in
direcCompany firewall mutilated the text. Here is another attempt:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `winmode` parameter, `mode` was passed
in diretly, and `ctypes.DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
yink to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340t.ly,
`ctyp. .DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
yink to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Change by Joseph Fox-Rabinovitz : -- title: Documentation of -> Documentation of ctypes.CDLL does not correspond to code ___ Python tracker <https://bugs.python.org/issue42114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of
New submission from Joseph Fox-Rabinovitz :
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but when
`winmode=None` To reproduce, any combination of adding the fol += der
containing the DLL to `os.evia ron['PATH']`, `os.add_dll_directory(...)`
Discoveryos.pathsep + ... triggered by https://stackoverflow.co, `sys.path.appen
Worked prior to 3.8 because there was no `winmode` parameter, and d(...)` does
not change the behavior.m/q/`mode` was passed in directly,
59330863/298873`ctypes0. .DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.Some info
summarized in https://stackoverflow.com/a/{8,9,}64472088/2988730.
Link to do pagecscorresponding :
https://docs.python.org/3.10/library/ctypes.html#ctypes.CDLL
730.
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
components: ctypes
messages: 379261
nosy: madphysicist
priority: normal
severity: normal
status: open
title: Documentation of
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41644] builtin type kwargs
Joseph Perez added the comment: That's why it's not an interpreter issue but a lack in the official documentation where the signature is documented. I quote https://docs.python.org/3/library/functions.html#type: > class type(object) > class type(name, bases, dict) The second line should be "class type(name, bases, dict, **kwargs)". (I've mentioned Pycharm and Mypy, but i think it's a kind of side-effect of the incomplete official documentation on which is based their typeshed) In fact, I've raised this issue because I've found myself needing to instantiate a class using `type` and kwargs, and I've not found in the documentation an example of it. -- ___ Python tracker <https://bugs.python.org/issue41644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41644] builtin type kwargs
New submission from Joseph Perez :
Class definition can have kwargs which are used by `__init_subclass__` (and
`__prepare__`).
However, passing these kwargs using `type` builtin function instead of class
definition syntax is not documented; kwargs are not mentioned in the function
signature.
https://docs.python.org/3/library/functions.html#type
However, passing kwargs to `type` works:
```python
class Foo:
def __init_subclass__(cls, **kwargs):
print(kwargs)
Bar = type("Bar", (Foo,), {}, bar=None) # mypy and Pycharm complain
#> {'bar': None}
```
By the way, the possibility to pass kwargs in `type` call is not documented in
https://docs.python.org/3/reference/datamodel.html#customizing-class-creation
too.
--
assignee: docs@python
components: Documentation
messages: 375936
nosy: docs@python, joperez
priority: normal
severity: normal
status: open
title: builtin type kwargs
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41644>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41370] PEP 585 and ForwardRef
Joseph Perez added the comment: However, PEP 563 will not solve the recursive type alias issue like `A = list["A"]` but this is a minor concern. -- ___ Python tracker <https://bugs.python.org/issue41370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41370] PEP 585 and ForwardRef
New submission from Joseph Perez :
PEP 585 current implementation (3.10.0a0) differs from current Generic
implementation about ForwardRef, as illustrated bellow:
```python
from dataclasses import dataclass, field
from typing import get_type_hints, List, ForwardRef
@dataclass
class Node:
children: list["Node"] = field(default_factory=list)
children2: List["Node"] = field(default_factory=list)
assert get_type_hints(Node) == {"children": list["Node"], "children2":
List[Node]}
assert List["Node"].__args__ == (ForwardRef("Node"),)
assert list["Node"].__args__ == ("Node",) # No ForwardRef here, so no
evaluation by get_type_hints
```
There is indeed no kind of ForwardRef for `list` arguments. As shown in the
example, this affects the result of get_type_hints for recursive types handling.
He could be "fixed" in 2 lines in `typing._eval_type` with something like this :
```python
def _eval_type(t, globalns, localns, recursive_guard=frozenset()):
if isinstance(t, str):
t = ForwardRef(t)
if isinstance(t, ForwardRef):
...
```
but it's kind of hacky/dirty.
It's true that this issue will not concern legacy code, 3.9 still being not
released. So developers of libraries using get_type_hints could add in their
documentation that `from __future__ import annotations` is mandatory for
recursive types with PEP 585 (I think I will do it).
By the way, Guido has quickly given his opinion about it in PR 21553: "We
probably will not ever support this: importing ForwardRef from the built-in
generic alias code would be problematic, and once from __future__ import
annotations is always on there's no need to quote the argument anyway." (So
feel free to close this issue)
--
messages: 374105
nosy: BTaskaya, eric.smith, gvanrossum, joperez, levkivskyi, lukasz.langa,
vstinner
priority: normal
severity: normal
status: open
title: PEP 585 and ForwardRef
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue41370>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41341] Recursive evaluation of ForwardRef (and PEP 563)
Joseph Perez added the comment: Ok, I admit that I did not think about recursive type when proposing this "fix". I've tried an implementation that just stop when recursion is encountered in a PR. -- ___ Python tracker <https://bugs.python.org/issue41341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41341] Recursive evaluation of ForwardRef (and PEP 563)
Change by Joseph Perez : -- keywords: +patch pull_requests: +20699 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21553 ___ Python tracker <https://bugs.python.org/issue41341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41341] Recursive evaluation of ForwardRef (and PEP 563)
New submission from Joseph Perez :
(This issue is already broached in https://bugs.python.org/issue38605, and a in
some way in https://bugs.python.org/issue35834, but only as a secondary
subject, that's why I've opened a ticket on this particular issue)
ForwardRef of ForwardRef are not currently evaluated by get_type_hints, only
the first level is, as illustrated in these examples:
```python
from typing import ForwardRef, Optional, get_type_hints
def func(a: "Optional[\"int\"]"):
pass
assert get_type_hints(func)["a"] == Optional[ForwardRef("int")]
# one would expect get_type_hints(func)["a"] == Optional[int]
```
```python
from __future__ import annotations
from typing import ForwardRef, Optional, get_type_hints
def func(a: Optional["int"]):
pass
assert get_type_hints(func)["a"] == Optional[ForwardRef("int")]
# one would expect get_type_hints(func)["a"] == Optional[int] (which is the
case without the import of __future__.annotations!)
```
On the one hand I find this behavior quite counter-intuitive; I rather think
ForwardRef as kind of internal (and wonder why there is no leading underscore,
like _GenericAlias where it's used) and I don't understand the purpose of
exposing it as the result of the public API get_type_hints. By the way, if
ForwardRef can be obtained by retrieving annotations without get_type_hints,
stringified annotations (especially since PEP 563) make get_type_hints kind of
mandatory, and thus make ForwardRef disappeared (only at the first level so …)
On the other hand, the second example show that adoptions of postponed
annotations can change the result of get_type_hints; several libraries relying
of get_type_hints could be broken.
An other issue raised here is that if these ForwardRef are not evaluated by
get_type_hints, how will be done their evaluatation by the user? It would
require to retrieve some globalns/localns — too bad, it's exactly what is doing
get_type_hints. And if the ForwardRef is in a class field, the class
globalns/localns will have to be kept somewhere while waiting to encounter
these random ForwardRef; that's feasible, but really tedious.
Agreeing with Guido Von Rossum (https://bugs.python.org/msg370232), this
behavior could be easily "fixed" in get_type_hints.
Actually, there would be only one line to change in ForwardRef._evaluate:
```python
# from
self.__forward_value__ = _type_check(
eval(self.__forward_code__, globalns, localns),
"Forward references must evaluate to types.",
is_argument=self.__forward_is_argument__)
# to
self.__forward_value__ = _eval_type(
_type_check(
eval(
self.__forward_code__, globalns, localns),
"Forward references must evaluate to types.",
is_argument=self.__forward_is_argument__,
),
globalns,
localns,
)
And if this fix could solve the "double ForwardRef" issue mentionned in
https://bugs.python.org/issue38605, it would also resolve
https://bugs.python.org/issue35834 in the same time, raising NameError in case
of unknown ForwardRef with postponed annotation.
--
messages: 373960
nosy: BTaskaya, eric.smith, gvanrossum, joperez, levkivskyi, lukasz.langa,
vstinner
priority: normal
severity: normal
status: open
title: Recursive evaluation of ForwardRef (and PEP 563)
type: behavior
___
Python tracker
<https://bugs.python.org/issue41341>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32958] socket module calls with long host names can fail with idna codec error
Joseph Hackman added the comment: According to the DNS standard, hostnames with more than 63 characters per label (the sections between .) are not allowed [https://tools.ietf.org/html/rfc1035#section-2.3.1]. That said, enforcing that at the codec level might be the wrong choice. I threw together a quick patch moving the limits up to 250, and nothing blew up. It's unclear what the general usefulness of such a change would be, since DNS servers probably couldn't handle those requests anyway. As for the original issue, if anybody is still doing something like that, could they provide a full example URL? I was unable to reproduce on HTTP (failed in a different place), or FTP. -- nosy: +joseph.hackman ___ Python tracker <https://bugs.python.org/issue32958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40425] Refleak in CDataObject
Change by Joseph Sible : -- nosy: +Joseph Sible ___ Python tracker <https://bugs.python.org/issue40425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40404] Python quit unexpectedly
Joseph added the comment: Sorry I should've added more context. I recently re-installed python on my computer and started getting these errors. It's hard to pinpoint when I get the error exactly, but I find it happens when I shutdown a Jupyter notebook. I'm wondering if this may be alluded to the fact that python has been incorrectly installed on my computer. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue40404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40404] Python quit unexpectedly
New submission from Joseph : Process: Python [91080] Path: /usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python Identifier:Python Version: 3.7.7 (3.7.7) Code Type: X86-64 (Native) Parent Process:bash [87533] User ID: 501 Date/Time: 2020-04-27 11:30:31.044 +0800 OS Version:Mac OS X 10.15.4 (19E287) Report Version:12 Bridge OS Version: 4.4 (17P4281) Anonymous UUID:2D923F70-DF15-0C75-5925-921AC7A6B975 Sleep/Wake UUID: 54C528EC-278D-4E97-9EA5-75A516A5B4EA Time Awake Since Boot: 43 seconds Time Since Wake: 4500 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_CRASH (SIGQUIT) Exception Codes: 0x, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Quit: 3 Termination Reason:Namespace SIGNAL, Code 0x3 Terminating Process: tmux [3601] Application Specific Information: dyld: in dlopen() Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 dyld0x00011591f899 ImageLoader::trieWalk(unsigned char const*, unsigned char const*, char const*) + 177 1 dyld0x000115929410 ImageLoaderMachOCompressed::findShallowExportedSymbol(char const*, ImageLoader const**) const + 112 2 dyld0x000115923085 ImageLoaderMachO::findExportedSymbol(char const*, bool, char const*, ImageLoader const**) const + 37 3 dyld0x00011591e513 ImageLoader::weakBindOld(ImageLoader::LinkContext const&) + 1485 4 dyld0x00011591c1ef ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&, char const*) + 333 5 dyld0x00011590e93f dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&, unsigned int) + 161 6 dyld0x000115918d77 dlopen_internal + 477 7 libdyld.dylib 0x7fff7043dd8a dlopen + 171 8 org.python.python 0x00010c9eef11 _PyImport_FindSharedFuncptr + 301 9 org.python.python 0x00010c9cdd7a _PyImport_LoadDynamicModuleWithSpec + 495 10 org.python.python 0x00010c9cd8f0 _imp_create_dynamic + 309 11 org.python.python 0x00010c922b0e _PyMethodDef_RawFastCallDict + 549 12 org.python.python 0x00010c92211f _PyCFunction_FastCallDict + 41 13 org.python.python 0x00010c9b0e12 _PyEval_EvalFrameDefault + 7738 14 org.python.python 0x00010c9b82cd _PyEval_EvalCodeWithName + 1698 15 org.python.python 0x00010c922424 _PyFunction_FastCallKeywords + 212 16 org.python.python 0x00010c9b7ad9 call_function + 737 17 org.python.python 0x00010c9b0a47 _PyEval_EvalFrameDefault + 6767 18 org.python.python 0x00010c922830 function_code_fastcall + 106 19 org.python.python 0x00010c9b7ad9 call_function + 737 20 org.python.python 0x00010c9b0a2e _PyEval_EvalFrameDefault + 6742 21 org.python.python 0x00010c922830 function_code_fastcall + 106 22 org.python.python 0x00010c9b7ad9 call_function + 737 23 org.python.python 0x00010c9b0ae2 _PyEval_EvalFrameDefault + 6922 24 org.python.python 0x00010c922830 function_code_fastcall + 106 25 org.python.python 0x00010c9b7ad9 call_function + 737 26 org.python.python 0x00010c9b0ae2 _PyEval_EvalFrameDefault + 6922 27 org.python.python 0x00010c922830 function_code_fastcall + 106 28 org.python.python 0x00010c9b7ad9 call_function + 737 29 org.python.python 0x00010c9b0ae2 _PyEval_EvalFrameDefault + 6922 30 org.python.python 0x00010c9b82cd _PyEval_EvalCodeWithName + 1698 31 org.python.python 0x00010c922424 _PyFunction_FastCallKeywords + 212 32 org.python.python 0x00010c9b7ad9 call_function + 737 33 org.python.python 0x00010c9b0ae2 _PyEval_EvalFrameDefault + 6922 34 org.python.python 0x00010c922830 function_code_fastcall + 106 35 org.python.python 0x00010c9b7ad9 call_function + 737 36 org.python.python 0x00010c9b0a47 _PyEval_EvalFrameDefault + 6767 37 org.python.python 0x00010c922830 function_code_fastcall + 106 38 o
[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)
Change by Joseph Gordon : -- nosy: -josephgordon ___ Python tracker <https://bugs.python.org/issue25597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25661] tokenize.untokenize does not maintain the order of tabbed indentations and leading spaces
Change by Joseph Gordon : -- nosy: -josephgordon ___ Python tracker <https://bugs.python.org/issue25661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24249] unittest API for detecting test failure in cleanup/teardown
Change by Joseph Gordon : -- nosy: -josephgordon ___ Python tracker <https://bugs.python.org/issue24249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Change by Joseph Gordon : -- nosy: -josephgordon ___ Python tracker <https://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39213] cmd should have a hook in the finally block of cmdloop
New submission from Joseph Sible : Currently, the cmdloop function in cmd has a preloop hook, which runs before the large try block, and a postloop hook, which runs at the end of the body of the large try block. This isn't sufficient for subclasses to safely use readline.set_completion_display_matches_hook, since an exception in the large try block would mean that postloop doesn't get called, so there wouldn't be an opportunity to restore the old value of that callback. This is analogous to how we need the finally block ourself to restore the old value of the completer. Moving where postloop is called would be a breaking change, so we should probably create a new method instead, called postloop_finally or something. -- components: Library (Lib) messages: 359305 nosy: Joseph Sible priority: normal severity: normal status: open title: cmd should have a hook in the finally block of cmdloop type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38910] AssertionError: ElementTree not initialized, missing root
Joseph Reagle added the comment: On 11/26/19 12:06 AM, Karthikeyan Singaravelan wrote: > Karthikeyan Singaravelan added the comment: > > This seems more like an issue with lxml. I posted a report over there now too: https://bugs.launchpad.net/lxml/+bug/1854057 -- ___ Python tracker <https://bugs.python.org/issue38910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38910] AssertionError: ElementTree not initialized, missing root
Joseph Reagle added the comment: Here's the error: ``` Traceback (most recent call last): File "", line 1, in File "src/lxml/etree.pyx", line 2291, in lxml.etree._ElementTree.xpath File "src/lxml/etree.pyx", line 1869, in lxml.etree._ElementTree._assertHasRoot AssertionError: ElementTree not initialized, missing root ``` -- ___ Python tracker <https://bugs.python.org/issue38910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38910] AssertionError: ElementTree not initialized, missing root
New submission from Joseph Reagle :
I've attached a simple XHTML file with which the 3.8 interpreter throws an
error on the following code, but 3.7 does not. (You'll have to change the path
in the code below.)
```
from io import StringIO, BytesIO
from lxml import etree
import os
import readline
HOME = os.path.expanduser("~")
ofile = HOME + '/data/2web/reagle.org/joseph/plan/plans/index.html'
plan_fd = open(ofile, 'r', encoding='utf-8', errors='replace')
plan_content = plan_fd.read()
plan_fd.close()
plan_tree = etree.parse(StringIO(plan_content),
etree.XMLParser(ns_clean=True, recover=True))
ul_found = plan_tree.xpath(
'''//x:div[@id='Done']/x:ul''',
namespaces={'x': 'http://www.w3.org/1999/xhtml'})
```
--
components: Library (Lib)
files: index.html
messages: 357465
nosy: joseph.reagle
priority: normal
severity: normal
status: open
title: AssertionError: ElementTree not initialized, missing root
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48742/index.html
___
Python tracker
<https://bugs.python.org/issue38910>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35922] robotparser crawl_delay and request_rate do not work with no matching entry
New submission from Joseph Myers :
RobotFileParser.crawl_delay and RobotFileParser.request_rate raise
AttributeError for a robots.txt with no matching entry for the given
user-agent, including no default entry, rather than returning None which would
be correct according to the documentation. E.g.:
>>> from urllib.robotparser import RobotFileParser
>>> parser = RobotFileParser()
>>> parser.parse([])
>>> parser.crawl_delay('example')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.6/urllib/robotparser.py", line 182, in crawl_delay
return self.default_entry.delay
AttributeError: 'NoneType' object has no attribute 'delay'
--
components: Library (Lib)
messages: 334982
nosy: joseph_myers
priority: normal
severity: normal
status: open
title: robotparser crawl_delay and request_rate do not work with no matching
entry
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue35922>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30670] pprint for dict in sorted order or insert order?
Joseph Shen added the comment: I reopened this issue, and change affected versions to 3.6, 3.7 and 3.8. -- status: closed -> open versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue30670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35324] ssl: FileNotFoundError when do handshake
New submission from joseph...@yahoo.com : After upgrade my python from 3.6 to 3.7, one of my program got following error msgs and I suppose it is related to the 'ssl' module: Traceback (most recent call last): File "M:\SUPPOR~1\ONEDAY~1\ODD2\lib\site-packages\urllib3\connectionpool.py", line 600, in urlopen chunked=chunked) File "M:\SUPPOR~1\ONEDAY~1\ODD2\lib\site-packages\urllib3\connectionpool.py", line 343, in _make_request self._validate_conn(conn) File "M:\SUPPOR~1\ONEDAY~1\ODD2\lib\site-packages\urllib3\connectionpool.py", line 839, in _validate_conn conn.connect() File "M:\SUPPOR~1\ONEDAY~1\ODD2\lib\site-packages\urllib3\connection.py", line 344, in connect ssl_context=context) File "M:\SUPPOR~1\ONEDAY~1\ODD2\lib\site-packages\urllib3\util\ssl_.py", line 357, in ssl_wrap_socket return context.wrap_socket(sock) File "f:\Anaconda3\Lib\ssl.py", line 412, in wrap_socket session=session File "f:\Anaconda3\Lib\ssl.py", line 853, in _create self.do_handshake() File "f:\Anaconda3\Lib\ssl.py", line 1117, in do_handshake self._sslobj.do_handshake() FileNotFoundError: [Errno 2] No such file or directory The background is, the program works all fine under python 3.6. I actually use the 'requests' lib which use the 'urllib3' inside. I don't know how to fix this so I just report here. I hope some one can help. -- assignee: christian.heimes components: SSL messages: 330491 nosy: christian.heimes, joseph...@yahoo.com priority: normal severity: normal status: open title: ssl: FileNotFoundError when do handshake type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34004] Acquiring locks not interrupted by signals on musl libc
Joseph Sible added the comment: Re musl changing their behavior, see https://www.openwall.com/lists/musl/2018/09/07/1 and the resulting thread. In addition to the old kernel version issue, two other issues were raised: 1. EINTR makes programming mistakes more likely, as people won't think to handle it. I don't give much weight to this point. 2. Most of the time, counting on receiving an EINTR results in race conditions. Our code seems to be affected by this too. Even on glibc, a signal at just the "right" time could result in it not being interrupted. This is why I think moving to an eventfd or something would be better, since we could then use pselect/ppoll/etc. to avoid the signal blocking race. -- ___ Python tracker <https://bugs.python.org/issue34004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34004] Acquiring locks not interrupted by signals on musl libc
Joseph Sible added the comment: How is this considered "fixed"? Why couldn't this be actually fixed by using eventfd instead of semaphores when they're available, for example? -- ___ Python tracker <https://bugs.python.org/issue34004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34584] subprocess
New submission from Joseph : Every time IDLE is opened this message "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection" shows up. When I open IDLE through .py programs the app crashes crash code: Process: Python [5021] Path: /Applications/Python 3.7/IDLE.app/Contents/MacOS/Python Identifier:org.python.IDLE Version: 3.7.0 (3.7.0) Code Type: X86-64 (Native) Parent Process:??? [1] Responsible: Python [5021] User ID: 501 Date/Time: 2018-09-05 17:09:24.893 +0800 OS Version:Mac OS X 10.13.4 (17E199) Report Version:12 Anonymous UUID:01609E2F-27A5-CB5F-4612-5BA977830EA2 Sleep/Wake UUID: 30FAEA7D-EBF8-44D0-AE53-A40B0636777A Time Awake Since Boot: 87000 seconds Time Since Wake: 510 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Reason:Namespace OBJC, Code 0x1 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x000101922ed6 __abort_with_payload + 10 1 libsystem_kernel.dylib 0x00010191d2cf abort_with_payload_wrapper_internal + 89 2 libsystem_kernel.dylib 0x00010191d276 abort_with_reason + 22 3 libobjc.A.dylib 0x000100e16962 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 108 4 libobjc.A.dylib 0x000100e16814 _objc_fatal(char const*, ...) + 135 5 libobjc.A.dylib 0x000100e21f63 (anonymous namespace)::AutoreleasePoolPage::busted(bool) + 123 6 libobjc.A.dylib 0x000100e09da5 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 79 7 com.apple.CoreFoundation0x000100047a56 _CFAutoreleasePoolPop + 22 8 com.apple.Foundation0x000103ee28ad -[NSAutoreleasePool drain] + 144 9 com.apple.Foundation0x000103f165a4 _NSAppleEventManagerGenericHandler + 120 10 com.apple.AE0x00010a9ccdd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788 11 com.apple.AE0x00010a9cc677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41 12 com.apple.AE0x00010a9cc565 aeProcessAppleEvent + 383 13 com.apple.HIToolbox 0x0001078ad4a0 AEProcessAppleEvent + 55 14 com.apple.AppKit0x0001045e1d32 _DPSNextEvent + 2788 15 com.apple.AppKit0x000104d77e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 16 libtk8.6.dylib 0x000103d4594a -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 44 17 com.apple.AppKit0x000104813e7b -[NSApplication _doModalLoop:peek:] + 476 18 com.apple.AppKit0x0001049f8c9f __35-[NSApplication runModalForWindow:]_block_invoke_2 + 64 19 com.apple.AppKit0x0001049f8c4c __35-[NSApplication runModalForWindow:]_block_invoke + 75 20 com.apple.AppKit0x000104ea7219 _NSTryRunModal + 100 21 com.apple.AppKit0x000104811911 -[NSApplication runModalForWindow:] + 133 22 com.apple.AppKit0x0001049e6eab __19-[NSAlert runModal]_block_invoke_2 + 158 23 com.apple.AppKit0x0001049e6dfa __19-[NSAlert runModal]_block_invoke + 75 24 com.apple.AppKit0x000104ea7219 _NSTryRunModal + 100 25 com.apple.AppKit0x000104886609 -[NSAlert runModal] + 124 26 libtk8.6.dylib 0x000103d32f31 Tk_MessageBoxObjCmd + 2098 27 libtcl8.6.dylib 0x000103b12f08 TclNRRunCallbacks + 58 28 _tkinter.cpython-37m-darwin.so 0x000101beebf7 Tkapp_Call + 183 29 org.python.python 0x00010077aa7b cfunction_call_varargs + 299 30 org.python.python 0x000100856376 _PyEval_EvalFrameDefault + 28614 31 org.python.python 0x00010084e740 _PyEval_EvalCodeWithName + 3088 32 org.python.python 0x00010077a50a _PyFunction_FastCallKeywords + 218 33 org.python.python 0x00010084f04f call_function + 671 34 org.python.python 0x00010085243d _PyEval_EvalFrameDefault + 12429 35 org.python.python 0x00010084e740 _PyEval_EvalCodeWithName + 3088 36 org.python.python 0x00010077a795 _PyFunct
[issue34584] subprocess
Joseph added the comment: Problem saved... turns out I saved a math.py file in my python location and thats what cause the crash. when i remove the math.py file or change its name, python got back to work. thanks -- ___ Python tracker <https://bugs.python.org/issue34584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34584] subprocess
Change by Joseph : -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue34584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34006] Windows HTML Help (chm) has fixed line length
Change by Joseph L. Casale : -- nosy: -jcasale ___ Python tracker <https://bugs.python.org/issue34006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34006] Windows HTML Help (chm) has fixed line length
Change by Joseph L. Casale : -- nosy: +jcasale ___ Python tracker <https://bugs.python.org/issue34006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34004] Acquiring locks not interrupted by signals on musl libc
New submission from Joseph Sible : When Python is built on Alpine Linux or in any other configuration that uses musl libc, calls to Lock.acquire() can't be interrupted by signals. This bug is caught by test_lock_acquire_interruption and test_rlock_acquire_interruption in 3.6/Lib/test/test_threadsignals.py, both of which fail when Python is built on musl. POSIX explicitly says that sem_timedwait ever failing with EINTR is optional: http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_timedwait.html#tag_16_508_05 And musl deliberately chooses not to support it: http://www.openwall.com/lists/musl/2018/02/24/3 http://git.musl-libc.org/cgit/musl/commit/?id=c0ed5a201b2bdb6d1896064bec0020c9973db0a1 However, we incorrectly rely on it for correct operation. Our documentation https://docs.python.org/3.6/library/threading.html#threading.Lock.acquire just says that "Lock acquires can now be interrupted by signals on POSIX", not that any optional POSIX features are required for it. A similar bug was #11223, which was the same problem but with pthread_cond_timedwait, which is used when semaphores aren't available. -- components: Extension Modules messages: 320742 nosy: Joseph Sible priority: normal severity: normal status: open title: Acquiring locks not interrupted by signals on musl libc type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33646] os.fspath() bypasses __fspath__ for str subclasses
New submission from Joseph Martinot-Lagarde :
os.fspath() returns its argument if it is a str. That means that it bypasses
__fspath__ for str subclasses.
This is the case for the library path.py for example.
This is a corner case that was discovered while trying to fix
https://github.com/matplotlib/matplotlib/issues/11306
Minimal example:
```
import os
class MyPath(str):
def __fspath__(self):
print("Returns a pure string")
return str(self)
os.fspath(MyPath()) # Prints nothing
```
--
components: Library (Lib)
messages: 317666
nosy: contrebasse
priority: normal
severity: normal
status: open
title: os.fspath() bypasses __fspath__ for str subclasses
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue33646>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29504] blake2: compile error with -march=bdver2
Joseph Mitzen added the comment: Is this ever going to get merged? The gentoo bug report link includes a patch that simply removes the nested comments, which is all that is needed to get the code to compile properly on Bulldozer processors. There's no "manual massaging" or anything else necessary to fix the bug. I've tested it out and it works. -- nosy: +Joseph Mitzen ___ Python tracker <https://bugs.python.org/issue29504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32393] nav menu jitter in old documentation
New submission from Joseph Hendrey : The sidebar navigation menu jitters when scrolling on the 2.7 documentation pages (at least in Chrome). A seemingly unrelated issue is that the collapse symbol '<<' is a fixed distance from the top of the page rather than staying in the centre (height-wise) of the screen (it should always be visible). It seems it has been fixed for newer documentation, but since the fix is so simple it would be nice to fix it for the old documentation too. Setting the position property of the span element seems to fix both issues for me (see attached screenshot) -- assignee: docs@python components: Documentation files: screenshot.JPG messages: 308834 nosy: Joseph Hendrey, docs@python priority: normal severity: normal status: open title: nav menu jitter in old documentation type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file47343/screenshot.JPG ___ Python tracker <https://bugs.python.org/issue32393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
Joseph Fox-Rabinovitz added the comment: I brought up the issue because it was really a point of confusion for me. Could we make the change to "Roughly equivalent" and make that a link to https://docs.python.org/3/reference/datamodel.html#special-method-lookup? That would make it clear how the lookup is actually done. While I agree that making the docs unnecessarily pedantic is probably a bad thing, I am going to guess that I am not the only person that looks to them for technical accuracy. Regards, -Joe On Thu, Jul 27, 2017 at 4:04 PM, R. David Murray wrote: > > R. David Murray added the comment: > > I agree with Raymond. I'm not sure that adding roughly is going to > decrease the possibility of confusion, but I won't object to it. > > In a way, it's too bad we didn't make the attribute lookup machinery look > up all dunder methods on the class, so that a.__index__ would call the > class method. I think backward compatibility prevented that. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue31042> > ___ > -- ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
New submission from Joseph Fox-Rabinovitz: The docs for [`operator.index`][1] and `operator.__index__` state that > Return *a* converted to an integer. Equivalent to `a.__index__()`. The first sentence is correct, but the second is not. First of all, we have the data model [docs][2]: > For custom classes, implicit invocations of special methods are only > guaranteed to work correctly if defined on an object’s type, not in the > object’s instance dictionary. Secondly, we can make a simple counter-example in code: ``` import operator class A: def __index__(self): return 0 a = A() a.__index__ = (lambda self: 1).__get__(a, type(a)) operator.index(a) ``` The result is of course zero and not one. I believe that the docs should read something more like one of the following to avoid being misleading: > Return *a* converted to an integer, if it is already an integral type. > Return *a* converted to an integer. Equivalent to `type(a).__index__(a)`. Or a combination of both: > Return *a* converted to an integer, if it is already an integral type. > Equivalent to `type(a).__index__(a)`. [1]: https://docs.python.org/3/library/operator.html#operator.index [2]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup -- assignee: docs@python components: Documentation messages: 299195 nosy: docs@python, madphysicist priority: normal severity: normal status: open title: Inconsistency in documentation of operator.index type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
Changes by Joseph Fox-Rabinovitz : -- type: behavior -> ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30670] pprint for dict in sorted order or insert order?
New submission from Joseph Shen: start from 3.6+, dict keys are ordered heir creation order. the builtin print function works as we expected, but for pprint, the keys is sorted. should we using the sorted version or just obey the creation order as builtin print? -- components: Library (Lib) messages: 296056 nosy: josephsmeng priority: normal severity: normal status: open title: pprint for dict in sorted order or insert order? type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29059] Windows: Python not using ANSI compatible console
Joseph Hackman added the comment: Thanks for the tip! If you hadn't said that, I probably would have written it into the init scripts. I'll try to write something for python-ideas / PEP tomorrow, but have attached a quick patch here so I can link to this issue for an example implementation. -- keywords: +patch Added file: http://bugs.python.org/file46060/issue29059.patch ___ Python tracker <http://bugs.python.org/issue29059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29080] unnecessary hg required for build version 3.6 on Windows
New submission from Joseph Shen: the released 3.6.0 PCbuild/build.bat required hg for building. but this requirement is not necessary for build python from source. maybe it will be better for us to remove this requirement as the old versions. -- components: Build messages: 284078 nosy: Joseph.Shen priority: normal severity: normal status: open title: unnecessary hg required for build version 3.6 on Windows type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29059] Windows: Python not using ANSI compatible console
Joseph Hackman added the comment: The flag is application specific. I.e. a python program that writes to console using ansi codes, when used on windows, will just display the codes. If the Output is redireced to file and then the file is printed to console using a console tool, the colors will show instead. -- ___ Python tracker <http://bugs.python.org/issue29059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29059] Windows: Python not using ANSI compatible console
New submission from Joseph Hackman: On windows, Python does not request that Windows enable VT100 for console output for Python. That is to say that ANSI codes such as \033[91m will function on Mac and Linux Pythons, but not Windows. As there is no good interface in core Python to the kernel32 console operations (and there probably shouldn't be, it would be better to be consistent), I suggest just flipping the bit at startup on Windows. I would be happy to submit a patch, but seek guidance on the best location for addition of code to 'at startup iff a tty is attached'. The following code solves the issue: import platform if platform.system().lower() == 'windows': from ctypes import windll, c_int, byref stdout_handle = windll.kernel32.GetStdHandle(c_int(-11)) mode = c_int(0) windll.kernel32.GetConsoleMode(c_int(stdout_handle), byref(mode)) mode = c_int(mode.value | 4) windll.kernel32.SetConsoleMode(c_int(stdout_handle), mode) Please see: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx (Search for ENABLE_VIRTUAL_TERMINAL_PROCESSING) https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=vs.85).aspx (As for why stdout is -11 on Windows) -- components: Windows messages: 283913 nosy: joseph.hackman, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows: Python not using ANSI compatible console type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue29059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Changes by Joseph L. Casale : -- nosy: +jcasale ___ Python tracker <http://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: Oh, can't believe this, and I thought iPhone 8 will bring back my lovely 3.5mm jack ^_^ On Sat, Sep 10, 2016 at 22:16 Zachary Ware wrote: > > Zachary Ware added the comment: > > Joseph: "plat-win" was actually removed from the comment in #28046; it is > an obsolete name that hasn't been used since August 21, 2000. I just > killed the platform directories, let's not bring them back :) > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: Yeah it's true, anyway thanks for your support On Sat, Sep 10, 2016 at 22:10 Steve Dower wrote: > > Steve Dower added the comment: > > I don't intend to change any defaults arbitrarily, but you can easily > specify a folder with whatever name you like for these. I agree it would be > a more sensible name, but it's such a minor issue that change would be more > disruptive than helpful. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: I noticed someone use `plat-win` instead of `DLLs` in this http://bugs.python.org/issue28046, so what's your opinion for this? `plat-win` looks more meaningful than old `DLLs` at least for me, do your have any plan for this in the 3.6 release? -- ___ Python tracker <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: thanks for the comment and make python work on Windows better :) I will trace the 3.6 source code. On Sat, Aug 27, 2016 at 8:58 PM Steve Dower wrote: > > Steve Dower added the comment: > > I don't entirely agree with the analysis or suggestions here, but I do > intend to change this for 3.6 so I'll assign myself. At the very least, we > won't fall back on totally relative paths - we'll make them absolute from > the program directory. > > -- > assignee: -> steve.dower > resolution: not a bug -> > stage: resolved -> needs patch > versions: +Python 3.6 -Python 3.5 > > ___ > Python tracker > <https://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <https://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: I don't know how to reopen this issue, please make some comments for what I added just now, thanks. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: Yea, thanks for review, I knew the pyven. But the behavior right now is really what I think unnecessary complicated and confusing. What I think, we all knew the DLLs is used for python keep the *.pyd (actually just dll), so by default, why we want this directory relative to the working directory? indeed the configure file can fix this, but is this process really what we needed? we need check the PYTHONHOME , read the registy, check if the configure file exist, just for make python find the libraries? I knew python has a long history for keep the library path environment variable work right, and not even mention pyenv and some other tools, but this just make things more complicated. So, as a conclusion, I think we should make the sys.path consistent with or without using zip packed library, especially for the DLLs if we think about some backward compatibility.fix this is just a small step for making python application launch faster and packing simpler. Thanks, I think this problem still arguable. On Sat, Aug 27, 2016 at 17:38 Eryk Sun wrote: > > Eryk Sun added the comment: > > Windows Python determines sys.prefix (i.e. the location of the standard > library, \lib) via either the PYTHONHOME environment variable or by > searching for the landmark "lib/os.py", starting in the application > directory and reducing back to the root directory [1]. > > If it can't find the prefix directory; PYTHONPATH isn't defined; and it > can't find PythonPath in the registry; then it adds the "DLLs" and "lib" > directories relative to the working directory. This default PYTHONPATH is > defined in PC/pyconfig.h as ".\\DLLs;.\\lib". > > There is an alternative "applocal" (application local) mode. Create a file > named pyvenv.cfg beside python.exe that contains the single line > > applocal = true > > This prevents Python from checking PYTHONHOME and PYTHONPATH, the > registry, and prevents searching for the "lib/os.py" landmark. sys.prefix > is set as the application directory, and the default "DLLs" and "lib" paths > are expanded relative to the application directory. > > Anyway, since what you're reporting is the expected behavior, I'm closing > this issue. Feel free to reopen it if you feel I've misdiagnosed the > problem or think the default behavior is somehow broken. I don't know what > Steve Dower's plans are, if indeed he has any, to change the legacy > sys.path behavior in future releases. > > > [1]: The reduce() function in PC/getpathp.c has a minor bug that > results in sys.prefix set as the drive-relative path "C:" if > the landmark search continues to the root and "C:/lib/os.py" > exists. This is due to the way it overwrites the path separator > with NUL to reduce the path. I think it should keep the > separator. The join() function works either way. > > -- > nosy: +eryksun > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <https://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: second snapshot -- Added file: https://bugs.python.org/file44239/2016-08-27_15-09-45.png ___ Python tracker <https://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
New submission from Joseph Shen: Found a inconsistent sys.path result when python packed with it's library with zip package. A. when NOT use zip package sys.path is base the python.exe's absolute path, result is 1. ABS_PATH\pythonXX.zip 2. ABS_PATH\DLLs 3. ABS_PATH\lib, 4. ABS_PATH 5. ABS_PATH\lib\site-packages B. when use zip package sys.path is base the relative path of call path, result is 1. ABS_PATH\pythonXX.zip 2. RLT_PATH\DLLs 3. RLT_PATH\lib, 4. ABS_PATH this is not commonly expected for the `DLLs` and `lib`, I think the result will still be absolute path for where the executable located. I snapshot two pictures for this problem, please review this, thanks. -- components: Windows files: 2016-08-27_15-09-39.png messages: 273763 nosy: Joseph.Shen, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: inconsistent sys.path behavior when using PythonXX.zip type: behavior versions: Python 3.5 Added file: https://bugs.python.org/file44238/2016-08-27_15-09-39.png ___ Python tracker <https://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27721] distutils strtobool returns 0 and 1 rather than False and True
Joseph Bane added the comment: Thank you for your feedback. I definitely understand your reasoning and commitment to not introducing breaking changes in externally facing codes. I also agree that this does fall slightly more on the side of aesthetic rather than functional changes. However, this change doesn't seem like it is significantly altering the interface of strtobool; if anything it is making it clearer and less surprising, especially for Python 2/3+ users. I know, as someone in that category, having learned Python at version 2.5, that it was a bit surprising when I got back an integer from this function rather than the native True and False values. I also want to emphasize that this change is specifically targeting Python 3.6, not 2.7, 3.4, or 3.5. Making this small change in a not-yet-released version should be safe, but, of course, that is my outsider opinion. You absolutely have a valid point if I were asking that we change a released version and it is not something I take lightly. Lastly, this is the kind of change I would hope I could make easily as a first time contributor to the project because of it being more of an aesthetic one. After all, isn't the whole point of making changes to a project about making it cleaner, modern, and clearer? Thanks again. I really appreciate the feedback and discussion. P.S. If there is support to introduce this change, I will certainly update the tests and docs as pointed out. -- ___ Python tracker <http://bugs.python.org/issue27721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27721] distutils strtobool returns 0 and 1 rather than False and True
Joseph Bane added the comment: Thank you for the feedback. Please find an updated patch attached. -- Added file: http://bugs.python.org/file44061/patch.diff ___ Python tracker <http://bugs.python.org/issue27721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27721] strtobool returns 0 and 1 rather than False and True
New submission from Joseph Bane: The distutils strtobool function returns 0 or 1 rather than the native boolean type True or False values: https://hg.python.org/cpython/file/3.5/Lib/distutils/util.py#l304 Please see the attached patch for updates to this function. I have included updates to use a f-string in the raise and casefold instead of lower. -- components: Distutils files: patch.diff keywords: patch messages: 272263 nosy: Joseph Bane, dstufft, eric.araujo priority: normal severity: normal status: open title: strtobool returns 0 and 1 rather than False and True type: enhancement versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file44060/patch.diff ___ Python tracker <http://bugs.python.org/issue27721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs
Joseph Hackman added the comment: Updated documentation in fileinput.rst, Doc/whatsnew/3.6.rst, Misc/NEWS and Misc/ACKS. Thank you so much Serhiy for taking the time to review! -- Added file: http://bugs.python.org/file42631/issue25788-3.patch ___ Python tracker <http://bugs.python.org/issue25788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs
Joseph Hackman added the comment: Uploading a new patch to address the issues in previous patch. -- Added file: http://bugs.python.org/file42620/issue25788-2.patch ___ Python tracker <http://bugs.python.org/issue25788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs
Joseph Hackman added the comment: Ping. Just wondering if anyone on the nosy list would be willing to help review my patch. :) -- ___ Python tracker <http://bugs.python.org/issue25788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26322] Missing docs for typing.Set
Joseph Moran added the comment: Deleted second ABSTRACTSET and added SET in typing docs -- nosy: +joegotflow83 Added file: http://bugs.python.org/file42109/26322 ___ Python tracker <http://bugs.python.org/issue26322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Changes by Joseph Hackman : -- nosy: +Joseph.Hackman ___ Python tracker <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs
Joseph Hackman added the comment: I haven't seen OP in over 30 days, so am posting my own patch. I've added an optional argument that defaults to strict and gets passed along. I've updated the primary test to verify the argument passing, as well as that things get handled as specified in the documentation at https://docs.python.org/3.5/library/codecs.html This is off-topic, but is there any way I can submit a patch that allows a similar fix for stdin? Presently there is no way at all to pass malformed unicode through fileinput using stdin that I can find. -- keywords: +patch nosy: +Joseph Hackman Added file: http://bugs.python.org/file41777/issue25788.patch ___ Python tracker <http://bugs.python.org/issue25788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26091] decimal.Decimal(0)**0 throws decimal.InvalidOperation
Changes by Joseph Pyott : -- components: +Library (Lib) -Extension Modules ___ Python tracker <http://bugs.python.org/issue26091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26091] decimal.Decimal(0)**0 throws decimal.InvalidOperation
Changes by Joseph Pyott : -- components: Extension Modules files: decimal pow error.py nosy: Pyottamus priority: normal severity: normal status: open title: decimal.Decimal(0)**0 throws decimal.InvalidOperation type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41593/decimal pow error.py ___ Python tracker <http://bugs.python.org/issue26091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock
Joseph Gordon added the comment: I uploaded a patch that appears to fix the issue. -- keywords: +patch Added file: http://bugs.python.org/file41396/issue25599.patch ___ Python tracker <http://bugs.python.org/issue25599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23846] asyncio : ProactorEventLoop raised BlockingIOError when ThreadPoolExecutor has many workers
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue23846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19873] There is a duplicate function in Lib/test/test_pathlib.py
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue19873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25324] Importing tokenize modifies token
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue25324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25597] unittest.mock does not wrap dict objects correctly
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue25597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue25599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25661] tokenize.untokenize does not maintain the order of tabbed indentations and leading spaces
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue25661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25664] Logging cannot handle Unicode logger names
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue25664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3
Joseph Gordon added the comment: With the changes in the uploaded patch it looks like strings of the form rb'...' are now recognized as raw byte strings. -- keywords: +patch Added file: http://bugs.python.org/file41382/issue23894.patch ___ Python tracker <http://bugs.python.org/issue23894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue23894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24249] unittest API for detecting test failure in cleanup/teardown
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue24249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14019] Unify tests for str.format and string.Formatter
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue14019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Changes by Joseph Gordon : -- nosy: +josephgordon ___ Python tracker <http://bugs.python.org/issue11551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24921] Operator precedence table in 5.15 should be highest to lowest precedence
New submission from Joseph Schachner: We should not make people who need to read Python documentation do an extra transformation in their heads to correctly understand that in section 5.15 higher precedence is at the bottom of the table and lower precedence is at the top. Because the documentation has this table inverted from the way it is usually presented in other references, one of the top hits in a Google search shows an instructor felt the need to make a version in the usual "high to low precedence" order to show students, see: http://www.mathcs.emory.edu/~valerie/courses/fall10/155/resources/op_precedence.html That version is so much more comfortable for me to read, it seems almost strange, but it is true. Please consider changing section 5.15 so it would not need the top paragraph explaining that the table order is not what the reader probably expects, instead just present the table as at the link above - in the order the reader does expect - higher precedence on top, lower on the bottom. That only needs two short sentences of explanation that don't make the reader think "wait ... what?" -- assignee: docs@python components: Documentation messages: 249046 nosy: Joseph Schachner, docs@python priority: normal severity: normal status: open title: Operator precedence table in 5.15 should be highest to lowest precedence versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue24921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24808] PyTypeObject fields have incorrectly documented types
New submission from Joseph Weston: Several fields in the Python 3.x documentation for the PyTypeObject API have incorrectly documented types. This was probably due to a wholesale shift of documentation from Python 2.x. -- assignee: docs@python components: Documentation files: PyTypeObject_documentation.patch keywords: patch messages: 248123 nosy: Joseph Weston, docs@python priority: normal severity: normal status: open title: PyTypeObject fields have incorrectly documented types type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40136/PyTypeObject_documentation.patch ___ Python tracker <http://bugs.python.org/issue24808> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22934] Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
New submission from joseph: Since the changeset 91853:88a532a31eb3 _freeze_importlib.c resides in the Programs dir. The header comment of Python/importlib.h should be changed to reflect this. -- components: Build files: freeze_importlib_comment.patch keywords: patch messages: 231617 nosy: crozzy priority: normal severity: normal status: open title: Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment versions: Python 3.5 Added file: http://bugs.python.org/file37267/freeze_importlib_comment.patch ___ Python tracker <http://bugs.python.org/issue22934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22872] multiprocessing.Queue raises AssertionError
New submission from Joseph Siddall:
putting something in Queue(multiprocessing.Queue) after closing it raises an
AssertionError.
Getting something out of a Queue after closing it raises an OSError.
I expected both scenarios to raise the same exception.
To Reproduce:
>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.put("ok")
Traceback (most recent call last):
...
AssertionError
>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.get()
Traceback (most recent call last):
...
OSError: handle is closed
--
components: Library (Lib)
messages: 231164
nosy: Joseph.Siddall
priority: normal
severity: normal
status: open
title: multiprocessing.Queue raises AssertionError
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue22872>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21091] EmailMessage.is_attachment should be a method
Joseph Godbehere added the comment: Very good point, Serhiy. Here is an alternative patch, which instead changes Message.is_multipart from a method to a property as per your suggestion. This way incorrect usage should fail noisily. This patch is against the relevant docs, tests, is_multipart and calls to is_multipart only. -- Added file: http://bugs.python.org/file36249/multipart_is_property.patch ___ Python tracker <http://bugs.python.org/issue21091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
