Kevin Shweh added the comment:
Frankly, it doesn't make sense that isgeneratorfunction or iscoroutinefunction
unwrap partials at all. The original justification for making them do that back
in https://bugs.python.org/issue34890 was invalid - the original argument was
that isfunction unwraps
Kevin Shweh added the comment:
The PR you submitted doesn't work, unfortunately. It essentially reintroduces
issue 45274. If this line:
if locked := lock.acquire(block, timeout):
gets interrupted between the acquire and the assignment, locked is still False.
That's rare, but so
Kevin Shweh added the comment:
Issue 45274 was a subtly different issue. That was a problem that happened if
the thread got interrupted *between* the acquire and the release, causing it to
*not* release the lock and *not* perform end-of-thread cleanup.
The fix for that issue caused
New submission from Kevin Shweh :
This code in Thread._wait_for_tstate_lock:
try:
if lock.acquire(block, timeout):
lock.release()
self._stop()
except:
if lock.locked():
# bpo-45274: lock.acquire() acquired the lock, but the function
Kevin Shweh added the comment:
Almost - C's weird bitwise operator precedence means it has to be parenthesized
as
if ((kind & _odict_ITER_ITEMS) == _odict_ITER_ITEMS)
--
___
Python tracker
<https://bugs.python.org/iss
New submission from Kevin Shweh :
The OrderedDict iterator caches a di_result tuple for use with
iter(od.items()). It's *supposed* to only do that for the items() case, but the
code does
if (kind & (_odict_ITER_KEYS | _odict_ITER_VALUES))
to test for this case. This is the wrong
New submission from Kevin Shweh :
The data model docs for __new__ say "If __new__() is invoked during object
construction and it returns an instance or subclass of cls, then the new
instance’s __init__() method will be invoked..."
"instance or subclass of cls" is inc
Kevin Shweh added the comment:
Of course it's reasonable to support dict subclasses. We already have a bunch
of dict subclasses in the standard library, like collections.defaultdict and
collections.Counter, and collections.Counter is significantly slower than it
could be because
Kevin Shweh added the comment:
It seems like the straightforward, minimal fix would be to just add
if (getattr(cls, '_is_protocol', False) and
not getattr(cls, '_is_runtime_protocol', False) and
not _allow_reckless_class_cheks()):
raise TypeError(...)
to _ProtocolMeta
New submission from Kevin Shweh :
A global declaration inside a function is only supposed to affect assignments
inside that function, but in code executed with exec, a global declaration
affects assignments outside the function:
>>> gdict = {}
>>> ldict = {}
>>>
New submission from Kevin Shweh :
The following code:
from dataclasses import dataclass, field
from typing import Callable
@dataclass
class Foo:
callback: Callable[[int], int] = lambda x: x**2
@dataclass
class Bar:
callback: Callable[[int
Kevin Shweh added the comment:
Looks like I accidentally doubled the PyMemberDef for __weakrefoffset__ while
editing. There's no double definition in the actual file.
--
___
Python tracker
<https://bugs.python.org/issue36
New submission from Kevin Shweh :
In Objects/typeobject.c, the PyMemberDefs for __flags__, __weakrefoffset__, and
__dictoffset__ all use T_LONG:
{"__flags__", T_LONG, offsetof(PyTypeObject, tp_flags), READONLY},
{"__weakrefoffset__", T_LONG,
o
New submission from Kevin Shweh :
LOAD_NAME and LOAD_GLOBAL don't treat dict subclasses for globals() the same
way. If globals() is a dict subclass, LOAD_GLOBAL will respect overridden
__getitem__, but LOAD_NAME will use PyDict_GetItem. This causes global lookup
to behave differently
Kevin Shweh added the comment:
The patch for this issue changed LOAD_GLOBAL to use PyObject_GetItem when
globals() is a dict subclass, but LOAD_NAME, STORE_GLOBAL, and DELETE_GLOBAL
weren't changed. (LOAD_NAME uses PyObject_GetItem for builtins now, but not for
globals.)
This means
Kevin Shweh <kevin.sh...@gmail.com> added the comment:
It looks to me like there are more situations than the patch lists where
whitespace still separates tokens. For example, *? is a reluctant quantifier
and * ? is a syntax error, even in verbose mode.
--
nosy: +Kevin
New submission from Kevin Shweh:
The only check that prevents instantiating abstract classes is in
object.__new__, but most built-in classes never actually call object.__new__.
That means you can do stuff like
import abc
class Foo(list, metaclass=abc.ABCMeta):
@abc.abstractmethod
Kevin Shweh added the comment:
Doesn't that ignore_extra_args thing prevent InitX.__init_subclass__ from
receiving the x argument it wanted? It doesn't seem like a solution.
--
nosy: +Kevin Shweh
___
Python tracker <rep...@bugs.python.org>
Kevin Shweh added the comment:
A type-based check runs into problems with 0.0 vs -0.0. For example, on Python
2.7.11:
>>> x, y = lambda: 0.0, lambda: -0.0
>>> y()
0.0
I wasn't able to reproduce the -0.0 problem with Python 3.4 on Ideone;
y.__code__.co_consts seems to
Kevin Shweh added the comment:
It looks like the fast paths for INPLACE_ADD and INPLACE_SUBTRACT in Python 2
don't have the cast-to-unsigned fix, so they're still relying on undefined
behavior. For example, in INPLACE_ADD:
/* INLINE: int + int */
register long
20 matches
Mail list logo
