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
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
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
Change by Bar Harel :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue46141>
___
___
Python-bugs-list mailing list
Unsubscrib
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 of
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:
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 wil
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:
@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:
> 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, th
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue38938>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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.
--
___
P
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_ini
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
Push
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
Change by Bar Harel :
--
nosy: +michael.foord
___
Python tracker
<https://bugs.python.org/issue44911>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
ve
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'
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 and there is no
Change by Bar Harel :
--
components: +Library (Lib)
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue46022>
___
___
Python-bugs-list mai
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:
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
> >&
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:
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
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
Bar Harel added the comment:
Ready for merge
--
___
Python tracker
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
pull_requests: +17141
pull_request: https://github.com/python/cpython/pull/17684
___
Python tracker
<https://bugs.python.org/issue38
Change by Bar Harel :
--
pull_requests: +17142
pull_request: https://github.com/python/cpython/pull/17685
___
Python tracker
<https://bugs.python.org/issue38
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: n
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 :
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 genera
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
Bar Harel added the comment:
See also bpo-39267
--
___
Python tracker
<https://bugs.python.org/issue39264>
___
___
Python-bugs-list mailing list
Unsubscribe:
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")
Change by Bar Harel :
--
pull_requests: +18412
pull_request: https://github.com/python/cpython/pull/19059
___
Python tracker
<https://bugs.python.org/issue40
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 addr
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:
Patch done, ready for upload.
No http experts for nosy, triage needed.
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issu
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, an
Change by Bar Harel :
--
title: ast -> asyncio.as_completed documentation misleading
___
Python tracker
<https://bugs.python.org/issue40405>
___
___
Python-
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
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 it
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:
@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
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,
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:
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 in
Change by Bar Harel :
--
nosy: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue31356>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 cu
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 :
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 info&quo
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 bas
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,
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 consideratio
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: ope
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
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
Change by Bar Harel :
--
nosy: +bquinlan, pitrou
___
Python tracker
<https://bugs.python.org/issue41372>
___
___
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 ab
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue37873>
___
___
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/issue23163>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Bar Harel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
Change by Bar Harel :
--
keywords: +patch
pull_requests: +13027
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Bar Harel added the comment:
Alright, patch submitted.
Shall I add regression tests?
--
___
Python tracker
<https://bugs.python.org/issue36813>
___
___
Pytho
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
New submission from Bar Harel :
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 example I've uploaded exploi
Change by Bar Harel :
--
keywords: +patch
pull_requests: +5292
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue32734>
___
_
Bar Harel added the comment:
Alright. Fixed, added tests, news and acks.
Besides PR5466, we'll need another one for the 3.6 branch.
--
___
Python tracker
<https://bugs.python.org/is
Change by Bar Harel :
--
pull_requests: +5305
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
pull_requests: +5306
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
pull_requests: +5309
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Bar Harel added the comment:
Finished fixing CR and adding backports.
--
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailin
Change by Bar Harel :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Bar Harel :
--
pull_requests: +5335
___
Python tracker
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Bar Harel :
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 happens is that during the time it ta
Change by Bar Harel :
Added file: https://bugs.python.org/file47441/le_meme.jpg
___
Python tracker
<https://bugs.python.org/issue32841>
___
___
Python-bugs-list mailin
Change by Bar Harel :
--
keywords: +patch
Added file: https://bugs.python.org/file47440/le_patch.diff
___
Python tracker
<https://bugs.python.org/issue32
Change by Bar Harel :
--
pull_requests: +5467
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32841>
___
___
Python-bugs-list mai
Bar Harel 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 which does so mig
Bar Harel added the comment:
Done :-)
Seems like I forgot to edit the news though, I'll try to edit it.
--
___
Python tracker
<https://bugs.python.org/is
Bar Harel added the comment:
Alrighty then, opt1 passed all tests and waiting on GitHub for inclusion :-)
--
___
Python tracker
<https://bugs.python.org/issue27
Bar Harel added the comment:
Yup. Thanks Yuri :-)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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:
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 m
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:
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:
Are the patch and tests good?
--
___
Python tracker
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsub
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
New submission from Bar Harel:
Seems like at
https://docs.python.org/3.5/library/asyncio-eventloop.html#creating-connections
(Creating connections) in asyncio, it states that "On Windows with
ProactorEventLoop, SSL/TLS is not supported."
But on the ProactorEventLoop it states that S
Bar Harel added the comment:
Here's a quick minor patch to fix, works on a re-compiled doc.
--
keywords: +patch
nosy: +bar.harel
Added file: http://bugs.python.org/file40506/multiprocessing_patch.patch
___
Python tracker
<http://bugs.py
Bar Harel added the comment:
A quick patch updating the mime and removing the mentioning of PyGoogle. We can
add a different example in the future if we wish.
--
keywords: +patch
nosy: +bar.harel
Added file: http://bugs.python.org/file40508/urllib_howto.patch
Bar Harel added the comment:
Added a similar patch to 2.7
--
Added file: http://bugs.python.org/file40509/urllib_howto27.patch
___
Python tracker
<http://bugs.python.org/issue25
Bar Harel added the comment:
I believe it's an intended behavior as python's float has a limit after all.
It's hard to reach it but definitely possible.
A workaround is to internally use Decimal (also take the advantage that it's
implementation is now way faster) but it wi
Bar Harel added the comment:
Whoop! I see the reason for it now. By limit I don't mean the precision limit,
I mean the top limit in which float converts to "inf".
Seems like this bug is due to the change of python 3's division operator.
Under numbers it states:
"
Bar Harel added the comment:
Yup, it indeed fixes the problem. Sorry for thinking it's intended.
Seems like it's a small problem but it does affects all the uses of Integral
or Rational.
I'll test it with the suite hoping it has a suff
1 - 100 of 118 matches
Mail list logo