[issue39450] unittest TestCase shortDescription does not strip whitespace

[Chris Withers]

Chris Withers  added the comment:


New changeset 7561e7a83f5118fda6c62fe9c8c3458f8cfd by Miss Islington (bot) 
in branch '3.7':
bpo-39450 Stripped whitespace before parsing the docstring in 
TestCase.shortDescription (GH-18321)
https://github.com/python/cpython/commit/7561e7a83f5118fda6c62fe9c8c3458f8cfd


--

___
Python tracker 

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

[issue39450] unittest TestCase shortDescription does not strip whitespace

[miss-islington]

Change by miss-islington :


--
pull_requests: +17694
pull_request: https://github.com/python/cpython/pull/18321

___
Python tracker 

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

[issue39450] unittest TestCase shortDescription does not strip whitespace

[miss-islington]

Change by miss-islington :


--
pull_requests: +17695
pull_request: https://github.com/python/cpython/pull/18322

___
Python tracker 

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

[issue39450] unittest TestCase shortDescription does not strip whitespace

[Chris Withers]

Chris Withers  added the comment:


New changeset 032de7324e30c6b44ef272cea3be205a3d768759 by Steve Cirelli in 
branch 'master':
bpo-39450 Stripped whitespace before parsing the docstring in 
TestCase.shortDescription (GH-18175)
https://github.com/python/cpython/commit/032de7324e30c6b44ef272cea3be205a3d768759


--
nosy: +cjw296

___
Python tracker 

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

[issue37224] test__xxsubinterpreters fails randomly

[miss-islington]

Change by miss-islington :


--
pull_requests: +17693
pull_request: https://github.com/python/cpython/pull/18318

___
Python tracker 

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

[issue39533] Use `statx(2)` system call on Linux for extended `os.stat` information

[ntninja]

New submission from ntninja :

Background: For a long time several Linux filesystems have been tracking two 
extra bits of information. The file attributes bits[1] and the file creation 
time (aka crtime aka btime aka birthtime)[2]. Before Linux 4.11 accessing these 
required secret knowledge (ioctl numbers) or access to unstable interfaces 
(debugfs). However since that version the statx(2) system call[3] has finally 
been added (it has a long history), which exposes these two fields adds 
(struct) space for potentially more.

Since CPython already exposes `st_birthtime` on FreeBSD and friends, I think it 
would be fair to also expose this field on Linux. As the timestamp value is 
only available on some file systems and configurations it is not guaranteed 
that the system call will return a value for btime at all. I suppose the field 
should be set to `None` in that case. In my opinion it should also become a 
regular field (available on all platforms) since, with this addition, we now 
have a suitable value to return on every major platform CPython targets: 
`stx_btime` on Linux, `st_birthtime` on macOS/FreeBSD and `st_ctime` on Windows.

`stx_attributes` could be exposed as a new `st_attributes` flag specific to 
Linux as there is no equivalent on other platforms to my knowledge (Window's 
`st_file_attributes` is similar in some aspects but has a completely different 
format and content).

There is a Python script I created, that calls statx(2) using ctypes here: 
https://github.com/ipfs/py-datastore/blob/e566d40a8ca81d8628147e255fe7830b5f928a43/datastore/filesystem/util/statx.py
It may be useful as a reference when implementing this in C.

  [1]: https://man.cx/chattr(1)
  [2]: https://unix.stackexchange.com/a/50184/47938
  [3]: https://man.cx/statx(2)

--
messages: 361265
nosy: ntninja
priority: normal
severity: normal
status: open
title: Use `statx(2)` system call on Linux for extended `os.stat` information
type: enhancement

___
Python tracker 

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

[issue39515] pathlib won't strip "\n" in path

[徐彻]

徐彻  added the comment:

Thank you for your explanation.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Tim Peters]

Tim Peters  added the comment:

[Tim]
>> The pure-Python Miller-Rabin code i posted in the
>> aforementioned thread is typically at least 100
>> times faster than that.

[Steven]
> This is exactly the sort of argument about quality of
> implementation which isn't, or shouldn't be, part of
> the argument about the API, IMO.

