[issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order

2020-10-16 Thread Bar Harel


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/issue19270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2020-10-10 Thread Bar Harel


Change by Bar Harel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41905] add update_abstractmethods function to update an ABC's abstract methods

2020-10-04 Thread Bar Harel


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, 
both internal and 3rd party. Adding a function to recalculate will require 
everyone to use it, and worse, know that it even exists.

The overhead should be quite low as this case is probably rare and the 
recalculation can happen only on failure.

I'm not sure however, what are the implications of changing 
Py_TPFLAGS_IS_ABSTRACT during type creation.

--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue41905>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23163] pdb docs need to contain a statement on threads/multithreaded debugging

2020-09-06 Thread Bar Harel


Change by Bar Harel :


--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue23163>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41571] Implement thread-related commands in pdb

2020-09-06 Thread Bar Harel


Change by Bar Harel :


--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue41571>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37873] unittest: execute tests in parallel

2020-09-01 Thread Bar Harel


Change by Bar Harel :


--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue37873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13322] The io module doesn't support non-blocking files

2020-08-16 Thread Bar Harel

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 a 
different aspect of the same underlying problem.

--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue13322>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41372] Log exception never retrieved in concurrent.futures

2020-07-22 Thread Bar Harel


Change by Bar Harel :


--
nosy: +bquinlan, pitrou

___
Python tracker 
<https://bugs.python.org/issue41372>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41372] Log exception never retrieved in concurrent.futures

2020-07-22 Thread Bar Harel


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 private variable named `__log_traceback` to False upon 
retrieval, and logging at `__del__` if the exception wasn't retrieved.

I believe it's a very important mechanism missing from concurrent.futures. It's 
very easy to implement.

I wanted to see if there's any disagreement before I implement it though. It's 
small enough to not need python-ideas yet important enough for inclusion I 
believe.

Regarding potential issues - I can only see issues with unlikely deadlocks at 
`__del__` (think of a handler taking a lock and this occurs during the handling 
of another log record). Asyncio however already took that bet, and although 
it's less planned for multi-threading, it's still a bet that was totally worth 
it.

--
components: Library (Lib)
messages: 374114
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Log exception never retrieved in concurrent.futures
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue41372>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41220] add optional make_key argument to lru_cache

2020-07-06 Thread Bar Harel


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/issue41220>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41186] distutils.version epoch compatibility

2020-07-01 Thread Bar Harel


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 -> closed

___
Python tracker 
<https://bugs.python.org/issue41186>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41186] distutils.version epoch compatibility

2020-07-01 Thread Bar Harel


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 but not sure if it uses 
distutils, or that setuptools have their own versioning scheme together with 
pkg_resources.

--
components: Distutils
messages: 372765
nosy: bar.harel, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.version epoch compatibility
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41186>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order

2020-06-23 Thread Bar Harel


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 patch and add a PR.

--

___
Python tracker 
<https://bugs.python.org/issue19270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order

2020-06-19 Thread Bar Harel


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 on absolute 
time).

To be honest, I do not believe anyone uses scheduler.cancel(Event(time, 
priority, ...)) in order to cancel an event based on the given time and 
priority.

Even if they do so, Event itself is undocumented and is being treated mostly as 
an ID for a currently scheduled event.

A good solution would be to add a DeprecationWarning to the ordering functions, 
so people won't use them, and remove __eq__ at 3.12.

The only issue that will arise is that an event1 might be >= than event2, <= 
than event 2, and != to event 2, as the other ordering will stay. We can fix 
this by implementing a slower lookup but I believe it isn't a real issue.

--
nosy: +bar.harel

___
Python tracker 
<https://bugs.python.org/issue19270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40886] Add PYTHONLOGGING environment variable and -L cmdline argument

2020-06-05 Thread Bar Harel


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" will be equivalent to 
"logging.basicConfig(level='info')" on interpreter startup.

Sames as setting env var "PYTHONLOGGING=info".

This matches the current behavior of other settings, such as PYTHONWARNINGS and 
-W, allows to easily test programs without modifying them, and further 
completes the expected arguments available from the commandline.

Discussion on mailing list for reference:
https://mail.python.org/archives/list/python-id...@python.org/thread/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/

--
components: Library (Lib)
messages: 370807
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Add PYTHONLOGGING environment variable and -L cmdline argument
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue40886>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40884] Added defaults parameter for logging.Formatter

