[issue38164] polishing asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

Closed by the new asyncio stream API reversion in GH-16485 and GH-16482.

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Change by Kyle Stanley :


--
status: closed -> open

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Change by Kyle Stanley :


--
stage: resolved -> commit review

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

> I've reverted the code. Andrew, would really appreciate if you could quickly 
> do a post commit review.

Oops, I'll reopen it.

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Change by Kyle Stanley :


--
stage: commit 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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 1c19d656a79a00f58361ceb61c0a6d1faf90c686 by Yury Selivanov in 
branch '3.8':
bpo-38242: Revert "bpo-36889: Merge asyncio streams (GH-13251)" (#16482) 
(#16485)
https://github.com/python/cpython/commit/1c19d656a79a00f58361ceb61c0a6d1faf90c686


--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:

I've reverted the code. Andrew, would really appreciate if you could quickly do 
a post commit review.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 1c19d656a79a00f58361ceb61c0a6d1faf90c686 by Yury Selivanov in 
branch '3.8':
bpo-38242: Revert "bpo-36889: Merge asyncio streams (GH-13251)" (#16482) 
(#16485)
https://github.com/python/cpython/commit/1c19d656a79a00f58361ceb61c0a6d1faf90c686


--

___
Python tracker 

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

[issue38163] AsyncMock child mocks should detect their type

[Lisa Roach]

Lisa Roach  added the comment:


New changeset 21f24ead90c22d0e2c2ebf14a64b37d99de54b33 by Lisa Roach in branch 
'3.8':
[3.8] bpo-38163: Child mocks detect their type as sync or async (GH-16471) 
(GH-16484)
https://github.com/python/cpython/commit/21f24ead90c22d0e2c2ebf14a64b37d99de54b33


--

___
Python tracker 

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

[issue38163] AsyncMock child mocks should detect their type

[Lisa Roach]

Change by Lisa Roach :


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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +16071
pull_request: https://github.com/python/cpython/pull/16485

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +16070
pull_request: https://github.com/python/cpython/pull/16485

___
Python tracker 

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

[issue38163] AsyncMock child mocks should detect their type

[Lisa Roach]

Change by Lisa Roach :


--
pull_requests: +16069
pull_request: https://github.com/python/cpython/pull/16484

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 6758e6e12a71ef5530146161881f88df1fa43382 by Yury Selivanov in 
branch 'master':
bpo-38242: Revert "bpo-36889: Merge asyncio streams (GH-13251)" (#16482)
https://github.com/python/cpython/commit/6758e6e12a71ef5530146161881f88df1fa43382


--

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 6758e6e12a71ef5530146161881f88df1fa43382 by Yury Selivanov in 
branch 'master':
bpo-38242: Revert "bpo-36889: Merge asyncio streams (GH-13251)" (#16482)
https://github.com/python/cpython/commit/6758e6e12a71ef5530146161881f88df1fa43382


--

___
Python tracker 

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

[issue38163] AsyncMock child mocks should detect their type

[Lisa Roach]

Lisa Roach  added the comment:


New changeset 3667e1ee6c90e6d3b6a745cd590ece87118f81ad by Lisa Roach in branch 
'master':
bpo-38163: Child mocks detect their type as sync or async (GH-16471)
https://github.com/python/cpython/commit/3667e1ee6c90e6d3b6a745cd590ece87118f81ad


--

___
Python tracker 

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

[issue37096] Add large-file tests for modules using sendfile(2)

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
components: +Tests -Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue37096] Add large-file tests for modules using sendfile(2)

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:


New changeset 5bcc6d89bcb622a6786fff632fabdcaf67dbb4e2 by Giampaolo Rodola in 
branch 'master':
bpo-37096: Add large-file tests for modules using sendfile(2) (GH-13676)
https://github.com/python/cpython/commit/5bcc6d89bcb622a6786fff632fabdcaf67dbb4e2


--

___
Python tracker 

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

[issue38045] enum.Flag instance creation is slow

[hongweipeng]

Change by hongweipeng :


--
pull_requests: +16068
pull_request: https://github.com/python/cpython/pull/16483

___
Python tracker 

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

[issue38161] AsyncMock add `.awaited` like `.called`

[Lisa Roach]

Lisa Roach  added the comment:


New changeset 36e7e4aabb662e86e9dace1a6447492f45868654 by Lisa Roach (Miss 
Islington (bot)) in branch '3.8':
bpo-38161: Removes _AwaitEvent from AsyncMock. (GH-16443) (GH-16481)
https://github.com/python/cpython/commit/36e7e4aabb662e86e9dace1a6447492f45868654


--

___
Python tracker 

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

[issue38136] Remove AsyncMock.assert_awaited_*

[Lisa Roach]

Change by Lisa Roach :


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

[issue38093] Update MagicMock __aenter__ and __aexit__ to return AsyncMock's

[Lisa Roach]

Change by Lisa Roach :


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

[issue38108] Everything in Mock should inherit from Base

[Lisa Roach]

Change by Lisa Roach :


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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +16066
pull_request: https://github.com/python/cpython/pull/16482

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Yury Selivanov]

Change by Yury Selivanov :


--
pull_requests: +16067
pull_request: https://github.com/python/cpython/pull/16482

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Ah, nevermind my last comment - yes. handle_weakrefs will clear all weakrefs to 
the objects we know are trash.

--

___
Python tracker 

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

[issue38161] AsyncMock add `.awaited` like `.called`

[miss-islington]

Change by miss-islington :


--
pull_requests: +16065
pull_request: https://github.com/python/cpython/pull/16481

___
Python tracker 

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

[issue38108] Everything in Mock should inherit from Base

[Lisa Roach]

Lisa Roach  added the comment:


New changeset b76ab352405df105c2d459fc66ef8dc98e47b37c by Lisa Roach (Miss 
Islington (bot)) in branch '3.8':
bpo-38108: Makes mock objects inherit from Base (GH-16060) (GH-16470)
https://github.com/python/cpython/commit/b76ab352405df105c2d459fc66ef8dc98e47b37c


--

___
Python tracker 

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

[issue38161] AsyncMock add `.awaited` like `.called`

[Lisa Roach]

Lisa Roach  added the comment:


New changeset 25e115ec00b5f75e3589c9f21013c47c21e1753f by Lisa Roach in branch 
'master':
bpo-38161: Removes _AwaitEvent from AsyncMock. (GH-16443)
https://github.com/python/cpython/commit/25e115ec00b5f75e3589c9f21013c47c21e1753f


--

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

> I see that handle_weakrefs() calls _PyWeakref_ClearRef() and that
> will clear the weakref even if it doesn't have callback.  So, I
> think that takes care for the hole I was worried about.  I.e. a
> __del__ method could have a weakref to an non-valid object.
> However, because handle_weakrefs() will find that weakref, it will
> have been cleared when the __del__ method executes.

There's no problem with objects we _know_ are trash.  Their finalizers are all 
force-run before delete_garbage starts.

It's "surprise" finalizers, triggered by refcounts falling to 0 while 
delete_garbage is running.  They're invisible to handle_weakrefs.

However, to the extent that delete_garage is effective in deallocating objects 
soon after clearing them, to that extent also will invalidated objects clear 
weak references to them as a matter of course.












'

--

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

> Note that my flags show that W *is* in 'unreachable'.  It has
> to be otherwise F would not have tp_clear called on it.

Right!  W holds a strong reference to F, so if W were thought to be reachable, 
F would be too.  But F isn't.


> But when delete_garbage() gets done, it moves the object to 'old'.  I
> think that means gc.get_objects() called after the collection completes
> can reveal objects that have had their tp_clear called (if tp_clear
> didn't result in them being freed).

If the tp_clear implementations aren't complete enough to break all cycles, 
that could happen.

In a world that took cyclic trash "very seriously", it would move them to a new 
internal list instead, then at the end of the function die if that list isn't 
empty ("we ran all tp_clears but cyclic trash still remains:  your object 
implementations inherently leak memory").


> I think the difference is that non-weakref finalizers have strong
> references to objects that they can access when they run. 
> So, if we haven't found them, they will keep all the objects that
> they refer to alive as well (subtract_refs() cannot account for
> those refs).  So those objects will all be valid.

That's persuasive :-)  For essentially the same reason, if a "surprise" 
finalizer runs during delete_garbage, it can't ressurect (or in any other way 
access) anything we knew was trash.


> There seems a hole though.  Non-weakref finalizers could have a
> weakref (without callback) to something in the garbage set.  Then,
> when the finalizer runs during delete_garbage(), that finalizer
> code can see non-valid objects via the weakref.  I think this can
> only happen if there are missing/incomplete tp_traverse methods.

Which is what I mean by a "surprise" finalizer:  a trash object T with a 
finalizer but we don't KNOW T is trash.  If we know T is trash then we 
force-run its finalizer before delete_garbage starts, so it can only see valid 
objects.


> We can have finalizer code running during delete_garbage().

Except that was never the intent (quite the contrary!).  The more people have 
moved to demanding that gc be a full-featured all-purpose collector, the more 
important it becomes that types implement what such a thing needs.  At a bare 
minimum, any robust gc needs to be 100% sure of the difference between trash 
and non-trash, and tp_traverse is the one & only way we have to discover 
anything about the object graph.  "Almost all" types that can participate in 
cycles need to implement it.

Or suffer rare shutdown segfaults that somehow nobody ever managed to stumble 
into before ;-)

--

___
Python tracker 

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

[issue38308] Add optional weighting to statistics.harmonic_mean()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Sounds like a great idea to me.

Thanks,

Steven

--

___
Python tracker 

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

[issue38318] Issues linking with ncurses and tinfo (cannot resolve symbols)

[Ammar Askar]

Change by Ammar Askar :


--
nosy: +skrah, twouters

___
Python tracker 

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

[issue38318] Issues linking with ncurses and tinfo (cannot resolve symbols)

[Michael Everitt]

Michael Everitt  added the comment:

May have confused the '_readline' extension with the '_ncurses' extension .. 
apologies!

attaching build.log from x86_64.

--
Added file: https://bugs.python.org/file48632/build-x86_64-uclibc.log

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> We can have finalizer code running during delete_garbage().  That
> code should not have access to non-valid objects.  Weakrefs seem be
> a way to violate that.  handle_weakrefs() take care of some of them
> but it seems there are other issues.

I see that handle_weakrefs() calls _PyWeakref_ClearRef() and that
will clear the weakref even if it doesn't have callback.  So, I
think that takes care for the hole I was worried about.  I.e. a
__del__ method could have a weakref to an non-valid object.
However, because handle_weakrefs() will find that weakref, it will
have been cleared when the __del__ method executes.

--

___
Python tracker 

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

[issue38318] Issues linking with ncurses and tinfo (cannot resolve symbols)

[Michael Everitt]

New submission from Michael Everitt :

tinfo library detection as part of ncurses is inconsistent, and causes build 
failure when expected symbols aren't found at link-time.
This breaks compilation of the 'readline' module as the attached log shows.
It seems to work in some configurations and not others, different arches and 
libc's seem to be affected differently (suspect linker variations).
It would appear that uclibc-ng triggers this failure consistently, as I have 
verified on both x86_64 and armv7a Arches.

See https://bugs.gentoo.org/692128 for further details.

--
components: Build
files: file_692128.txt
messages: 353523
nosy: veremitz
priority: normal
severity: normal
status: open
title: Issues linking with ncurses and tinfo (cannot resolve symbols)
type: compile error
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48631/file_692128.txt

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> Fleshing out something I left implicit: if there's a trash object T
> with a finalizer but we don't KNOW it's trash, we won't force-run its
> finalizer before delete_garbage starts either.  Then, really the same
> thing: we may tp_clear some piece of trash T's finalizer needs before
> enough cycles are broken that T's finalizer gets run as a routine
> consequence of T's refcount falling to 0.

Definition: a 'valid' object is one that hasn't had tp_clear called

I think the difference is that non-weakref finalizers have strong
references to objects that they can access when they run.  So, if we
haven't found them, they will keep all the objects that they refer
to alive as well (subtract_refs() cannot account for those refs).
So those objects will all be valid.

There seems a hole though.  Non-weakref finalizers could have a
weakref (without callback) to something in the garbage set.  Then,
when the finalizer runs during delete_garbage(), that finalizer code
can see non-valid objects via the weakref.  I think this can only happen if 
there are missing/incomplete tp_traverse methods.

We can have finalizer code running during delete_garbage().  That
code should not have access to non-valid objects.  Weakrefs seem be
a way to violate that.  handle_weakrefs() take care of some of them
but it seems there are other issues.

--

___
Python tracker 

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

[issue23284] Improve termcap detection in setup.py

[Michael Everitt]

Change by Michael Everitt :


--
nosy: +veremitz

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Since W is in the unreachable set, we should not be executing its callback.  
Would the attached rough patch (gc_disable_wr_callback.txt) be a possible fix?  
When we find W inside handle_weakrefs(), we mark it as trash and will not 
execute the callback.

This is similar to Pablo's bpo-38009 but I think attacks the problem in a 
better way.  Having func_clear() being run is only one possible bad outcome of 
executing the callback.  We want to avoid executing *any* user level Python 
code if the weakref has access to objects found by the GC and which have 
tp_clear called on them.

--
Added file: https://bugs.python.org/file48630/gc_disable_wr_callback.txt

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I hacked up my copy of CPython to add flags to PyObject to see the
GC state of objects.  That makes it easier to know if an object is
in the 'unreachable' list or not.

> We must know that F is trash, else we never would have called tp_clear(F).

Yup.  In the crashing test program, F is in 'unreachable'.

> We must NOT know CT is trash.  If we did know that, then we would
> have found W too, and then:

Yes again.  CT is not in 'unreachable'.

> So if CT _is_ trash, we didn't know it.  If/when delete_garbage
> broke enough cyclea that CT's refcount fell to 0, other parts of
> Python would have invoked W's callback as a matter of course, with
> F possibly already tp_clear'ed.

I haven't verified this but it must be what's happening.  Note that my flags
show that W *is* in 'unreachable'.  It has to be otherwise F would not have
tp_clear called on it.

> Neil, at a high level it's not REALLY surprisimg that gc can screw
> up if it can't tell the difference between trash & treasure ;-)
> Long ago, though, it's possible the only real failure mode was
> leaking objects that were actually unreachable.

It has been so long I can't be sure the GC worked that way but I think
it did.  It would only call tp_clear on things it could really prove
were garbage.  If tp_clear didn't actually break the cycle, the only
harmful result was leaking memory.  That behavior is similar to a
conservative GC.

> Offhand not worried about get_objects().  That returns objects from
> generation lists, but gc moves possible trash among temporary
> internal (not generation) lists as it goes along.

But when delete_garbage() gets done, it moves the object to 'old'.  I
think that means gc.get_objects() called after the collection completes
can reveal objects that have had their tp_clear called (if tp_clear
didn't result in them being freed).

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

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

[issue38164] polishing asyncio Streams API

[Caleb Hattingh]

Change by Caleb Hattingh :


--
nosy: +cjrh

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Caleb Hattingh]

Change by Caleb Hattingh :


--
nosy: +cjrh

___
Python tracker 

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

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

Change by STINNER Victor :


--
Removed message: https://bugs.python.org/msg353517

___
Python tracker 

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

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

(Oops, I posted a comment to the wrong issue, it was a comment for bpo-38317.)

--

___
Python tracker 

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

[issue33135] Define field prefixes for the various config structs

[STINNER Victor]

STINNER Victor  added the comment:

Warnings options priority are badly documented. The latest major change was 
bpo-20361 when -b command line option changed to get the highest priority (-b > 
-W).

--

___
Python tracker 

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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[STINNER Victor]

STINNER Victor  added the comment:

Oh, the documentation in the PEP 587 was also wrong. I updated it:
https://github.com/python/peps/commit/16bc2821eeb09b4692c372a5a359fd28993cd29b

The "warnings options priority" is currently not documented at:
https://docs.python.org/dev/c-api/init_config.html

The latest major change was bpo-20361 when -b command line option changed to 
get the highest priority (-b > -W).

cc Nick Coghlan

--
nosy: +ncoghlan
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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[miss-islington]

miss-islington  added the comment:


New changeset c9ed9e6fc76323ed537fb79d4232bcd27d82c57e by Miss Islington (bot) 
in branch '3.8':
bpo-38317: Fix PyConfig.warnoptions priority (GH-16478)
https://github.com/python/cpython/commit/c9ed9e6fc76323ed537fb79d4232bcd27d82c57e


--
nosy: +miss-islington

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Fleshing out something I left implicit:  if there's a trash object T with a 
finalizer but we don't KNOW it's trash, we won't force-run its finalizer before 
delete_garbage starts either.  Then, really the same thing:  we may tp_clear 
some piece of trash T's finalizer needs before enough cycles are broken that 
T's finalizer gets run as a routine consequence of T's refcount falling to 0.

--

___
Python tracker 

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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[miss-islington]

Change by miss-islington :


--
pull_requests: +16064
pull_request: https://github.com/python/cpython/pull/16479

___
Python tracker 

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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fb4ae152a9930f0e00cae8b2807f534058cf341a by Victor Stinner in 
branch 'master':
bpo-38317: Fix PyConfig.warnoptions priority (GH-16478)
https://github.com/python/cpython/commit/fb4ae152a9930f0e00cae8b2807f534058cf341a


--

___
Python tracker 

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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue38317] PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority

[STINNER Victor]

New submission from STINNER Victor :

The PEP 587 says that PyConfig.warnoptions has the highest priority for 
warnings options:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules

But in the current implementation, PyConfig.warnoptions has... the lowest 
priority :-(

Attached PR not only fix the issue but also add tests to ensure that every ways 
to set warnings options have the expected priority.

Priority of warnings options, lowest to highest:

- any implicit filters added by _warnings.c/warnings.py
- PyConfig.dev_mode: "default" filter
- PYTHONWARNINGS environment variable
- '-W' command line options
- PyConfig.bytes_warning ('-b', '-bb'): "default::BytesWarning"
  or "error::BytesWarning" filter
- early PySys_AddWarnOption() calls
- PyConfig.warnoptions

--
components: Interpreter Core
messages: 353513
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyConfig (PEP 587): PyConfig.warnoptions should have the highest priority
versions: 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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Tim Peters]

Tim Peters  added the comment:

Sorry, this is very hard for me - broke an arm near the shoulder on Tuesday, 
and between bouts of pain and lack of good sleep, concentration is nearly 
impossible.  Typing with one hand just makes it worse :-(

We must know that F is trash, else we never would have called tp_clear(F).

We must NOT know CT is trash.  If we did know that, then we would have found W 
too, and then:

1. If we thought W was trash, we would have suppressed the callback.

2. If we thought W was not trash, we would have invoked the callback directly, 
long before delete_garbage even started (i.e., F would have been intact).

So if CT _is_ trash, we didn't know it.  If/when delete_garbage broke enough 
cyclea that CT's refcount fell to 0, other parts of Python would have invoked 
W's callback as a matter of course, with F possibly already tp_clear'ed.

Neil, at a high level it's not REALLY surprisimg that gc can screw up if it 
can't tell the difference between trash & treasure ;-)  Long ago, though, it's 
possible the only real failure mode was leaking objects that were actually 
unreachable.

Offhand not worried about get_objects().  That returns objects from generation 
lists, but gc moves possible trash among temporary internal (not generation) 
lists as it goes along.

Am concerned that weakref callbacks may not be the only hole.  We force-run 
finalizers before ever calling tp_clear for the same reason we force-run 
weakref callbacks:  finalizers may also need to access trash objecta while 
they're still sane.  Having finalizers on objects in trash cycles isn't special 
anymore (we used to refuse to run them).  But my brain is fried again for now 
;-)

--

___
Python tracker 

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

[issue38316] docs: Code object's "co_stacksize" field is described with mistake

[Ammar Askar]

Ammar Askar  added the comment:

Yeah, that parenthesized bit seems a bit weird: co_stacksize really has nothing 
to do with the number of variables, it's just that certain opcodes 
(https://docs.python.org/3/library/dis.html#python-bytecode-instructions) push 
and pop off the stack, co_stacksize is just the largest the stack will ever 
grow to from these operations.

For example:

  >>> def f():
  ...   a = 1
  ...   b = 2
  ...   c = 3
  ...   g(a, b, c)
  ...
  >>> f.__code__.co_stacksize
  4

and

  >>> def g():
  ...   g(1, 2, 3)
  ...
  >>> g.__code__.co_stacksize
  4

have the exact same stack size despite differences in variables because the 
call to `g` has to push all 3 operands (and g itself) onto the stack.

--
nosy: +ammar2

___
Python tracker 

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

[issue38304] PEP 587 implementation is not ABI forward compatible

[STINNER Victor]

STINNER Victor  added the comment:

> Both it and struct_size should be removed, as we don't support updating an 
> embedded Python runtime to a new X.Y.0 release without rebuilding the 
> embedding application.

See my reply on python-dev:
https://mail.python.org/archives/list/python-...@python.org/message/ZE5K7MEKN32YGHNA5457AROWUNI7JOWC/

--

___
Python tracker 

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

[issue38304] PEP 587 implementation is not ABI forward compatible

[STINNER Victor]

STINNER Victor  added the comment:

> The hidden _config_version field wasn't in the accepted PEP.

It was in the accepted PEP and I replaced it with struct_size:
https://github.com/python/peps/commit/afa38c0bef7738b8fcc3173daee8488e0420833d

I suggest to discuss the issue on the thread that I started on python-dev.

--

___
Python tracker 

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

[issue38316] docs: Code object's "co_stacksize" field is described with mistake

[Paul Sokolovsky]

New submission from Paul Sokolovsky :

CPython's Data Model -> Internal types -> Code objects, direct link as of 
version 3.7 is: 
https://docs.python.org/3.7/reference/datamodel.html?highlight=co_stacksize#index-55
 , states following:

* "co_nlocals is the number of local variables used by the function (including 
arguments);"
* "co_stacksize is the required stack size (including local variables);"

However, practical checking shows that co_stacksize is the required stack size 
WITHOUT local variables. One could argue about the meaning of "local variables" 
in the description of co_stacksize above, saying that what is meant is 
temporary stack variables of something. That's why I quoted above co_nlocals 
description too, it clearly shows that local variebles are local function 
variables (include functions args), and nothing else.

Code to reproduce:

==
def func():
a = 1
b = 2
c = 3

print("co_stacksize", func.__code__.co_stacksize)
print("co_nlocals", func.__code__.co_nlocals)
==

Result of running:
==
$ python3.7 script_under_test.py 
co_stacksize 1
co_nlocals 3
==

Clearly, co_stacksize doesn't include the size of local vars, or it would have 
been larger than co_nlocals in printout.

--
assignee: docs@python
components: Documentation
messages: 353508
nosy: docs@python, pfalcon
priority: normal
severity: normal
status: open
title: docs: Code object's "co_stacksize" field is described with mistake
versions: Python 3.5, Python 3.6, 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

[issue38313] Crash/No start

[Zachary Ware]

Zachary Ware  added the comment:

Sorry, but you've given us no information to work with here.  Which version of 
Python?  Which version of Windows?  What exactly are you trying to do?  What 
error message do you get?  Which distribution of Python are you using?  How did 
you install it?  Have you tried reinstalling it?

Without specific answers to at least most of those questions, there's nothing 
we can do to help you.

--
status: open -> pending

___
Python tracker 

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

[issue38006] Crash in remove() weak reference callback of weakref.WeakValueDictionary at Python exit

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Victor:
> I'm surprised that the function would be seen as "unreachable" if
> it's reference counter was equal to 135:

If all those references are contained within that garbage set, it is
possible.


Pablo:
> For the weakref to be handled correctly the ctypedescr needs to be
> identified correctly as part of the isolated cycle. If is not in
> the isolated cycle something may be missing tp_traverse or the GC
> flags. 

I think this analysis is correct.  I did some poking around with
using 'rr'.  It is very handy to run the program in reverse and use
conditional breakpoints based on pointer addresses.

The objects involved seem to be:

CF: cfield
CT: ctypedescr
F: function
W: weakref

They have the following structure:

CF -> CT -> W -> F

The first link the chain is not found by the GC because CF does not
implement tp_traverse.  All those objects are part of garbage kept
alive by the reference cycle and the GC calls delete_garbage() on
it.  CT is not part of 'unreachable' and handle_weakrefs() does not
find W.

What I previously said about tp_clear was incorrect.  We take great
pains to avoid running non-trivial code after calling tp_clear (no
finalizers and no callbacks).  So, the func_clear method should be
safe.  Even if tp_clear doesn't succeed in breaking the cycle, there
should be no way for user Python code to access those objects that
have had tp_clear called on them.  Is gc.get_objects() a hole in
this?  Seems like you could cause crashes with it.

This bug is surprising to me in another way.  If the analysis is
correct then fully implementing the GC protocols is no longer
optional (as it was when cyclic GC was first introduced).  If the GC
cannot find garbage weakrefs handle_weakrefs() doesn't work and we
end up with crashes like this.

Maybe Pablos fix to not call the weakref callback if we are in
delete_garbage() is a good enough band-aid.  The alternative would
seem to be ensuring that tp_traverse methods exist so that every
single reference can be followed by the GC.  I imagine that would be
a huge task and there are many extension types that don't have them.

--

___
Python tracker 

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

[issue38302] __rpow__ not reached when __ipow__ returns NotImplemented

[Ammar Askar]

Ammar Askar  added the comment:

This isn't the ternary form of pow(), the documentation there is referring to 
the `pow(base, exp, modulus)`.

--
nosy: +ammar2

___
Python tracker 

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

[issue38315] Provide defaultdict variant that passes key to default_factory

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The __missing__() method already fulfills this need:

   class DoubleDict(dict):

   def __missing__(self, key):
   return key * 2

If desired, it can also add entries:

   class DoubleDict(dict):

   def __missing__(self, key):
   self[key] = value = key * 2
   return value

--
nosy: +rhettinger
resolution:  -> rejected
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

[issue38302] __rpow__ not reached when __ipow__ returns NotImplemented

[hongweipeng]

hongweipeng  added the comment:

The document 
says(https://docs.python.org/3.9/reference/datamodel.html?highlight=__rpow__#object.__rpow__)：
>Note that ternary pow() will not try calling __rpow__() (the coercion rules 
>would become too complicated).

--
nosy: +hongweipeng

___
Python tracker 

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

[issue38315] Provide defaultdict variant that passes key to default_factory

[Mark Amery]

New submission from Mark Amery :

There seems to be at least some demand for the ability to have the key being 
accessed be passed to the factory function of a defaultdict. See e.g. 
https://stackoverflow.com/q/2912231/1709587 (13k views) or previous enhancement 
suggestion https://bugs.python.org/issue30408.

However, as noted on that issue, defaultdict cannot simply be modified to pass 
the key to the factory function without breaking backwards compatibility.

Perhaps it makes sense, then, to have a separate class in the collections 
module, perhaps called keydefaultdict, that is like defaultdict but whose 
factory function receives one argument, which is the key being accessed? Having 
this built into the standard library would be slightly more convenient than 
either making an ad-hoc dict subclass every time this functionality is needed 
or having to roll your own subclass like the one at 
https://stackoverflow.com/a/2912455/1709587.

--
components: Library (Lib)
messages: 353502
nosy: ExplodingCabbage
priority: normal
severity: normal
status: open
title: Provide defaultdict variant that passes key to default_factory
type: enhancement

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +16062
pull_request: https://github.com/python/cpython/pull/16476

___
Python tracker 

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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +16061
pull_request: https://github.com/python/cpython/pull/16476

___
Python tracker 

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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +16059
pull_request: https://github.com/python/cpython/pull/16475

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines

[Jason R. Coombs]

Change by Jason R. Coombs :


--
pull_requests: +16060
pull_request: https://github.com/python/cpython/pull/16475

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[Andrew Svetlov]

Change by Andrew Svetlov :


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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> Someone should look at how to do similar in 2.7 _if_ the project(s) that 
> complained about the problem rely on such behavior in their last 2.7 
> compatible releases.

Looking at the history, it seems that only two projects were mentioned, 
CherryPy and urllib3. For CherryPy, a workaround is in place such that the 2.7 
maintenance branch does not encounter this issue (the offending test was 
removed), and the master branch only supports Python 3. Similarly, urllib3 has 
a workaround that bypasses transmission of these bytes entirely. Therefore, the 
urgency is reduced.

I do feel a little uneasy recommending not to backport the bugfix to the 
versions where the change was introduced, as it leaves an opportunity for 
another project to encounter. I'll go ahead and prep a backport for Python 3.5 
and 2.7, with the understanding that the 2.7 change may be rejected or deferred 
until requested.

--

___
Python tracker 

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

[issue38314] Implement unix read_pipe.is_reading() method

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Nothing special.
There is UnixReadPipeTransportTests test cases inside 
Lib/test/test_asyncio/test_unix_events.py

This class has a bunch of tests for pause_reading() / resume_reading().

Test(s) for is_reading() can be built in the same way.

--

___
Python tracker 

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

[issue20504] cgi.FieldStorage, multipart, missing Content-Length

[Ned Deily]

Change by Ned Deily :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue38314] Implement unix read_pipe.is_reading() method

[Shubham Upreti]

Shubham Upreti  added the comment:

I would like to take this up. I am a beginner and any more instructions you 
want to give me.

--
nosy: +shubh07

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[miss-islington]

miss-islington  added the comment:


New changeset 19cd5951ec4480c7cfcbcc379b36902312cfb8b8 by Miss Islington (bot) 
in branch '3.8':
bpo-38019: correctly handle pause/resume reading of closed asyncio unix pipe 
(GH-16472)
https://github.com/python/cpython/commit/19cd5951ec4480c7cfcbcc379b36902312cfb8b8


--

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[miss-islington]

miss-islington  added the comment:


New changeset 1c3e4691bb41fa070d6f4836cb03005123e53e4b by Miss Islington (bot) 
in branch '3.7':
bpo-38019: correctly handle pause/resume reading of closed asyncio unix pipe 
(GH-16472)
https://github.com/python/cpython/commit/1c3e4691bb41fa070d6f4836cb03005123e53e4b


--
nosy: +miss-islington

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 58498bc7178608b1ab031994ca09c43889ce3e76 by Andrew Svetlov in 
branch 'master':
bpo-38019: correctly handle pause/resume reading of closed asyncio unix pipe 
(GH-16472)
https://github.com/python/cpython/commit/58498bc7178608b1ab031994ca09c43889ce3e76


--

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[miss-islington]

Change by miss-islington :


--
pull_requests: +16058
pull_request: https://github.com/python/cpython/pull/16474

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[miss-islington]

Change by miss-islington :


--
pull_requests: +16057
pull_request: https://github.com/python/cpython/pull/16473

___
Python tracker 

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

[issue38308] Add optional weighting to statistics.harmonic_mean()

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue38314] Implement unix read_pipe.is_reading() method

[Andrew Svetlov]

Andrew Svetlov  added the comment:

The issue is easy, basically we need the following code plus a test

def is_reading(self):
return not self._paused and not self._closing

--
keywords: +newcomer friendly
type:  -> enhancement

___
Python tracker 

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

[issue38314] Implement unix read_pipe.is_reading() method

[Andrew Svetlov]

New submission from Andrew Svetlov :

Sockets support it, there is no reason for missing the method in unix pipe.

--
components: asyncio
messages: 353494
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement unix read_pipe.is_reading() method
versions: Python 3.9

___
Python tracker 

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

[issue38019] asyncio subprocess AttributeError: 'NoneType' object has no attribute '_add_reader' / '_remove_reader'

[Andrew Svetlov]

Change by Andrew Svetlov :


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

___
Python tracker 

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

[issue38164] polishing asyncio Streams API

[Kyle Stanley]

Kyle Stanley  added the comment:

This should no longer be a release blocker for 3.8 with the reversion of the 
new asyncio streaming API in GH-16455.

--
nosy: +aeros167

___
Python tracker 

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

[issue20504] cgi.FieldStorage, multipart, missing Content-Length

[Pierre Quentel]

Pierre Quentel  added the comment:

Now that the PR has been merged, can someone close the issue ?

--

___
Python tracker 

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

[issue38306] High level API for loop.run_in_executor(None, ...)?

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'd like to see how thread pools integrate with (not existing yet bug planned 
for 3.9) task groups before pushing forward the proposed approach.

--

___
Python tracker 

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

[issue38304] PEP 587 implementation is not ABI forward compatible

[Ned Deily]

Ned Deily  added the comment:

Nick, do you consider this a 3.8.0 release blocker?  If so, you should reopen 
it and mark it as such, since the 3.8.0rc1 cutoff is imminent.

--
nosy: +ned.deily

___
Python tracker 

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

[issue24464] "sqlite3_enable_shared_cache" deprecation warning when compiling with macOS system SQLite3

[Ned Deily]

Ned Deily  added the comment:

Also, I notice that, while there is docstring help for 
sqlite3.enable_shared_cache, it does not seem to be mentioned in the sqlite3 
module doc page in the Library reference.

--

___
Python tracker 

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

[issue24464] "sqlite3_enable_shared_cache" deprecation warning when compiling with macOS system SQLite3

[Ned Deily]

Ned Deily  added the comment:

Now that this has come up again, it's worth noting Ronald's comment in 
msg295954 from duplicate Issue30646:

"See also . Apple basically 
disabled this function starting at macOS 10.7, that's why there's a warning.

It is possible to suppress the warning, but I don't think its worth the trouble.

BTW. The python documentation for this function claims this changes a 
thread-local setting, but the SQLite documentation says this is a process 
global setting in SQLite 3.5.0 and later (released in 2007).  It is possible to 
make behaviour match the python documentation by making 
_sqlite3.enable_shared_cache store a flag that's used in the call to 
sqlite3_open_v2. That would be a backward compatibility concern (there's bound 
to be users that rely on the current behavior), but would also avoid this 
warning."

--
components: +Build
title: Got warning when compiling sqlite3 module on Mac OS X -> 
"sqlite3_enable_shared_cache" deprecation warning when compiling with macOS 
system SQLite3
versions: +Python 3.9 -Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue38304] PEP 587 implementation is not ABI forward compatible

