Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue29258>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
A relevant old issue is https://bugs.python.org/issue6647
--
components: +Library (Lib)
nosy: +Eric Wieser
type: -> behavior
___
Python tracker
<https://bugs.python.org/issu
Eric Wieser added the comment:
If the resolution here is that this is behaving as intended (which personally I
disagree with), I think this issue should remain open as a documentation task -
the docs should clearly state that this does not apply to PEP420 namespace
packages
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue39471>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Wieser :
Right now, the behavior is:
>>> import numpy as np
>>> arr_0d = np.array(42)
>>> mem_0d = memoryview(arr_0d)
>>> len(mem_0d)
1
>>> mem_0d[0]
TypeError: invalid indexing of 0-dim memory
It seems bizarre to have this
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +17836
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18463
___
Python tracker
<https://bugs.python.org/issu
Eric Wieser added the comment:
Thanks for pointing out the docs reference, I updated the patch to reword that
section.
There's a sentence right before the one you draw attention to which to me reads
as another argument to change this:
> ``len(view)`` is equal to the length o
Eric Wieser added the comment:
Nothing holding it up from my end, just waiting on someone to review it.
Perhaps this ping will help with that.
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue34
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue37881>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue23967>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
> To make this work I had to write an ast printer that produces evaluatable
> Python code. Note that it's not complete, I know it's not complete, it's
> missing loads of operators. Assume that if this is a good idea I will add
>
New submission from Eric Wieser :
Consider a class like
class MyClass:
x: int
y: int
Which has
>>> MyClass.__annotations__
{'x': int, 'y': int}
In future, it might change to
class MyClass:
@proper
Change by Eric Wieser :
--
keywords: +patch
nosy: +Eric.Wieser
nosy_count: 1.0 -> 2.0
pull_requests: +19361
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20052
___
Python tracker
<https://bugs.python.org/i
Eric Wieser added the comment:
This seems somewhat related to https://bugs.python.org/issue31939
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue37
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue31861>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Wieser :
Python distinguishes signed zeros by their repr:
# floats
>>> 0.0
0.0
>>> -0.0
-0.0
# complex
>>> complex(0.0, 0.0) # A
0j
>>> complex(0.0, -0.0) # B
-0j
>>> complex(-0.0, 0.0) # C
(-0+0j)
>>> comple
Eric Wieser added the comment:
This was reported and closed in https://bugs.python.org/issue17336, but it
seems to me that this is easy to avoid - have `__repr__` return `complex(...)`
for values which do not round-trip.
--
___
Python tracker
Eric Wieser added the comment:
Apologies for not searching the issue tracker effectively until after filing
this.
--
___
Python tracker
<https://bugs.python.org/issue41
Eric Wieser added the comment:
> BTW I don't want repr() of a complex number to use the complex(..., ...)
A compromise would be to only use this notation if signed zeros are involved.
---
Another option would be to use slightly unusual reprs for these complex
numbers, which at lea
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue41584>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Wieser :
The full definition of `multiprocessing.heap.BufferWrapper` is:
class BufferWrapper(object):
_heap = Heap()
def __init__(self, size):
if size < 0:
raise ValueError("Size {0:n} out of range"
Eric Wieser added the comment:
Whoops, typo. `>>> b[0]` should read `m[0]`.
--
___
Python tracker
<https://bugs.python.org/issue41673>
___
___
Python-bu
New submission from Eric Wieser :
This behavior is pretty surprising:
```python
import ctypes
class Simple(ctypes.Structure):
_fields_ = [
('a', ctypes.c_uint8),
('b', ctypes.c_uint8),
]
class Bitfields(ctypes.Structure):
_fields_ = [
New submission from Eric Wieser :
Introduced in the fix to bpo-36504, GH-12660.
```python
>>> (ctypes.c_uint8 * 0 * 2)()
Fatal Python error: Floating point exception
>>> struct Empty(ctypes.Structure): _fields_ = []
>>> (Empty * 2)()
Fatal Python error: Floating poi
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +13759
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13881
___
Python tracker
<https://bugs.python.org/issu
Change by Eric Wieser :
--
components: +ctypes
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue37187>
___
___
Python-bugs-list mai
Change by Eric Wieser :
--
components: +ctypes
___
Python tracker
<https://bugs.python.org/issue37188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Wieser :
--
pull_requests: +13779
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/13906
___
Python tracker
<https://bugs.python.org/issu
Eric Wieser added the comment:
Pinging again, now that the patch has undergone a revision with some cleanup
thanks to @skrah
--
___
Python tracker
<https://bugs.python.org/issue32
Changes by Eric Wieser :
--
nosy: +Eric.Wieser
___
Python tracker
<http://bugs.python.org/issue30140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
> Revising the code example to use an empty array
I think you mean
>>> import array
>>> memoryview(array.array('H', [])).itemsize
2
Your example is an array containing 0, not an empty array - but the conclusion
is the same.
&
New submission from Eric Wieser :
Discovered [here](https://github.com/numpy/numpy/issues/10528)
Consider the following structure, and a memoryview created from it:
class foo(ctypes.Structure):
_fields_ = [('one', ctypes.c_uint8),
('two', cty
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +5383
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32780>
___
___
Python-
Change by Eric Wieser :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue32780>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Eric Wieser :
Take the following simple structure:
class Foo(ctypes.Structure):
_fields_ = [('f', ctypes.uint32_t)]
And construct some arrays with it:
def get_array_view(N):
return memoryview((Foo * N)())
In most cases, this works a
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +5394
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32782>
___
___
Python-
Eric Wieser added the comment:
Would it be possible for function self-reference cell vars to be weak
references?
This wouldn't solve the issue for co-recursive inner functions, but would at
least prevent reference cycles for the more common case of simple recursive
func
Eric Wieser added the comment:
> Are you suggesting that _if_ they were to implement `as_integer_ratio` at
> some point in the future, then they'd become compatible with `Fraction`
Yes, exactly. Conversely, there's little gain in implementing it _until_
`Fraction` sup
New submission from Eric Wieser :
Discovered in https://github.com/numpy/numpy/pull/10882/files#r180813166
A reproduction:
```
In [1]: import ctypes
In [2]: def make_array_ctype(shape):
...: import ctypes
...: ct = ctypes.c_uint8
...: for i in shape:
...: ct = i
Eric Wieser added the comment:
Apologies, I missed the important part of that snippet:
```
In [3]: gc.collect(); x = make_array_ctype((1,)); del x; gc.collect()
Out[3]: 7
```
--
___
Python tracker
<https://bugs.python.org/issue33
Eric Wieser added the comment:
> allows Fraction instantiation from duck-typing classes that provide
> as_integer_ratio
This would allow the numpy `np.floating` types to take part in `Fraction`
conversion as well, which would be great.
As far as I can tell, `Decimal` already follow
Eric Wieser added the comment:
Not necessarily an argument against this feature, but two workarounds exist for
this already:
1. Use `nonlocal` to prevent `value` going into the class namespace:
value = None
class BaudRate(enum.Enum):
nonlocal value
for value
New submission from Eric Wieser :
PEP 442 states that:
> Two new C API functions are provided to ease calling of tp_finalize,
> especially from custom deallocators.
But it does not give the names of these functions, nor do any python docs I can
discover.
>From grepping for tp_fin
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
PEP3118 as a protocol is far less useful if the canonical implementation is
non-compliant.
--
___
Python tracker
<ht
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
Ideally this and https://bugs.python.org/issue32780 would make the same patch
release.
--
___
Python tracker
<https://bugs.python.
Eric Wieser added the comment:
> It should be fairly simple to modify the code to use a format of "B"
> for unions, so that it at least matches the itemsize
Seems reasonable, although:
* I think it should be "B" or "()B"
* I'd rather leave that for
Eric Wieser added the comment:
> I get the following results for builtin objects that have defined subclasses
>From that list, the only unhelpful ones with > 4 items, in my opinion, appear
>to be `object`, since that just tells you every type that exists, and `tuple`,
>bec
Eric Wieser added the comment:
This now leaves `inspect.getsource` inconsistent with `inspect.getsourcefile`:
>>> import inspect
>>> from contextlib import contextmanager
>>> @contextmanager
... def func():
...yield
>>> inspect.getsource(func)
'
New submission from Eric Wieser :
Following on from https://bugs.python.org/issue1764286 - inspect.getsourcefile
and inspect.getcomments fall afoul of the same problem.
--
components: Library (Lib)
messages: 322847
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title
Change by Eric Wieser :
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue34305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +8108
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34305>
___
___
Py
Eric Wieser added the comment:
New issue opened at https://bugs.python.org/issue34305, along with a PR linked
there.
--
___
Python tracker
<https://bugs.python.org/issue1764
Change by Eric Wieser :
--
nosy: +Eric.Wieser
___
Python tracker
<https://bugs.python.org/issue34494>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
What I think I find surprising is that I'd expect the sequence protocol to be
defined by `__getitem__` and `__len__`, and for `__iter__` to be inferred as:
def __iter__(self):
for i in range(len(self)):
yield self[i]
But in reali
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
--
___
Python tracker
<https://bugs.python.org/issue34
Eric Wieser added the comment:
Pinging again, for lack of a clearer path forward
--
___
Python tracker
<https://bugs.python.org/issue32782>
___
___
Python-bug
Eric Wieser added the comment:
For anyone doing archaeology - this came up on python-dev about a year after
this issue was filed:
https://mail.python.org/pipermail/python-dev/2009-December/094439.html
--
___
Python tracker
<ht
Eric Wieser added the comment:
> then we should perhaps instead consider the rewrite for 3.6: provide a *new*
> distutils function that does use Popen and does things "right" (based on
> everything we've learned since distutils was written), leaving the old
> fu
New submission from Eric Wieser:
This code:
class Sudoku(dict):
COLUMNS = [
{(x, y) for y in xrange(9)} for x in xrange(9)
]
When run on Python 2.7.5, fails with this traceback:
Traceback (most recent call last):
File "", line 1, in
Changes by Eric Wieser :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue18110>
___
___
Python-bugs-list mailing list
Unsubscri
Eric Wieser added the comment:
This is not at first glance, a duplicate of 3692 - in that case, the list
comprehension is referring to another class variable.
Most notably, that describes a behavioural change introduced by python 3 - in
this case, python 3 handles it correctly - there's
Eric Wieser added the comment:
Thanks for the clarification - this behavior now makes perfect sense to me. As
expected, swapping the list comprehension for a generator comprehension, or
vice versa, prevents the error.
--
___
Python tracker
<h
New submission from Eric Wieser:
It would be nice if there was a `with` "expression". Such that instead of:
with open(...) as f:
result = foo(f)
One could write:
result = foo(f) with open(...) as f
This would be particularly useful in comprehensions. Instead of:
Changes by Eric Wieser :
--
components: +Interpreter Core
___
Python tracker
<http://bugs.python.org/issue17788>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Wieser:
https://docs.python.org/3.2/reference/compound_stmts.html#function-definitions
and onwards say the following
decorator ::= "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE
This is a regression
Eric Wieser added the comment:
The offending patch can be found at
https://hg.python.org/cpython/rev/71ff2235bb4c
--
___
Python tracker
<http://bugs.python.org/issue27
Eric Wieser added the comment:
The parent commit is also bad:
https://hg.python.org/cpython/rev/b65007ef59c0
--
___
Python tracker
<http://bugs.python.org/issue27
67 matches
Mail list logo