2020-06-05 Thread Bar Harel


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/issue40884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40884] Added defaults parameter for logging.Formatter

2020-06-05 Thread Bar Harel


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 log records that go 
through the handler must have the custom field set using `extra={}`.
Failure to do so will result in exceptions thrown inside the logging library.

Custom fields are common, and are even suggested by the Python logging 
cookbook, where they are attached to the root logger.

There is, however, no way to specify default values for the custom fields. 
Quite a few issues arise from it.

For example, if I've set a formatter on the root logger with the custom field 
"%(ip)s", all logging messages sent by the asyncio library, will cause 
exceptions to raise.

Adding default values is possible using LoggerAdapter but will causes other 
issues as well as not solve the aforementioned problem.

Adding default values is possible using Filters, but cause confusion, isn't 
simple, and permanently modify the record object itself, which can cause issues 
if more handlers or formatters are attached.

>From a quick search, this feature was asked for many times in stackoverflow, 
>and even spawned up a few libraries such as "logaugment" in order to solve it.

I believe the solution offered, by using `defaults={}` is simple enough to not 
need discussion over python-ideas, yet common enough to justify the addition to 
the standard library.

I've provided a reference PR. It does not cause backwards compatibility issues, 
complies with all formatter styles (%, {}, $), passes all tests and is simple 
enough to both use and understand.

Not sure if 3.9 is feature-closed for small additions like this.

--
components: Library (Lib)
messages: 370796
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Added defaults parameter for logging.Formatter
type: enhancement
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40884>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40405] asyncio.as_completed documentation misleading

2020-04-29 Thread Bar Harel


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 order of completion."

Represents -> Returns (less obscure, and coroutines are awaited on to get the 
result)
Earliest -> removed, "order  of completion" looks great.

--

___
Python tracker 
<https://bugs.python.org/issue40405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40405] asyncio.as_completed documentation misleading

2020-04-28 Thread Bar Harel


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/issue40405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40405] asyncio.as_completed documentation misleading

2020-04-27 Thread Bar Harel


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 awaitables"?

--

___
Python tracker 
<https://bugs.python.org/issue40405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40405] ast

2020-04-27 Thread Bar Harel


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 awaitables."

There's only one problem: The only thing it definitely doesn't do, is return an 
iterator of future objects. To be honest with you, I'm not entirely sure how to 
phrase it.

For reference, I fell for this:

mapping = {fut: index for fut, index in enumerate(futures)}
for fut in as_completed(mapping):
  mapping[fut]  # KeyError

--
assignee: docs@python
components: Documentation, asyncio
messages: 367410
nosy: aronacher, asvetlov, bar.harel, docs@python, gvanrossum, hynek, vstinner, 
xtreak, yselivanov
priority: normal
severity: normal
status: open
title: ast
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40405] asyncio.as_completed documentation misleading

2020-04-27 Thread Bar Harel


Change by Bar Harel :


--
title: ast -> asyncio.as_completed documentation misleading

___
Python tracker 
<https://bugs.python.org/issue40405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40205] Profile 'builtins' parameter documentation missing

2020-04-06 Thread Bar Harel


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, and are 
undocumented.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 365859
nosy: bar.harel, docs@python
priority: normal
severity: normal
status: open
title: Profile 'builtins' parameter documentation missing
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40002] Cookie load error inconsistency

2020-03-18 Thread Bar Harel


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/issue40002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40002] Cookie load error inconsistency

2020-03-18 Thread Bar Harel


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 parsing."

--

___
Python tracker 
<https://bugs.python.org/issue40002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40002] Cookie load error inconsistency

2020-03-18 Thread Bar Harel


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.

--

___
Python tracker 
<https://bugs.python.org/issue40002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40002] Cookie load error inconsistency

2020-03-18 Thread Bar Harel


Change by Bar Harel :


--
pull_requests: +18412
pull_request: https://github.com/python/cpython/pull/19059

___
Python tracker 
<https://bugs.python.org/issue40002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40002] Cookie load error inconsistency

2020-03-18 Thread Bar Harel


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") # Silently ignored
s.load("invalid/=cookie") # Raises CookieError

--
components: Library (Lib)
messages: 364519
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Cookie load error inconsistency
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39264] Fix UserDict.get to account for __missing__

2020-01-08 Thread Bar Harel


Bar Harel  added the comment:

See also bpo-39267

--

