Bar Harel added the comment:
Anyway, yes, it should be quite the same. I can provide some benchmarks
tomorrow if you wish.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Bar Harel added the comment:
Any comments on the patch?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Pyth
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:
Alright, this patch passed all tests.
I've changed the function sum to include a new parameter called fraction which
decides whether to return a fraction or not. It might be useful in more
scenarios due to the fact fractions are more accurate.
I'm still unsure why
Bar Harel added the comment:
Here you go.
--
nosy: +bar.harel
Added file: http://bugs.python.org/file40656/Issue16802_rev2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Bar Harel added the comment:
Alright, I issued a fix, now testing it
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
__
Bar Harel added the comment:
Seems like this is the only viable option. It fixes the OverflowError but comes
at the cost of precision and time.
Another option would be to try/except the overflow error and only then return
the slower method.
Regarding the data [8.988465674311579e+307
Bar Harel added the comment:
Is this good? :-)
--
keywords: +patch
nosy: +bar.harel
Added file: http://bugs.python.org/file40520/Issue25175.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 will cause a precision
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 sufficient coverage
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 <rep...@bugs.python.
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Bar Harel added the comment:
Alright,
Seems like the problem is bigger than I thought. PEP 238
(https://www.python.org/dev/peps/pep-0238/) mentions that problem.
Using the new division, // will cause a floor while / will cause an
OverflowError.
An ugly way around it involves type checking
Bar Harel added the comment:
I guess you're correct, a simple mistake one time mistake shouldn't require the
changing of the docs.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Bar Harel added the comment:
Unfortunately that patch will not help for files like "python.exe.exe", and
double ext which sometimes happens.
I'm on it. Should take me a day or two, more problems might arise along the
way. Thanks Bob for alerting.
Regarding the uppercase,
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
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
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
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 <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Pyth
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
Changes by Bar Harel <bzvi7...@gmail.com>:
--
nosy: +bar.harel
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26601>
___
__
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.
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:
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
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:
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 <
Bar Harel added the comment:
Bumposaurus Rex
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list
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 <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:
Yup. Thanks Yuri :-)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Bar Harel <bzvi7...@gmail.com>:
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
__
Change by Bar Harel <bzvi7...@gmail.com>:
--
pull_requests: +5335
___
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: +5305
___
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: +5309
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
_
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
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
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>:
--
pull_requests: +5467
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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>:
--
keywords: +patch
Added file: https://bugs.python.org/file47440/le_patch.diff
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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
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 :
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 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 :
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:
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'd
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
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
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
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:
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
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
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-
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
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 :
--
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:
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
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
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:
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:
> 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 :
--
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
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:
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
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:
@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
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
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
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 about
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
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: +Dennis Sweeney
___
Python tracker
<https://bugs.python.org/issue31356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
nosy: +bar.harel
___
Python tracker
<https://bugs.python.org/issue31356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Bar Harel :
--
nosy: +michael.foord
___
Python tracker
<https://bugs.python.org/issue44911>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
keywords: +patch
pull_requests: +26241
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27765
___
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
1 - 100 of 117 matches
Mail list logo