I wasn't at all talking about API at that point.  I was backing the argument 
_you_ were making, that trial division is a hopelessly inefficient 
implementation, compared to what's possible with probabilistic methods, 
regardless of API.  You were in fact underselling that argument, because it's 
straightforward to get an order or two of magnitude faster than you 
demonstrated.


> the Q I quoted above was carefully designed (not by me, I hasten
> to add!)

I know the paper it came from.

> to be a preudoprime to the first 307 prime bases, so it's
> something of a worst-case scenario for my version.

Which is why I have no problem picturing how this "should be" approached:  the 
original Miller-Rabin (which uses random bases, not succumbing to the 
"premature optimization" catastrophe magnet) has no problem with Q (or with 
anything else!), and hasn't really been improved on for general-purpose use 
since it was published.  It's a darned-near perfect mix of simplicity, brevity, 
clarity, robustness, generality, and speed.  "Good enough" by a long shot on 
all counts.

>>def probably_prime(n, maxsteps=20)
>>
>> supplies a _default_ instead.  I don't want an API that's useful
>> _only_ to people who don't know what they're doing ;-)

> It's not just for people who don't know what they're doing. It
> is for people who don't want to sweat the small details,

Then they can accept the default.  In what conceivable sense is that a burden?

> they just want an nswer True or False and are prepared
> to trust that the function author knows what they are
> doing.

But the function author can't possibly know what the _user_ needs this for.  In 
some apps degree of certainty is far more important than speed, while in other 
apps it's the opposite.  Be realistic here?  Your argument here makes sense for 
always-right functions, but you're not willing to accept one of those for this 
specific purpose (& neither am I).

> If someone cares about the small details like how
> many bases to try,

It's not a "small detail" where it matters:  it is THE way to trade off 
computation time against confidence in the results.  It's a _fundamental_ 
aspect of how Miller-Rabin works.

> they might also care about details like:
>
> - which specific bases are used;
> - whether to use Miller-Rabin at all;
> - how many trial divisions to do first;
> - which specific primality test to use;

Then they should go use a special-purpose library ;-)  Letting them fiddle the 
single most important parameter isn't down in the weeds, it's a top-level 
control knob.

My answers to all the above:

- bases are picked via randrange(2, n-1)
- yes, because no better general-purpose algorithm is known
- none - although I'll allow that there may be a
  speed advantage in some apps if a gcd is done with a
  relatively small primorial first (more efficient than
  one-at-a-time trial divisions by small primes)
- Miller-Rabin

> What if the implementation shifts away from Miller-Rabin
> to (say) Baillie-PSW?

It can't ;-)  I would absolutely document that Miller-Rabin _is_ the algorithm 
being used, with the random-bases implementation choice.  Then the curious can 
search the web for a mountain of good information about it.

> Then your maxsteps parameter becomes meaningless. Do we
> deprecate it or leave it there in case the implementation
> changes again to something that has a concept of number
> of steps?

All moot, given that I have no interest in hiding the specific algorithm in 
use.  YAGNI.

> I think that if someone cares sufficiently about the details,
> then they probably won't be satisfied with a single isprime
> function, but may want is_fermat_prime, is_miller_rabin_prime,
> is_lucas_prime etc.

Again, go to a special-purpose library if that's what they want.  And, again, I 
don't agree with your characterization of the Miller-Rabin maxsteps parameter 
as a "detail".  It's a fundamental aspect of what the algorithm does.  Which 
casual users can certainly ignore, but at their own risk.

> ...
> Correct. The first twelve primes make up such a minimal set.

And if you don't care about picking the fixed bases from a prefix of the 
primes, you only need 7 bases for a 100% reliable test through 2**64:  2, 325, 
9375, 28178, 450775, 9780504, and 1795265022.  Or so this table claims:

https://miller-rabin.appspot.com/