___
Python tracker 
<https://bugs.python.org/issue39264>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39267] Fix dict's __missing__ documentation

2020-01-08 Thread Bar Harel


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/issue39267>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39267] Fix dict's __missing__ documentation

2020-01-08 Thread Bar Harel


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 method but a dict-only implementation.

--
assignee: docs@python
components: Documentation
messages: 359639
nosy: bar.harel, docs@python
priority: normal
severity: normal
status: open
title: Fix dict's __missing__ documentation
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39267>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39264] Fix UserDict.get to account for __missing__

2020-01-08 Thread Bar Harel


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/issue39264>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39264] Fix UserDict.get to account for __missing__

2020-01-08 Thread Bar Harel


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
severity: normal
status: open
title: Fix UserDict.get to account for __missing__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39264>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-12-23 Thread Bar Harel


Change by Bar Harel :


--
pull_requests: +17142
pull_request: https://github.com/python/cpython/pull/17685

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-12-23 Thread Bar Harel


Change by Bar Harel :


--
pull_requests: +17141
pull_request: https://github.com/python/cpython/pull/17684

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-12-03 Thread Bar Harel


Bar Harel  added the comment:

Ready for merge

--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-11-23 Thread Bar Harel


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.
B().foo() # oh barnacles, I should have stayed at home.

--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-11-22 Thread Bar Harel


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.com/python/cpython/pull/17336
>
> ___
> Python tracker 
> <https://bugs.python.org/issue38878>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-11-22 Thread Bar Harel


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/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-11-21 Thread Bar Harel


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(os.PathLike): pass
> ...
> >>> class B:
> ... def __fspath__(self): pass
> ...
> >>> issubclass(B, A)
> True
>
> Did you check against an older version of Python?
>
> --
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> <https://bugs.python.org/issue38878>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38878] os.PathLike subclasshook causes subclass checks true on abstract implementation

2019-11-21 Thread Bar Harel


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 issubclass(B, A)

I will fix the bug later today and push a patch over to python/cpython on 
GitHub.

--
components: Library (Lib)
messages: 357174
nosy: bar.harel
priority: normal
severity: normal
status: open
title: os.PathLike subclasshook causes subclass checks true on abstract 
implementation
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36813] QueueListener not calling task_done upon termination

2019-05-07 Thread Bar Harel


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/issue36813>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36813] QueueListener not calling task_done upon termination

2019-05-06 Thread Bar Harel


Bar Harel  added the comment:

Alright, patch submitted.
Shall I add regression tests?

--

___
Python tracker 
<https://bugs.python.org/issue36813>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36813] QueueListener not calling task_done upon termination

2019-05-06 Thread Bar Harel


Change by Bar Harel :


--
keywords: +patch
pull_requests: +13027
stage: needs patch -> patch review

___
Python tracker 
<https://bugs.python.org/issue36813>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36813] QueueListener not calling task_done upon termination

2019-05-06 Thread Bar Harel


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 = QueueListener(q)
>>> h.start()
>>> h.stop()
# Goodbye cruel world!
>>> q.join()

Fixing and uploading a patch as we speak.

--
components: Library (Lib)
messages: 341519
nosy: bar.harel
priority: normal
severity: normal
status: open
title: QueueListener not calling task_done upon termination
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue36813>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-05-25 Thread Bar Harel

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://bugs.python.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-02-14 Thread Bar Harel

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 which does so might just be a good idea. I
think another parameter to shield to choose cancellation time will clutter
the function call.

On Wed, Feb 14, 2018, 7:28 AM Nathaniel Smith <rep...@bugs.python.org>
wrote:

>
> Nathaniel Smith <n...@pobox.com> added the comment:
>
> It does make me wonder if asyncio.shield *should* wait for the thing it's
> shielding though, so that it *would* work in this case? (Similar to
> bpo-32751.)
>
> --
>
> ___
> Python tracker <rep...@bugs.python.org>
> <https://bugs.python.org/issue32841>
> ___
>

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-02-13 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
pull_requests: +5467
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-02-13 Thread Bar Harel

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.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-02-13 Thread Bar Harel

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.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32841] Asyncio.Condition prevents cancellation

2018-02-13 Thread Bar Harel

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 happens is that during the time it takes to get back a conditional lock 
after notifying it, asyncio completely ignores all cancellations sent to the 
waiting task.

le_bug.py: Contains the bug
le_patch.diff: Contains a very simple fix (will send a pull on Github too)
le_meme.jpg: Contains my face after debugging this for 4 hours