[Nick Coghlan]

Nick Coghlan  added the comment:

The hidden _config_version field wasn't in the accepted PEP.

Both it and struct_size should be removed, as we don't support updating an 
embedded Python runtime to a new X.Y.0 release without rebuilding the embedding 
application.

--
nosy: +ncoghlan

___
Python tracker 

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

[issue30646] SQLite: sqlite3_enable_shared_cache() is deprecated

[Ned Deily]

Change by Ned Deily :


--
resolution: third party -> duplicate
superseder:  -> Got warning when compiling sqlite3 module on Mac OS X

___
Python tracker 

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

[issue24464] Got warning when compiling sqlite3 module on Mac OS X

[David CARLIER]

Change by David CARLIER :


--
pull_requests: +16055
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16469

___
Python tracker 

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

[issue38311] Building with macoS system SQLite3 generates sqlite3_enable_shared_cache deprecation warning

[Ned Deily]

Ned Deily  added the comment:

Sorry, I should have checked: this issue has come up at least a couple of times 
before, for example, Issue30646 and Issue24464 (still open with a slightly more 
compex patch). Let's just close this issue as a duplicate of the earlier one 
and continue any new discussion there.

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Got warning when compiling sqlite3 module on Mac OS X

___
Python tracker 

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

[issue38311] Building with macoS system SQLite3 generates sqlite3_enable_shared_cache deprecation warning

[Ned Deily]

New submission from Ned Deily :

Thanks for the PR!  As noted in my review comment of it, I believe a more 
robust approach would be needed to ensure that builds still work properly when 
building with a local copy of SQLite on macOS (not the system-supplied one), a 
common occurrence.

--
components: +macOS
nosy: +ned.deily, ronaldoussoren
stage:  -> patch review
title: macOS sqlite 3 module build fix -> Building with macoS system SQLite3 
generates sqlite3_enable_shared_cache deprecation warning

___
Python tracker 

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