But I don't care here.  Using a fixed set of bases is begging for embarrassment 
(for every fixed finite set of bases, there are an infinite number of 
composites they'll _claim_ are prime).  There are no systemic failure modes 
when using random bases.

--

___

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> [Steven]
> > ... Try it on numbers like this:
> > ...
> > Q = P*(313*(P-1)+1)*(353*(P-1)+1)
> >
> > Q is a 397 digit Carmichael Number. Its smallest factor is P,
> > which has 131 digits.

[Tim]
> The pure-Python Miller-Rabin code i posted in the aforementioned 
> thread is typically at least 100 times faster than that.

This is exactly the sort of argument about quality of implementation 
which isn't, or shouldn't be, part of the argument about the API, IMO. 
Just as the choice of Timsort over Quicksort or Bubblesort *wink* isn't 
part of the list.sort() API, let alone the implementation choices in 
Timsort such as MIN_GALLOP.

I'm happy to have a discussion about implementation, here or off-list, 
I'm sure I will learn a lot. But briefly, the Q I quoted above was 
carefully designed (not by me, I hasten to add!) to be a preudoprime to 
the first 307 prime bases, so it's something of a worst-case scenario 
for my version.

> BTW, it doesn't much matter that this is "pure Python" - for ints of 
> this size the bulk of the time regardless is spent in CPython's 
> C-coded bigint arithmetic.

A fair point, thank you.

> About the API, I can't agree to the one you propose.  Different 
> applications have different appropriate tradeoffs between degree of 
> certainty and time consumed - "one size fits all" doesn't fly here.
> 
> def probably_prime(n, maxsteps=20)
> 
> supplies a _default_ instead.  I don't want an API that's useful 
> _only_ to people who don't know what they're doing ;-)

It's not just for people who don't know what they're doing. It is for 
people who don't want to sweat the small details, they just want an 
answer True or False and are prepared to trust that the function author 
knows what they are doing.

If someone cares about the small details like how many bases to 
try, they might also care about details like:

- which specific bases are used;
- whether to use Miller-Rabin at all;
- how many trial divisions to do first;
- which specific primality test to use;

etc. What if the implementation shifts away from Miller-Rabin to (say) 
Baillie-PSW? Then your maxsteps parameter becomes meaningless. Do we 
deprecate it or leave it there in case the implementation changes again 
to something that has a concept of number of steps?

I think that if someone cares sufficiently about the details, then they 
probably won't be satisfied with a single isprime function, but may want 
is_fermat_prime, is_miller_rabin_prime, is_lucas_prime etc.

> > (By the way: for smallish numbers, under 2**64, no more than
> > twelve rounds of Miller-Rabin are sufficient to
> > deterministically decide whether a number is prime or not.
> 
> But only if you use a fixed set of 12 specific bases for which the 
> claim has been proved.

Correct. The first twelve primes make up such a minimal set.

http://oeis.org/A014233

--

___
Python tracker 

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

[issue39532] Pathlib: handling of `.` in paths and patterns creates unmatchable paths

[Isaac Muse]

Isaac Muse  added the comment:

The more I think about this, I think the normalization of paths is actually 
fine, it is the normalization of the patterns that is problematic, or more the 
difference in normalization. I could live with the pattern normalization of `.` 
and trailing `/` if it was at least consistent with what happens in paths. I 
still find the modification of the glob pattern in this manner surprising, but 
at least it wouldn't' cause cases like this to fail.

--

___
Python tracker 

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Kyle Stanley]

Kyle Stanley  added the comment:

> Thank you very muck, Kyle!

No problem. Thanks for reviewing and merging the PR, Antoine!

--

___
Python tracker 

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

[issue39532] Pathlib: handling of `.` in paths and patterns creates unmatchable paths

[Isaac Muse]

New submission from Isaac Muse :

It appears that the pathlib library strips out `.` in glob paths when they 
represent a directory. This is kind of a naive approach in my opinion, but I 
understand what was trying to be achieved.

When a path is given to pathlib, it normalizes it by stripping out 
non-essential things like `.` that represent directories, and strips out 
trailing `/` to give a path without unnecessary parts (the stripping of 
trailing `/` is another discussion).

But there is a small twist, when given an empty string or just a dot, you need 
to have something as the directory, so it allows a `.`.

So, it appears the idea was since this normalization is applied to paths, why 
not apply it to the glob patterns as well, so it does. But the special logic 
that ensures you don't have an empty string to match does not get applied to 
the glob patterns. This creates unmatchable paths:

>>> import pathlib
>>> str(pathlib.Path('.'))
'.'
>>> pathlib.Path('.').match('.')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python36\lib\pathlib.py", line 939, in match
raise ValueError("empty pattern")
ValueError: empty pattern

I wonder if it is appropriate to apply this `.` stripping to glob patterns. 
Personally, I think the glob pattern, except for slash normalization, should 
remain unchanged, but if it is to be normalized above and beyond this, at the 
very least should use the exact same logic that is applied to the paths.

--
components: Library (Lib)
messages: 361259
nosy: Isaac Muse
priority: normal
severity: normal
status: open
title: Pathlib: handling of `.` in paths and patterns creates unmatchable paths
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[Jeremy Kloth]

Jeremy Kloth  added the comment:

+1, obviously, as I came to the same conclusion above (see msg361122)

--

___
Python tracker 

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

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Random idea (not carefully thought-out):  Would it be simpler to have these 
objects just ignore their refcount by having dealloc() be a null operation or 
having it set the refcount back to a positive number).  That would let 
sub-interpreters share the objects without worrying about race-conditions on 
incref/decref operations.  To make this work, the objects can register 
themselves as permanent, shared, objects; then, during shutdown, we could 
explicitly call a hard dealloc on those objects.

--

___
Python tracker 

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

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Is the sub-interpreter PEP approved?   If not, I had thought the plan was to 
only implement PRs that made clean-ups that would have been necessary anyway.

--
nosy: +rhettinger

___
Python tracker 

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

[issue39492] reference cycle affecting Pickler instances (Python3.8+)

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 17236873392533ce0c5d7bbf52cbd61bca171c59 by Antoine Pitrou in 
branch '3.8':
[3.8] bpo-39492: Fix a reference cycle between reducer_override and a Pickler 
instance (GH-18266) (#18316)
https://github.com/python/cpython/commit/17236873392533ce0c5d7bbf52cbd61bca171c59


--

___
Python tracker 

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

[issue39492] reference cycle affecting Pickler instances (Python3.8+)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you for the PR!

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

___
Python tracker 

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

[issue39492] reference cycle affecting Pickler instances (Python3.8+)

[Antoine Pitrou]

Change by Antoine Pitrou :


--
pull_requests: +17692
pull_request: https://github.com/python/cpython/pull/18316

___
Python tracker 

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

[issue39531] Memory Leak in multiprocessing.Pool()

[EMO]

New submission from EMO :

After even deleting all variables it still reserves memory of around a GB.

--
components: Library (Lib)
files: User's.py
messages: 361253
nosy: EMO
priority: normal
severity: normal
status: open
title: Memory Leak in multiprocessing.Pool()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48877/User's.py

___
Python tracker 

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

[issue39492] reference cycle affecting Pickler instances (Python3.8+)

[miss-islington]

miss-islington  added the comment:


New changeset 0f2f35e15f9fbee44ce042b724348419d8136bc5 by Pierre Glaser in 
branch 'master':
bpo-39492: Fix a reference cycle between reducer_override and a Pickler 
instance (GH-18266)
https://github.com/python/cpython/commit/0f2f35e15f9fbee44ce042b724348419d8136bc5


--
nosy: +miss-islington

___
Python tracker 

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

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Tim Peters]

Tim Peters  added the comment:

[Steven]
> ... Try it on numbers like this:
> ...
> Q = P*(313*(P-1)+1)*(353*(P-1)+1)
>
> Q is a 397 digit Carmichael Number. Its smallest factor is P,
> which has 131 digits.
> ...
> My old and slow PC can prove that Q is a composite number,
> using pure Python, in less than six seconds.
>
> And I'm sure that a better programmer than me would be
> able to shave off some of that time.

The pure-Python Miller-Rabin code i posted in the aforementioned thread is 
typically at least 100 times faster than that.  But it's not deterministic.  
Because it tries (pseudo)random bases, it all depends on how many it needs to 
try on each run before finding a witness to that Q is composite.  It usually 
(at least 75% of runs) finds one on the first try.