Yuri, I hope you didn't miss me during this week ;-)

-- Bar

--
components: asyncio
files: le_bug.py
messages: 312140
nosy: asvetlov, bar.harel, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio.Condition prevents cancellation
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47439/le_bug.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-02 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
pull_requests: +5335

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-02 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
status: open -> pending

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-01 Thread Bar Harel

Bar Harel <bzvi7...@gmail.com> added the comment:

Finished fixing CR and adding backports.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-01 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
pull_requests: +5309

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-01 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
pull_requests: +5306

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-02-01 Thread Bar Harel

Change by Bar Harel <bzvi7...@gmail.com>:


--
pull_requests: +5305

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-01-31 Thread Bar Harel

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.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-01-31 Thread Bar Harel

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.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32734] Asyncio Lock safety issue (unlimited acquire)

2018-01-31 Thread Bar Harel

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 example I've uploaded exploits it by acquiring 4 times, which grooms the 
loop's _ready queue, cancelling the second acquire to add the cancellation to 
the _ready queue, and releasing once to add the next waiter (number 3) to the 
_ready queue. Next event loop step causes the cancellation to run first, 
skipping the queued waiter (due to .done check being true) and waking the next 
waiter in line (number 4). Then both number 3 and number 4 run together on the 
same Lock.

I'm not at home so it's hard for me to code but the simple way of fixing it is 
by adding this line - "if self._locked: yield from self.acquire()" after the 
"yield from fut" (quite minimal overhead and only if bug happens, so no harm) 
or by slightly restructuring the code and the checks regarding cancelled 
futures.

I can later on post the restructured code but I think the simple if statement 
is a pretty fine and efficient fix.

--
components: asyncio
files: bug.py
messages: 311361
nosy: asvetlov, bar.harel, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Lock safety issue (unlimited acquire)
type: security
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47419/bug.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2017-10-24 Thread Bar Harel

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.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2017-10-23 Thread Bar Harel

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.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-10-13 Thread Bar Harel

Bar Harel added the comment:

Bumposaurus Rex

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-09-26 Thread Bar Harel

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-09-26 Thread Bar Harel

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.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-09-26 Thread Bar Harel

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 __slots__ but it somewhat interferes with future 
implementation)
- Doesn't call __reduce__, __getstate__, ... while people might rely on it for 
some reason during copy, thus it might not be entirely backwards compatible

opt_2 makes use of __reduce__.

Advantages:

- Lowest in the chain. Shouldn't cause any backwards compatibility issues as if 
the user manually defined __getstate__ or __reduce_ex__ himself, the code as 
far as he's concerned did not change.
- Uses the default mechanism for copying. Changes in the protocol will not 
cause any bug in here.

Disadvantages:

- Affects pickling, messes up with the __reduce__ protocol.
- Takes more memory during pickling as it recreates the dict.
- Uglier as a personal opinion.

__getstate__ was not attempted as it will break backwards compatibility for 
sure if someone wrote a __reduce__ method (as it won't be called), but it's 
also a viable option.

Both patches contain tests and both fix the bug in UserDict and UserList.

--
versions: +Python 3.7
Added file: http://bugs.python.org/file44832/issue27141_patch_rev1_opt1.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27598] Add SizedIterable to collections.abc and typing

2016-08-23 Thread Bar Harel

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 you create an object that acts like 
range() but you can cycle over it more than once I wouldn't exactly call it a 
collection. I would though call it a Reiterable and it would be clear for any 
Python programmer familiar with the concept of iterators.

I believe this is a funny case in which the naming is more important than the 
implementation as it will turn into a term or concept that will be further used 
in many places to come.

--
nosy: +bar.harel

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27598>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-06-28 Thread Bar Harel

Bar Harel added the comment:

Are the patch and tests good?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27176] Addition of assertNotRaises

2016-06-01 Thread Bar Harel

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: Library (Lib), Tests
messages: 266816
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Addition of assertNotRaises
type: enhancement

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27176>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-05-28 Thread Bar Harel

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://bugs.python.org/file43036/UserObj_tests.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-05-28 Thread Bar Harel

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.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27141] Fix collections.UserList shallow copy

2016-05-27 Thread Bar Harel

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 too.
The patch just assigns __copy__ to self.copy triggering the correct behavior.

