Bar Harel added the comment:
Actually I'm not sure if the fix is so simple. What happens if B does not
inherit from dataclass, but still inherits from A? Do we want to use the new
__post_init__? I would assume we do, meaning we don't necessarily want to
attach the __post_init__
Bar Harel added the comment:
@Eric, I can easily fix it if you wish :-)
Just wondered if it's intended or not, as it looked like a bug but the
documentation was somewhat endorsing it and I got confused.
Either case, a simple fix.
--
___
Python
New submission from Bar Harel :
Not sure if a continuance of https://bugs.python.org/issue44365 or not, but the
suggestion to call super().__init__() in __post__init__ will cause infinite
recursion if the superclass also contains __post__init__:
>>> @d
... class A:
... test: int
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue38938>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
> That was true in 2011 and it is still true today
Python's methodology greatly shifted since 2011. For the better or worse,
Python lost some of its duck typing. Nowadays, most people use linters.
Wherever you'd try to pass sre_parse.SubPattern, the lin
Bar Harel added the comment:
@rhettinger I completely understand what you're saying and at first I agreed
with you. Before I gave it a closer look, I thought about the same thing - we
want reliability. Reliability is important and will avoid subtle bugs, which is
why I was against
Bar Harel added the comment:
I thought about it, what about simply excluding TPFLAGS_MAPPING from PySequence
and TPFLAGS_Sequence from PyMapping? It will remove the types that are 100% not
sequences or mappings, as these flags are mutually exclusive by definition. The
result will be much
Bar Harel added the comment:
Another question we should ask is about duck typing. Is a sequence which
doesn't inherit from abc.Sequence considered a sequence? Whatever the answer
is, PySequence specifically looks for a sequence and removes duck typing out of
the picture. The object
Bar Harel added the comment:
Do note, the relevant functions are in the Stable ABI, and their promise will
slightly change, yet modifying the current functions instead of creating new
ones may still be beneficial.
--
___
Python tracker
<ht
Bar Harel added the comment:
Up until now, trying to distinguish between actual sequences and mappings in
C-API was a pain. Same methods are implemented in customer user classes, and
the ABCs could have either been registered dynamically or had an appropriate
__subclasshook__. On top
Change by Bar Harel :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue46141>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Bar Harel :
IPv4Network accepts a tuple.
If you send a tuple to ip_network instead, it throws a TypeError while
attempting to format the ValueError message.
--
components: Library (Lib)
messages: 408980
nosy: bar.harel
priority: normal
pull_requests: 28439
Bar Harel added the comment:
Does this count as a regression or as an unintended bugfix for evaluation order?
https://stackoverflow.com/a/70404659/1658617
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue39
Change by Bar Harel :
--
keywords: +patch
pull_requests: +28307
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30086
___
Python tracker
<https://bugs.python.org/issu
Change by Bar Harel :
--
components: +Library (Lib)
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue46022>
___
___
Python-bugs-list mai
Bar Harel added the comment:
Regarding backwards compatibility, the only issue that can arise from solutions
1 or 2, is if someone uses a bare `except` statement for finalization around
`serve_forever` instead of using `finally`.
Keep in mind the function is not documented
New submission from Bar Harel :
The Python docs recommends using `.serve_forever()` for running a
multiprocessing manager.
The problem is, that unlike any equivalent `.serve_forever()`, this specific
one calls `sys.exit()` and exits the program. This in turn may cause issues if
that's
Bar Harel added the comment:
It's technically not a bug as it is not exposed externally, but I concur with
the OP that it shouldn't happen. I'll send a fix either way, and from there we
will continue asking if _Server should be exposed or not.
--
nosy: +bar.harel
versions: +Python
Change by Bar Harel :
--
nosy: +michael.foord
___
Python tracker
<https://bugs.python.org/issue44911>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
keywords: +patch
pull_requests: +26241
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27765
___
Python tracker
<https://bugs.python.org/issu
New submission from Bar Harel :
Writing a test that leaks a running asyncio task will cause
IsolatedAsyncioTestCase to crash while attempting to cancel.
Seems like the loop argument wasn't removed from the usage of asyncio.gather()
in IsolatedAsyncioTestCase._tearDownAsyncioLoop
Pushing
Change by Bar Harel :
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue31356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
I've taken a shot making this in pure Python, and took into account a few more
factors such as starvation and reentrancy.
As Nick said, one of the only ways it can truly work is if it's completely
global, in which case we don't need to use the internal lock
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue31356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
It relinquishes control for exactly one event loop cycle.
You'll see that it takes two or three cycles and then gets cancelled correctly.
The reason being is that recovery from your `await asyncio.sleep(1)` takes two
or three cycles. (Under the hood, a few
Change by Bar Harel :
--
pull_requests: +21694
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22729
___
Python tracker
<https://bugs.python.org/issu
Change by Bar Harel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Bar Harel added the comment:
> When instantiation fails, recheck to see the missing abstract methods had
> been defined?
I've written about it in the python-ideas discussion as well, and completely
agree.
There is no other approach that would guarantee correctness across all APIs,
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue23163>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue41571>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue37873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
I have experienced both ×´TypeError: can't concat NoneType to bytes×´, and the
fact BufferedIO returns None.
@pitrou @izbyshev contrary to your belief, I think there is at least some
interest in this issue. Every few months another ticket is opened about
Change by Bar Harel :
--
nosy: +bquinlan, pitrou
___
Python tracker
<https://bugs.python.org/issue41372>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Bar Harel :
Asyncio has an amazing mechanism showing "Task exception was never retrieved"
or "Future exception was never retrieved" if the task threw an exception, and
no one checked its `.result()` or `.exception()`.
It does so by setting a pr
Bar Harel added the comment:
May I suggest calling it key? Will comply with other Python functions.
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue41
Bar Harel added the comment:
Actually, it looks like distutils days are quite over and pip itself uses
setuptools with pypa packaging.
I'll take the initiative and close this.
--
resolution: -> wont fix
stage: -> resolved
status: open -&g
New submission from Bar Harel :
Is distutils.version aware of the PEP440 epoch version modifier? I haven't seen
any reference to this.
AFAIK pypa packaging does take it into consideration, but should the stdlib
also care about it?
I would like to believe pip takes it into consideration
Bar Harel added the comment:
@Raymond your first idea sounds good and was the first thing that came to my
mind.
I only worried about breaking things, so I gave the more conservative
suggestion.
If breaking a few eggs isn't an issue and the implications of your idea are
agreed upon, I'll
Bar Harel added the comment:
I've just encountered this bug as well.
Although this issue is old, #1 should be fixed whether we like it or not.
Cancelling an unintended event instead of the one we wanted is a bug, and
prevents me from using the library at all (I schedule events based
New submission from Bar Harel :
Per discussion on mailing list, I suggest adding a PYTHONLOGGING environment
variable, and a matching -L cmdline argument.
When set to a logging level of choice, they will initiate basicConfig with the
appropriate level.
For example, "py.exe -L
Change by Bar Harel :
--
keywords: +patch
pull_requests: +19885
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20668
___
Python tracker
<https://bugs.python.org/issu
New submission from Bar Harel :
TLDR; `logging.Formatter('%(ip)s %(message)s', defaults={"ip": None})`
Python's logging.Formatter allows the placement of custom fields, e.g.
`logging.Formatter("%(ip)s %(message)")`.
If a handler has a formatter with a custom field, all
Bar Harel added the comment:
@Kyle, looks good to me. Maybe this will work better? Together with the current
example which shows the "earliest_result" variable of course.
"Each coroutine returns the next result from the set of the remaining
awaitables, based upon the orde
Change by Bar Harel :
--
keywords: +patch
pull_requests: +19074
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19753
___
Python tracker
<https://bugs.python.org/issu
Bar Harel added the comment:
It's a coroutine. Basically the same coroutine yielded over and over, returning
the first future's result each time.
Like I said, I'm not entirely sure how to phrase it.
Maybe "Returns an iterator of await
New submission from Bar Harel :
Continuing with bpo-27589, looks like as_completed documentation is still
misleading. According to the docs, it "Return(s) an iterator of Future objects.
Each Future object returned represents the earliest result from the set of the
remaining await
Change by Bar Harel :
--
title: ast -> asyncio.as_completed documentation misleading
___
Python tracker
<https://bugs.python.org/issue40405>
___
___
Python-
New submission from Bar Harel :
Profile and cProfile's documentation does not say anything about the builtins
parameter.
Also, it exists only on cProfile, which means Profile is not a drop-in
replacement.
Lastly, enable() method, that exists on cProfile, also accepts params
Bar Harel added the comment:
Patch done, ready for upload.
No http experts for nosy, triage needed.
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issu
Bar Harel added the comment:
For reference, docs already state:
"On encountering an invalid cookie, CookieError is raised, so if your cookie
data comes from a browser you should always prepare for invalid data and catch
CookieError on pa
Bar Harel added the comment:
The only issue I fear is breakage if people count on it silently ignoring
errors.
But then again it's inconsistent, and sometimes it will throw errors either
way, so I still believe this issue should be addressed
Change by Bar Harel :
--
pull_requests: +18412
pull_request: https://github.com/python/cpython/pull/19059
___
Python tracker
<https://bugs.python.org/issue40
New submission from Bar Harel :
ATM loading cookies is inconsistent.
If you encounter an invalid cookie, BaseCookie.load will sometimes raise
CookieError and sometimes silently ignore the load:
from http.cookies import SimpleCookie
s = SimpleCookie()
s.load("invalid\x00=cookie")
Bar Harel added the comment:
See also bpo-39267
--
___
Python tracker
<https://bugs.python.org/issue39264>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
keywords: +patch
pull_requests: +17322
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17911
___
Python tracker
<https://bugs.python.org/issu
New submission from Bar Harel :
Continuing bpo-39264, and according to the mailing list discussion at
Python-Dev.
Fixing dict's __missing__ documentation. Clarify .get() does not call
__missing__, and move __missing__ from the data model to dict's section as it's
not a general object or ABC
Change by Bar Harel :
--
keywords: +patch
pull_requests: +17321
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17910
___
Python tracker
<https://bugs.python.org/issu
New submission from Bar Harel :
Unlike dict, UserDict.__missing__ is called on .get().
After a discussion on the Python-Dev mailing list, mimicking dict's behavior
was chosen as a solution to the issue.
--
components: Library (Lib)
messages: 359633
nosy: bar.harel
priority: normal
Change by Bar Harel :
--
pull_requests: +17142
pull_request: https://github.com/python/cpython/pull/17685
___
Python tracker
<https://bugs.python.org/issue38
Change by Bar Harel :
--
pull_requests: +17141
pull_request: https://github.com/python/cpython/pull/17684
___
Python tracker
<https://bugs.python.org/issue38
Bar Harel added the comment:
Ready for merge
--
___
Python tracker
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
A better example is this:
class A(PathLike):
def foo(self):
"""For all your foo needs"""
class B:
def __fspath__(self):
pass
issubclass(B, A) == True
A().foo() # Yay, I Foo'd
Bar Harel added the comment:
Done.
On Fri, Nov 22, 2019, 12:23 PM Bar Harel wrote:
>
> Change by Bar Harel :
>
>
> --
> keywords: +patch
> pull_requests: +16820
> stage: resolved -> patch review
> pull_request: https://github
Change by Bar Harel :
--
keywords: +patch
pull_requests: +16820
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17336
___
Python tracker
<https://bugs.python.org/issu
Bar Harel added the comment:
Hey Brett, that's exactly the bug. It's supposed to be False ofc.
On Thu, Nov 21, 2019, 9:45 PM Brett Cannon wrote:
>
> Brett Cannon added the comment:
>
> I can't reproduce in Python 3.8.0:
>
> >>> import os
> >>> class A
New submission from Bar Harel :
Quick and small fix.
os.PathLike.__subclasshook__ does not check if cls is PathLike as abstract
classes should.
This in turn causes this bug:
class A(PathLike):
pass
class B:
def __fspath__(self):
pass
assert
Bar Harel added the comment:
Alright. Regression tests added, all tests pass. Patch ready for upload!
--
nosy: +vinay.sajip
___
Python tracker
<https://bugs.python.org/issue36
Bar Harel added the comment:
Alright, patch submitted.
Shall I add regression tests?
--
___
Python tracker
<https://bugs.python.org/issue36813>
___
___
Pytho
Change by Bar Harel :
--
keywords: +patch
pull_requests: +13027
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Bar Harel :
QueueListener does not call task_done upon termination, causing an unsuspecting
thread to deadlock.
Steps to reproduce:
>>> import queue
>>> q = queue.Queue()
>>> from logging.handlers import QueueListener
>>> h = Queue
Bar Harel <bzvi7...@gmail.com> added the comment:
Yup. Thanks Yuri :-)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Bar Harel <bzvi7...@gmail.com> added the comment:
I don't think so. Having shield not cancel immediately but rather wait and
cancel will cause long timed shielded operations to stall the task
cancellation, usually for no good. This isn't the general case.
However, adding another function
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5467
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Bar Harel <bzvi7...@gmail.com>:
--
keywords: +patch
Added file: https://bugs.python.org/file47440/le_patch.diff
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Bar Harel <bzvi7...@gmail.com>:
Added file: https://bugs.python.org/file47441/le_meme.jpg
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Bar Harel <bzvi7...@gmail.com>:
Hey guys,
A week after a serious asyncio.Lock bug, I found another bug that makes
asyncio.Condition ignore and prevent cancellation in some cases due to an
"except: pass" which tbh is a little embarrassing.
What happen
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5335
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
_
Change by Bar Harel <bzvi7...@gmail.com>:
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
__
Bar Harel <bzvi7...@gmail.com> added the comment:
Finished fixing CR and adding backports.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5309
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
_
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5306
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
_
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5305
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
_
Bar Harel <bzvi7...@gmail.com> added the comment:
Alright. Fixed, added tests, news and acks.
Besides PR5466, we'll need another one for the 3.6 branch.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Bar Harel <bzvi7...@gmail.com>:
--
keywords: +patch
pull_requests: +5292
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Bar Harel <bzvi7...@gmail.com>:
Hey guys,
I found a pretty dangerous bug that allows acquiring locks in asyncio without
them being free.
This happens due to double release (calling _wake_up_first) from both release
and acquire in case of cancellation.
The exampl
Bar Harel <bzvi7...@gmail.com> added the comment:
Alrighty then, opt1 passed all tests and waiting on GitHub for inclusion :-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Bar Harel <bzvi7...@gmail.com> added the comment:
Done :-)
Seems like I forgot to edit the news though, I'll try to edit it.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Bar Harel added the comment:
Bumposaurus Rex
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list
Bar Harel added the comment:
I personally prefer the __copy__ mechanism as I think a bugfix shouldn't be
10% backwards compatible, chances of issues are low, and it's cleaner, more
efficient and how things should be.
--
___
Python tracker <
Changes by Bar Harel <bzvi7...@gmail.com>:
Added file: http://bugs.python.org/file44833/issue27141_patch_rev1_opt2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Bar Harel added the comment:
Alright. 2 patches are available.
opt_1 makes the use of __copy__.
Advantages:
- Clean
- Does not affect pickling at all
- More memory efficient
Disadvantages:
- Might be missing something from the normal copy mechanism (e.g. UserList
doesn't implement
Bar Harel added the comment:
I still believe "Reiterable" better demonstrates the concept.
When you request a Reiterable as a function parameter or assert if something is
a Reiterable the other side knows exactly what you mean.
A "Collection" is way more ambiguous - if
Bar Harel added the comment:
Are the patch and tests good?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Pyth
New submission from Bar Harel:
I thought of implementing an assertNotRaises to solve the issue of using
try...except...fail in order to prevent showing the tests as an error and
instead show them as a failure.
Is there anything I should consider while implementing it?
--
components
Bar Harel added the comment:
Added UserDict and UserList tests.
Keep in mind I am currently skipping UserDict's tests until we will implement
the correct mechanism.
We do not need the same tests or functionality for UserString as UserString is
immutable.
--
Added file: http
Bar Harel added the comment:
I thought about UserDict, but adding this simple patch to UserDict will result
in infinite recursion (due to how copy is implemented in there). We will have
to change the implementation of UserDict's copy method
New submission from Bar Harel:
I have encountered a weird behavior in collections.UserList.
Using copy.copy() on an instance results in a new instance of UserList but with
the same underlying list. Seems like self.copy() works great but __copy__ was
not overridden to allow copy.copy to work
Bar Harel added the comment:
Any idea how to test it then? I found this happening by chance because I care
about efficiency too much. We can't just stick timeit in random areas and hope
to get results.
--
___
Python tracker <rep...@bugs.python.
Changes by Bar Harel <bzvi7...@gmail.com>:
--
nosy: +bar.harel
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26601>
___
__
New submission from Bar Harel:
After asking a question regarding performance in StackOverflow, I received an
answer which seemed like a design problem in object allocation.
This is the question: http://stackoverflow.com/q/36548518/1658617
Seems like it ignores the garbage allocation settings
1 - 100 of 117 matches
Mail list logo