BTW, it doesn't much matter that this is "pure Python" - for ints of this size 
the bulk of the time regardless is spent in CPython's C-coded bigint 
arithmetic.  I expect that your code must be doing more than _just_ 
Miller-Rabin, and in the Q case is paying through the nose for "optimizations" 
that all fail before getting to Miller-Rabin.

About the API, I can't agree to the one you propose.  Different applications 
have different appropriate tradeoffs between degree of certainty and time 
consumed - "one size fits all" doesn't fly here.

def probably_prime(n, maxsteps=20)

supplies a _default_ instead.  I don't want an API that's useful _only_ to 
people who don't know what they're doing ;-)
 

> (By the way: for smallish numbers, under 2**64, no more than
> twelve rounds of Miller-Rabin are sufficient to
> deterministically decide whether a number is prime or not.

But only if you use a fixed set of 12 specific bases for which the claim has 
been proved.  "Real" Miller-Rabin picks bases at random, relying only on 
properties that have been proved independent of the argument size.

[Vedran]
> Tim: Considering that congruence is _defined_ as
> x=y(mod m) :<=> m|y-x, it's
> really not so surprising. :-)

Didn't say it was ;-)  Was just noting the odd coincidence that I just happened 
to stumble into a real use for lcm(), not previously mentioned in this report, 
while doing something else.

--

___
Python tracker 

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

[issue35885] configparser: indentation

[SilentGhost]

SilentGhost  added the comment:

I would suggest adding indent parameter to the write method, it would default 
to an empty string and could be used directly in the formatting operation.

--
nosy: +SilentGhost

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yes, it is what I meant.

Many code written before 3.7 use get_event_loop() because there was no 
get_running_loop() yet. Now, to avoid deprecation (and making the code more 
robust) it should be rewritten with using get_running_loop() or 
get_event_loop() depending on Python version. It is cumbersome, and causes a 
code churn.

--

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Andrew Svetlov]

Change by Andrew Svetlov :


--
components: +asyncio
nosy: +yselivanov

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Serhiy, maybe I had not understood your proposal properly.

If you are asking about deprecating get_event_loop() call from outside of async 
code but implicit call get_running_loop() without a warning if called from 
async function -- it sounds like a brilliant idea.

Something like:

def get_event_loop():
current_loop = _get_running_loop()
if current_loop is not None:
return current_loop
warnings.warn("...", DeprecationWarning)  
return get_event_loop_policy().get_event_loop()

--

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Currently, I'm talking about adding a deprecation only.
The asyncio.get_event_loop() function will stay in Python for a while in 
deprecated status. I don't know the exact period but it should be 3 releases at 
least I guess, with possibly extending to 5 releases if needed.

--

___
Python tracker 

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

[issue39524] Escape sequences in doc string of ast._pad_whitespace

[Eric V. Smith]

Eric V. Smith  added the comment:

I think this would be an improvement, and an good issue for a newcomer.

I'd vote for the r-string, but it doesn't really matter.

--
keywords: +easy, newcomer friendly
nosy: +eric.smith
stage:  -> needs patch

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Will asyncio.get_event_loop() be removed or made an alias of 
asyncio.get_running_loop()? The latter could minimize the disruption of the 
existing code.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue35885] configparser: indentation

[Ido Michael]

Ido Michael  added the comment:

Can I take this?
What needs to be done? adding an indent flag and if it's passed indent the keys?

--
nosy: +Ido Michael

___
Python tracker 

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

[issue38101] Update devguide triaging keywords

[Ido Michael]

Ido Michael  added the comment:

It treats the PR as a cpython while it's on the devguide repo, here is the link:
https://github.com/python/devguide/pull/570

--

___
Python tracker 

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

[issue38101] Update devguide triaging keywords

[Ido Michael]

Ido Michael  added the comment:

Added a PR: GH-570

--

___
Python tracker 

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

[issue39128] Document happy eyeball parameters in loop.create_connection signature docs

[Ido Michael]

Ido Michael  added the comment:

Created PR added arguments to method signature in doc.
GH-18315

--
nosy: +Ido Michael

___
Python tracker 

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