--
components: Library (Lib)
files: UserList.patch
keywords: patch
messages: 266515
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Fix collections.UserList shallow copy
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43032/UserList.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26601] Use new madvise()'s MADV_FREE on the private heap

2016-04-11 Thread Bar Harel

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.org>
<http://bugs.python.org/issue26601>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26601] Use new madvise()'s MADV_FREE on the private heap

2016-04-11 Thread Bar Harel

Changes by Bar Harel <bzvi7...@gmail.com>:


--
nosy: +bar.harel

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26601>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26734] Repeated mmap\munmap calls during temporary allocation

2016-04-11 Thread Bar Harel

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 (as timeit is supposed to 
disable it as far as I know) and I might not be proficient in low-level 
programming but there should be a way to implement it that doesn't cause 
endless allocations.

--
components: Benchmarks, Interpreter Core, Tests
messages: 263189
nosy: bar.harel, brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Repeated mmap\munmap calls during temporary allocation
type: performance
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-11-07 Thread Bar Harel

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/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-10-10 Thread Bar Harel

Bar Harel added the comment:

Any comments on the patch?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs

2015-10-05 Thread Bar Harel

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/issue25175>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24505] shutil.which wrong result on Windows

2015-10-05 Thread Bar Harel

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, I believe it is better to leave the casing as it is. 
It should be up to the user to mess with it as converting case is a one way 
ticket. If someone entered an uppercase, perhaps he wants it like that. Also 
it's less prune to errors and behaves the same for Unix and Windows.

--
nosy: +bar.harel

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24505>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16802] fileno argument to socket.socket() undocumented

2015-10-02 Thread Bar Harel

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/issue16802>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-27 Thread Bar Harel

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 not to support mixed types, as we can just again, return a 
mixed type as fraction but I left it like this in order not to cause unexpected 
behavior. I still think however that supporting mixed types should be fine as 
the bottleneck regarding precision is fraction, which is used as the base for 
conversion anyway.
I've added a few doctests on the way including the float max and min, which did 
not previously pass on the current implementation, and changed the unittest to 
match.

--
Added file: http://bugs.python.org/file40597/Issue25177_rev2.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-27 Thread Bar Harel

Bar Harel added the comment:

Alright, I issued a fix, now testing it

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-19 Thread Bar Harel

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, 8.98846567431158e+307], float has 
lesser precision than other types like Decimal so the patched method would 
return 8.98846567431158e+307.
A dataset to test the fix is [8.99e+307, 8.989e+307] which gives a correct 
result.

--
keywords: +patch
Added file: http://bugs.python.org/file40519/issue25177.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs

2015-09-19 Thread Bar Harel

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/issue25175>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-19 Thread Bar Harel

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 loss, and 
somewhat unexpected behavior.
Last thing we can do is catch that OverflowError and raise StatisticsError from 
exc.
I believe catching and re-raising as Statistics or just writing that it may 
also cause an Overflow error are the most viable ways.
Either way, I'd like another opinion before implementing either method as a 
patch.

--
nosy: +bar.harel

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-19 Thread Bar Harel

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:
"It's important that this conversion use the integer's "true"
division rather than casting one side to float before dividing
so that ratios of huge integers convert without overflowing."

It is meant to not to overflow but the "/" operator is now "//".
Lemme patch it up and see if it fixes the problem. If it states the integer's 
"true" division, I believe this small fix will be sufficient as it has been 
tested before.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-19 Thread Bar Harel

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.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25177] OverflowError in statistics.mean when summing large floats

2015-09-19 Thread Bar Harel

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 or reverting back to the classic 
division.

--
nosy: +benjamin.peterson, mark.dickinson

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25169] multiprocess documentation

2015-09-18 Thread Bar Harel

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.org>
<http://bugs.python.org/issue25169>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25145] urllib how-to should be updated to remove PyGoogle

2015-09-18 Thread Bar Harel

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

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25145>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25145] urllib how-to should be updated to remove PyGoogle

2015-09-18 Thread Bar Harel

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/issue25145>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25134] SSL asyncio

2015-09-15 Thread Bar Harel

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 SSL support was added in 3.5
Please remove the "unsupported" statement in the docs of 3.5 and 3.6
p.s. Is there a way I can fix these errors myself instead of hassling other 
people?

--
assignee: docs@python
components: Documentation
messages: 250803
nosy: Bar Harel, docs@python
priority: normal
severity: normal
status: open
title: SSL asyncio
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25134>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com