[issue39128] Document happy eyeball parameters in loop.create_connection signature docs

[Ido Michael]

Change by Ido Michael :


--
keywords: +patch
pull_requests: +17691
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18315

___
Python tracker 

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

[issue10572] Move test sub-packages to Lib/test

[Ido Michael]

Ido Michael  added the comment:

Are there any conclusions? what needs to be done?

--
nosy: +Ido Michael

___
Python tracker 

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

[issue38691] [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

[Ido Michael]

Ido Michael  added the comment:

Created this PR: GH-18314

--
nosy: +Ido Michael

___
Python tracker 

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

[issue38691] [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

[Ido Michael]

Change by Ido Michael :


--
keywords: +patch
pull_requests: +17690
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18314

___
Python tracker 

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

[issue39274] Conversion from fractions.Fraction to bool

[SilentGhost]

SilentGhost  added the comment:

"Successful" PR would be merged into master. This issue is still in "patch 
review" stage.

--
nosy: +SilentGhost

___
Python tracker 

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

[issue39274] Conversion from fractions.Fraction to bool

[Ido Michael]

Ido Michael  added the comment:

Hi all,

I think this issue can be closed right?
Saw a successful PR.

--
nosy: +Ido Michael

___
Python tracker 

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

[issue37404] asyncio sock_recv blocks on ssl sockets.

[Ido Michael]

Ido Michael  added the comment:

Sorry it broke the version, what could I have done to avoid this?
Also can we close this issue?

--

___
Python tracker 

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

[issue39530] Documentation about comparisons between numeric types is misleading

[Mark Dickinson]

Mark Dickinson  added the comment:

Related SO question: 
https://stackoverflow.com/questions/60005876/how-does-python-compare-int-to-float-objects

--

___
Python tracker 

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

[issue39530] Documentation about comparisons between numeric types is misleading

[Mark Dickinson]

New submission from Mark Dickinson :

The documentation[1] for comparisons between mixed types says:

> [...] when a binary arithmetic operator has operands of different
> numeric types, the operand with the "narrower" type is widened to
> that of the other, where integer is narrower than floating point,
> which is narrower than complex. Comparisons between numbers of
> mixed type use the same rule.

That "use the same rule" part of the last sentence is misleading: it suggests 
that (for example) when an int is compared with a float, the int is first 
converted to a float, and then the two floats are compared. But that's not what 
actually happens: instead, the exact values of the int and float are compared. 
(And it's essential that equality comparisons happen that way, else equality 
becomes intransitive and dictionaries with numeric keys get very confused as a 
result.)

I suggest dropping the last sentence and adding a new paragraph about 
comparisons between numbers of mixed type.




[1] 
https://github.com/python/cpython/blob/master/Doc/library/stdtypes.rst#numeric-types-classint-classfloat-classcomplex

--
assignee: docs@python
components: Documentation
messages: 361234
nosy: docs@python, mark.dickinson
priority: normal
severity: normal
status: open
title: Documentation about comparisons between numeric types is misleading
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue39434] Remove unnecessary logic of float __floordiv__

[Dong-hee Na]

Dong-hee Na  added the comment:

Thanks good catch :)

--

___
Python tracker 

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

[issue28312] Minor change - more direct hint re: multiple machine sizes and LONG_BIT conflicts

[Michael Felt]

Change by Michael Felt :


--
keywords: +patch
pull_requests: +17689
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18313

___
Python tracker 

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 339fd46cb764277cbbdc3e78dcc5b45b156bb6ae by Kyle Stanley in 
branch 'master':
bpo-39349: Add *cancel_futures* to Executor.shutdown() (GH-18057)
https://github.com/python/cpython/commit/339fd46cb764277cbbdc3e78dcc5b45b156bb6ae


--

___
Python tracker 

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you very muck, Kyle!

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

___
Python tracker 

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

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

[Michael Felt]

Change by Michael Felt :


--
versions: +Python 3.8, Python 3.9 -Python 2.7

___
Python tracker 

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

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

[Michael Felt]

Change by Michael Felt :


--
keywords: +patch
pull_requests: +17688
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18312

___
Python tracker 

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

[issue39434] Remove unnecessary logic of float __floordiv__

[Mark Dickinson]

Mark Dickinson  added the comment:

@shihai1991 Good catch! Now fixed.

--

___
Python tracker 

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

[issue39434] Remove unnecessary logic of float __floordiv__

[Mark Dickinson]

Change by Mark Dickinson :


--
pull_requests: +17687
pull_request: https://github.com/python/cpython/pull/18311

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Andrew Svetlov]

New submission from Andrew Svetlov :

Yuri proposed it for Python 3.8 but at that time the change was premature.
Now we can reconsider it for 3.9

The problem is that asyncio.get_event_loop() not only returns a loop but also 
creates it on-demand if the thread is main and the loop doesn't exist.  

It leads to weird errors when get_event_loop() is called at import-time and 
asyncio.run() is used for asyncio code execution.

get_running_loop() is a much better alternative when used *inside* a running 
loop, run() should be preferred for calling async code at top-level. Low-level 
new_event_loop()/loop.run_until_complete() are still present to run async code 
if top-level run() is not suitable for any reason.

asyncio.run() was introduced in 3.7, deprecation on get_event_loop() in 3.8 was 
able to complicate support of 3.5/3.6 by third-party libraries.
3.5 now reached EOL, 3.6 is in the security-fix mode and going close to EOL. 
Most people are migrated to newer versions already if they care.
The maintenance burden of the introduced deprecation should be pretty low.

--
messages: 361229
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Deprecate get_event_loop()

___
Python tracker 

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

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

[Michael Felt]

Michael Felt  added the comment:

This is something from long long ago - time to get it completed.

The (remaining) issue is: "c" and "m" may not be shared libraries - so nothing 
is ever found and the test is "skipped" but reports itself as PASSED.

The original issue (fixed for AIX in Python3.7) would be if find_library itself 
is broken and always returns NULL/None.

Again, the tests says "PASSED" when actually it was skipped.

Following this - Martin's suggestion seems a viable solution.

--
type:  -> behavior

___
Python tracker 

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

[issue39483] Proposial add loop parametr to run in asyncio

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue39434] Remove unnecessary logic of float __floordiv__

[hai shi]

hai shi  added the comment:

Small style question: using 5 spaces in 
https://github.com/python/cpython/blob/master/Objects/floatobject.c#L655-L664 
after PR 18147 merged.
Due to bpo don't receive style quesiton, I commented here.

--
nosy: +shihai1991

___
Python tracker 

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

[issue12915] Add inspect.locate and inspect.resolve

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests: +17686
pull_request: https://github.com/python/cpython/pull/18310

___
Python tracker 

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

[issue39526] print(text1.get(1.2,1.5))

[SilentGhost]

Change by SilentGhost :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue39526] print(text1.get(1.2,1.5))

[mlwtc]

mlwtc  added the comment:

ok, I see, Thank U.

--

___
Python tracker 

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

[issue39350] Remove deprecated fractions.gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

Apologies, I think I moved the discussion off-track. The first order of 
business should be to fix the regression. We can discuss behaviour changes 
after that.

I've opened GH-18309 as a quick fix for the regression.

--

___
Python tracker 

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

[issue39350] Remove deprecated fractions.gcd()

[Mark Dickinson]

Change by Mark Dickinson :


--
pull_requests: +17685
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18309

___
Python tracker 

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

[issue39513] NameError: name 'open' is not defined

[Vinay Sajip]

Vinay Sajip  added the comment:

Well, my comment/request was prompted by whether this issue is a duplicate of 
bpo-26789, because it's not clear from the OP. If it is, then it can be closed 
as such. I don't think this is specifically a logging problem, more a case of 
how things become inaccessible as the interpreter shuts down. Any code which 
calls "open" (or some other builtins) would run into this problem, not just and 
not specifically logging. I'm not sure, but I don't believe we have a good 
answer to this problem in general.

--

___
Python tracker 

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

[issue39526] print(text1.get(1.2,1.5))

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

1.30 is the same as 1.3 in Python.

You perhaps want to use '1.30'.

--
nosy: +serhiy.storchaka

___
Python tracker 

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