[issue40624] add support for != (not-equals) in ElementTree XPath

2020-11-08 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue40624] add support for != (not-equals) in ElementTree XPath

2020-11-08 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 97e8b1eaeaf3aa325c84ff2e13417c30414d0269 by Ammar Askar in branch 
'master':
bpo-40624: Add support for the XPath != operator in xml.etree (GH-22147)
https://github.com/python/cpython/commit/97e8b1eaeaf3aa325c84ff2e13417c30414d0269


--

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



[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values

2020-10-28 Thread Stefan Behnel


Stefan Behnel  added the comment:

In general, since the C accelerator is enabled by default, and few people would 
consider disabling it explicitly, I generally consider the behaviour of the C 
implementation to be "right", if both implementations differ.

As a single data point, the reason why the difference was found in this case 
was differing behaviour in PyPy (which uses only the Python implementation). It 
was only later found to be a problem on the CPython side.

Changing the behaviour of the C implementation would certainly break a lot more 
code than changing the Python implementation.

--

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



[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values

2020-10-26 Thread Stefan Behnel


Stefan Behnel  added the comment:

The patch looks right. I'm not sure if this can still be changed in Py3.8, 
though, since that has been around for quite a while now.

Admittedly, few people will disable the C accelerator module and thus whitness 
this issue, but for them, this is a breaking change, and some code might rely 
on the current behaviour. I have no way to tell how much, and whether it 
intentionally relies on it.

I'd definitely change this for 3.9 and later. Maybe for 3.8, but it's at least 
a bit of a risk, given that there will only be very few more minor releases for 
it, and given that this is how things have been working for years. So, rather 
not, unless there is a convincing argument for backporting the change.

--
components: +XML -Library (Lib)
versions:  -Python 3.6, Python 3.7, Python 3.8

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-10-11 Thread Stefan Behnel


Stefan Behnel  added the comment:

> Don't forget to remove PyGen_Send()

That's the function that allows sending data into a generator. It's also used 
internally by "PyIter_Send()". Are you really suggesting to remove it, or to 
make it underscore-private again? (As it was before.)

--

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-10-04 Thread Stefan Behnel


Stefan Behnel  added the comment:

Closing since this works as designed.

Users are responsible for avoiding concurrent tree modifications during 
iteration.

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

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-10-04 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests: +21547
pull_request: https://github.com/python/cpython/pull/22546

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



[issue33802] Regression in logging configuration

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy:  -scoder

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



[issue6721] Locks in the standard library should be sanitized on fork

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy:  -scoder

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



[issue33802] Regression in logging configuration

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests:  -21521

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



[issue36533] logging regression with threading + fork are mixed in 3.7.1rc2 (deadlock potential)

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy:  -scoder

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



[issue6721] Locks in the standard library should be sanitized on fork

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests:  -21519

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



[issue36533] logging regression with threading + fork are mixed in 3.7.1rc2 (deadlock potential)

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests:  -21520

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



[issue33802] Regression in logging configuration

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy: +scoder
nosy_count: 9.0 -> 10.0
pull_requests: +21521
pull_request: https://github.com/python/cpython/pull/22474

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



[issue36533] logging regression with threading + fork are mixed in 3.7.1rc2 (deadlock potential)

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy: +scoder
nosy_count: 9.0 -> 10.0
pull_requests: +21520
pull_request: https://github.com/python/cpython/pull/22474

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



[issue6721] Locks in the standard library should be sanitized on fork

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


--
nosy: +scoder
nosy_count: 29.0 -> 30.0
pull_requests: +21519
pull_request: https://github.com/python/cpython/pull/22474

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-03 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-03 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset a0f2b664335eb689abdecc677e09a193f503af59 by Miss Skeleton (bot) 
in branch '3.9':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a 
default namespace was defined. (GH-22474) (GH-22507)
https://github.com/python/cpython/commit/a0f2b664335eb689abdecc677e09a193f503af59


--

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-03 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset cfed5343331350c5737b464970a31f7588319e8b by Miss Skeleton (bot) 
in branch '3.8':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a 
default namespace was defined. (GH-22474) (GH-22508)
https://github.com/python/cpython/commit/cfed5343331350c5737b464970a31f7588319e8b


--

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-03 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 6a412c94b6b68e7e3632562dc7358a12ffd1447f by scoder in branch 
'master':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a 
default namespace was defined. (GH-22474)
https://github.com/python/cpython/commit/6a412c94b6b68e7e3632562dc7358a12ffd1447f


--

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-10-02 Thread Stefan Behnel


Change by Stefan Behnel :


--
versions: +Python 3.10, Python 3.9

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-01 Thread Stefan Behnel


Change by Stefan Behnel :


--
keywords: +patch
pull_requests: +21493
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22474

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



[issue41900] XML C14N serialisation fails with default namespace

2020-10-01 Thread Stefan Behnel


New submission from Stefan Behnel :

import xml.etree.ElementTree as ET
xml="""
http://soap.sforce.com/2006/04/metadata;>

"""
print(ET.canonicalize(xml))

Fails with:
ValueError: Namespace "" is not declared in scope
when trying to build the QName of the unnamespaced "targets" attribute.

Originally reported for lxml here:
https://bugs.launchpad.net/lxml/+bug/1869455

--
components: XML
messages: 377743
nosy: scoder
priority: normal
severity: normal
stage: needs patch
status: open
title: XML C14N serialisation fails with default namespace
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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



[issue31256] xml.etree.ElementTree: add support for doctype in tostring method

2020-10-01 Thread Stefan Behnel


Stefan Behnel  added the comment:

Yes, it fixed already. Thanks!

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

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



[issue41899] Poor example for Element.remove()

2020-10-01 Thread Stefan Behnel


Stefan Behnel  added the comment:

Closing as duplicate of issue 41891. Let's keep the discussion there.

--
nosy: +scoder
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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



[issue41899] Poor example for Element.remove()

2020-10-01 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue41899] Poor example for Element.remove()

2020-10-01 Thread Stefan Behnel


Stefan Behnel  added the comment:

Closing as duplicate of issue 41892. Let's keep the discussion there.

--

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-09-30 Thread Stefan Behnel


Stefan Behnel  added the comment:

@WoodyWoo, you can (and should) do something like this:

for ELEMchild in list(etroot):

Modifying a container while iterating over it is usually not a good idea. The 
same applies to Python lists and dicts, for example.

--
stage: patch review -> 

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-09-30 Thread Stefan Behnel


Change by Stefan Behnel :


--
stage:  -> patch review

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-09-30 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue41892] use both "for in" and "ElementTree.remove" has a index bug

2020-09-30 Thread Stefan Behnel


Stefan Behnel  added the comment:

> That example is especially problematic.

No, it's not. It uses .findall(), which returns a list. It's like when you make 
a copy of a list to iterate over, when you want to modify the original list in 
the loop.

That could be made explicit in the text that introduces the example, but I 
think it's a very good example.

--

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



[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

2020-09-29 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue38225] iscoroutinefunction broken with cython - allow tagging of functions as async?

2020-09-22 Thread Stefan Behnel


Stefan Behnel  added the comment:

FYI, https://github.com/cython/cython/pull/3427 has been merged into Cython. In 
Cython 3.0, compiled coroutines will disguise as non-compiled coroutines, from 
the PoV of asyncio.

Restricting this ticket to Py3.10 since we're rather discussing a new feature 
now.

--
versions: +Python 3.10 -Python 3.7, Python 3.8, Python 3.9

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-09-20 Thread Stefan Behnel


Stefan Behnel  added the comment:

Closing again since GH-21528 has been merged in issue 41295.

--
status: open -> closed

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

BTW, just to give this a house number, I remember having measured a performance 
improvement of up to 70% at some point when switching from "generators always 
raise a StopIteration at the end" to "generators just return NULL" in Cython. 
For short-running generators and coroutines, this can make a big difference.

--

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-09-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

I would also have preferred a more type specific function, but yeah, as long as 
the types for which the function would normally be used are special cased early 
enough in the implementation, it makes no big difference.

Fine with me, too.

--

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-09-16 Thread Stefan Behnel


Stefan Behnel  added the comment:

I'm happy to see this moving forward.

Not convinved of the "PyIter_Send()" name, though. I don't consider this part 
of the iterator protocol. It's specific to generators and coroutines. Cython 
would probably guard its usage by "PyGen_CheckExact()" or 
"PyCoro_CheckExact()", and not use it for arbitrary iterators.

Since coroutines inherit the generator protocol more or less, I think 
"PyGen_Send()" is a more suitable name, better than "PyCoro_Send()".

--

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-09-11 Thread Stefan Behnel


Stefan Behnel  added the comment:

Copying some of the design discussion from the PR here 
(https://github.com/python/cpython/pull/22196/files#r486730457), because it 
belongs into the ticket.

Yury Selivanov proposed to add a new C-API function for this (naming changes by 
me):

typedef enum {PYGEN_RETURN, PYGEN_ERROR, PYGEN_NEXT} PyGenSendStatus;

PyGenSendStatus PyGen_Send(PyGenObject *gen, PyObject *arg, PyObject 
**result);

Mark Shannon and I agreed that the status code should be the return value, with 
some confusion whether "PyGen_" or "PyCoro_" would be appropriate prefixes.

Mark Shannon wrote: I don't think [the C-API function] should be public, as a 
possible further improvement is to stop passing exceptions through a side 
channel, but in result. Maybe we don't want to do that, but lets' not add to 
the (already rather large) C-API.

However, I think this will be demanded and used by extensions, including Cython 
implemented ones, so it seems better to make them use a public function than a 
private one.

Let's continue these lines of discussion here.

--

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



[issue41756] Do not always use exceptions to return result from coroutine

2020-09-11 Thread Stefan Behnel


Stefan Behnel  added the comment:

Big +1 from me, too, for the same reasons Yury gave.

--
nosy: +scoder

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



[issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting

2020-09-07 Thread Stefan Behnel


Change by Stefan Behnel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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



[issue19483] Allow more low-level parser configuration in ElementTree

2020-09-07 Thread Stefan Behnel


Stefan Behnel  added the comment:

Changing subject to make it clear what this ticket is really about.

--
title: Pure-Python ElementTree classes no longer available since 3.3 -> Allow 
more low-level parser configuration in ElementTree
versions: +Python 3.10 -Python 3.3, Python 3.4, Python 3.5

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



[issue39714] ElementTree parser limitation of input string size

2020-09-07 Thread Stefan Behnel


Change by Stefan Behnel :


--
title: ElementTree limitation -> ElementTree parser limitation of input string 
size

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



[issue39714] ElementTree limitation

2020-09-07 Thread Stefan Behnel


Stefan Behnel  added the comment:

I'd suggest feeding the data into the parser in chunks, or letting it read from 
a file-like object, or something like that.

Also, you probably want to do incremental processing on the data (see the 
XMLPullParser and iterparse), because reading 3.5GB of XML data into an 
in-memory tree can easily result in 10x the memory usage. You may have 40GB of 
RAM on your machine, but even then, I'd still recommend processing the data in 
incrementally.

--
nosy: +scoder
versions: +Python 3.10, Python 3.9 -Python 3.7

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



[issue40624] add support for != (not-equals) in ElementTree XPath

2020-09-07 Thread Stefan Behnel


Stefan Behnel  added the comment:

Agreed that adding "!=" would be a nice improvement, probably not very 
invasive. PR welcome.

https://www.w3.org/TR/xpath-10/#booleans

--
nosy: +scoder
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.10 -Python 3.9

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



[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)

2020-08-20 Thread Stefan Behnel


Stefan Behnel  added the comment:

> On the whole I think the arguments to make a module are very strong. So I 
> think that is the appropriate way forward.

If you take this route, please don't write it directly against the CPython 
C-API (as you would for a CPython stdlib module). It is much easier to get 
something working, correct, testable and feature-rich with Cython. Once you 
have that, put it on PyPI to give it more testing. If you then decide to come 
back and provide a patch to get it integrated into CPython's zlib module, it's 
relatively easy to manually translate the Cython code to equivalent C-API code. 
But by that time, your code will be known to work, will have a test suite, and 
we can run real benchmarks on it before investing the time into spelling it out 
in C.

--

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



[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)

2020-08-17 Thread Stefan Behnel


Stefan Behnel  added the comment:

> libdeflate and isa-l use different compression ratio's for the levels.

I don't see why these would need to translate 1:1. The zlib module is a Python 
API wrapper, it can do its own mapping here, or use the libraries selectively 
only for some compression levels. Python code also cannot rely on an exact bit 
pattern coming out of the zlib/gzip compressor, since that might change with 
the zlib version that is available. So I think we're fine when replacing the 
underlying implementation, as long as the API does not change and the output is 
strictly zlib/gzip compatible (and there are no visible performance/size 
regressions, as your numbers seem to suggest, but that would need some broader 
testing).


You also wrote on python-ideas that

> It is packaged in linux distros already

That might be an option then. CPython could use the existing library if it is 
available. It doesn't have to ship the sources. Most Linux distributions 
already build some standard library modules against the system-wide installed 
libraries rather than whatever CPython ships in its sources. And those 
distributions could then make the library a fixed dependency of their CPython 
packages.

--

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



[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)

2020-08-17 Thread Stefan Behnel


Stefan Behnel  added the comment:

What about building the library? The readme says it needs nasm? That's not a 
standard dependency for the CPython build currently, which relies solely on a C 
compiler.

--

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



[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)

2020-08-17 Thread Stefan Behnel


Stefan Behnel  added the comment:

> This has to be in a PEP

No, the bug tracker seems fine for this.

--
nosy: +scoder
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> performance

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



[issue35018] Sax parser provides no user access to lexical handlers

2020-08-09 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue35018] Sax parser provides no user access to lexical handlers

2020-08-09 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset e28b8c93878072dc02b116108ef5443084290d47 by Zackery Spytz in 
branch 'master':
bpo-35018: Sax parser should provide user access to lexical handlers (GH-20958)
https://github.com/python/cpython/commit/e28b8c93878072dc02b116108ef5443084290d47


--

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



[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

2020-07-19 Thread Stefan Behnel


Stefan Behnel  added the comment:

> test_asyncio altered the execution environment

That happened several times before in previous builds. I think there's just a 
part of the asyncio tests that is unreliable. I left a comment in issue 41273 
since it might be related, the sporadic failures started appearing in the build 
following the merge.

--

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



[issue41273] asyncio: proactor read transport: use recv_into instead of recv

2020-07-19 Thread Stefan Behnel


Stefan Behnel  added the comment:

There have been sporadic buildbot failures in "test_asyncio" since this change, 
message being "1 test altered the execution environment", e.g.

https://buildbot.python.org/all/#/builders/129/builds/1443

Could someone please check if they are related?

--
nosy: +scoder

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



[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

2020-07-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

PR 21528 works for all four test cases that we now have (1x test_capi.py, 3x 
test_descr.py).

Any comments? We need to merge a fix before Monday to meet the deadline of the 
planned hotfix release.

@kam193, could you please also test that change with your real code?

--

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

I pushed PR 21528 with a new proposal. See issue 41295.

--

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



[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses

2020-07-18 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests: +20664
pull_request: https://github.com/python/cpython/pull/21528

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

> intermediate base type "object" in the hierarchy

Sorry, I meant an intermediate base type "B", which inherits its setattr from 
"object".

--

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

The problem in the test added in PR 21473 is that there is an intermediate base 
type "object" in the hierarchy:

class A(type):
def __setattr__(cls, key, value):
type.__setattr__(cls, key, value)

class B:
pass

class C(B, A):
pass

>>> [c for c in C.__mro__]
[, , , , ]

>>> [c.__setattr__ for c in C.__mro__]
[, , , , ]

I think the change to the algorithm there is too broad, it disables much of 
what the check was written for (or against).

Given Guido's second (negative) test case, I think it would also not be correct 
to add "object.__setattr__" to the list of allowed (intermediate) slot methods:

class A(type):
def __setattr__(cls, key, value):
object.__setattr__(cls, key, value)   # this should fail!

class B:
pass

class C(B, A):
pass

It's difficult to turn this into an algorithm. Is the MRO really the place to 
look? For "A", we're only really interested in the C-level bases, aren't we?

--

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-05 Thread Stefan Behnel


Stefan Behnel  added the comment:

Fixed in 3.8+. Closing.
Thanks for the feedback.

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

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-05 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 8912c182455de83e27d5c120639ec91b18247913 by scoder in branch 
'3.8':
bpo-39960: Allow heap types in the "Carlo Verre" hack check that override 
"tp_setattro()" (GH-21092) (GH-21339)
https://github.com/python/cpython/commit/8912c182455de83e27d5c120639ec91b18247913


--

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-05 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests: +20487
pull_request: https://github.com/python/cpython/pull/21339

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-02 Thread Stefan Behnel


Stefan Behnel  added the comment:

I think we missed the train for fixing 3.7 (which was questionable anyway), but 
I added a test, so it's ready for merging into 3.8+ (minus merge conflicts for 
the test in 3.8, probably).

--

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-07-02 Thread Stefan Behnel


Change by Stefan Behnel :


--
versions:  -Python 3.7

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-06-23 Thread Stefan Behnel


Change by Stefan Behnel :


--
stage:  -> patch review

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-06-23 Thread Stefan Behnel


Stefan Behnel  added the comment:

I chose to go through the MRO, which takes multiple inheritance into account.

--
stage: patch review -> 

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-06-23 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue41078] [C API] Convert PyTuple_GET_ITEM() macro to a static inline function

2020-06-22 Thread Stefan Behnel

Stefan Behnel  added the comment:

> Also, later, these structures may change to be more efficient.

Tuples? Really?

Ok, quoting PEP-620:
> Members of … PyTupleObject structures have not changed since the "Initial 
> revision" commit (1990)

I honestly think the reason for that might simply be that there's not so much 
to improve for tuples.

> nothing prevents a C extension to get or set directly
> PyTupleObject.ob_item[0] (the first item of a tuple).

I certainly understand that that is a problem, especially if "PyObject" may 
change in the future. And this is essentially what the current 
"PyTuple_GET_ITEM()" macro does in a binary module.

Should we also turn "_PyTuple_ITEMS()" into a public inline function then to 
make up for the loss of the "_GET_ITEM(t, 0)" pattern? It would make it 
explicit what is intended. I think that should be our main goal in the CPython 
side.

--

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



[issue41078] [C API] Convert PyTuple_GET_ITEM() macro to a static inline function

2020-06-22 Thread Stefan Behnel

Stefan Behnel  added the comment:

> Giving a direct access to an array or PyObject* (PyObject**) is causing 
> issues with other Python implementations, like PyPy, which don't use PyObject 
> internally.

I'm wondering – if the intention is to help other implementations, then why do 
we need to break extensions in *CPython* for that? In CPython, this usage seems 
perfectly valid with the current data structure. If that ever changes, we can 
still make this change as well, but do you really see the internal layout of 
tuples change at some point? (Lists are a different case, I'd say, but tuples?)

--
nosy: +scoder

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-06-21 Thread Stefan Behnel


Stefan Behnel  added the comment:

This SO answer by Martijn Pieters explains the background:

https://stackoverflow.com/a/44854477

and links to the original python-dev discussion:

https://mail.python.org/pipermail/python-dev/2003-April/034535.html

The current implementation checks that the function being called is the one 
defined in the first non-heap type up the hierarchy. As long as heap types are 
only Python types, this is the first builtin/native/C-implemented (super)type. 
With extension types as heap types, however, it's no longer necessarily the 
type that defines the correct slot function.

IMHO, Greg Ewing gives the right direction here:

https://mail.python.org/pipermail/python-dev/2003-April/034569.html

> Providing some way for objects to prevent superclass
> methods from being called on them when they're not looking

So, I think we should do something like walking up the hierarchy to find the C 
function in it that is currently being called, and then check if it's the one 
we would expect or if a subclass defines a different one. The current check 
does not bother to search and just assumes that it knows which (super)type 
defines the right function to call.

--

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2020-06-21 Thread Stefan Behnel


Stefan Behnel  added the comment:

Feel free to use the patch in any way you like.

--

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2020-06-21 Thread Stefan Behnel


Stefan Behnel  added the comment:

PRs look good to me. Here is a test that fails for me with the master branch 
and works with your fixes. It has a slightly odd place in the subinterpreter 
tests, but I would argue that it's not entirely misplaced there. You would want 
to know when subinterpreters start rejecting valid code, wouldn't you? :)


diff --git a/Lib/test/test_capi.py b/Lib/test/test_capi.py
index 73e167a0b0..9bed8255e1 100644
--- a/Lib/test/test_capi.py
+++ b/Lib/test/test_capi.py
@@ -627,6 +627,24 @@ class SubinterpreterTest(unittest.TestCase):
 self.assertNotEqual(pickle.load(f), id(sys.modules))
 self.assertNotEqual(pickle.load(f), id(builtins))
 
+def test_subinterps_recent_language_features(self):
+r, w = os.pipe()
+code = """if 1:
+import pickle
+with open({:d}, "wb") as f:
+
+@(lambda x:x)  # Py 3.9
+def noop(x): return x
+
+a = (b := f'1{{2}}3') + noop('x')  # Py3.8 (:=) / 3.6 (f'')
+pickle.dump(dict(a=a, b=b), f)
+""".format(w)
+
+with open(r, "rb") as f:
+ret = support.run_in_subinterp(code)
+self.assertEqual(ret, 0)
+self.assertEqual(pickle.load(f), {'a': '123x', 'b': '123'})
+
 def test_mutate_exception(self):
 """
 Exceptions saved in global module state get shared between
diff --git a/Modules/_testcapimodule.c b/Modules/_testcapimodule.c
index 808483ebd7..468e25ff9e 100644
--- a/Modules/_testcapimodule.c
+++ b/Modules/_testcapimodule.c
@@ -3468,6 +3468,8 @@ run_in_subinterp(PyObject *self, PyObject *args)
 const char *code;
 int r;
 PyThreadState *substate, *mainstate;
+/* only initialise 'cflags.cf_flags' to test backwards compatibility */
+PyCompilerFlags cflags = {0};
 
 if (!PyArg_ParseTuple(args, "s:run_in_subinterp",
   ))
@@ -3486,7 +3488,7 @@ run_in_subinterp(PyObject *self, PyObject *args)
 PyErr_SetString(PyExc_RuntimeError, "sub-interpreter creation failed");
 return NULL;
 }
-r = PyRun_SimpleString(code);
+r = PyRun_SimpleStringFlags(code, );
 Py_EndInterpreter(substate);
 
 PyThreadState_Swap(mainstate);

--

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2020-06-20 Thread Stefan Behnel

Stefan Behnel  added the comment:

I wasn't sure which is better – solve it or leave it. But it seems a) easy to 
adapt to on user side, and b) solvable in CPython in a way that allows code 
that wants to adapt to work across 3.8.x versions. Only code that does not get 
adapted would risk failure in existing 3.8.x versions, and benefit from a fix 
in future 3.8.x releases.

So, yeah, I think we should fix it then.

--
status: open -> closed

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2020-06-20 Thread Stefan Behnel


Stefan Behnel  added the comment:

I was made aware [1] that the addition of the "cf_feature_version" field broke 
the backwards compatibility of the "PyRun_StringFlags()" function [2]. Unlike 
what the docs of "PyCompilerFlags" [3] suggest, the new field is not ignored 
there but must now be set in order to enable the syntax features of the running 
Python version.

Background: A Cython user was trying "exec()" on code with f-strings in Py3.8 
and got a SyntaxError, because "cf_feature_version" had not been initialised.

I can see two types of existing code being affected:

1) applications or modules that execute user provided Python code (as in the 
bug report) for which users expect the syntax of the currently running Python 
runtime to be available.

2) code that used to work in Py3.6/7 using the available Python syntax features 
and now runs into newly introduced syntax restrictions in Py3.8, such as 
f-strings no longer being available.

Since Py3.8 has been out for a while with this change, and there were 
apparently little complaints in addition to issue 37072, should we just update 
the documentation of "PyCompilerFlags" and "PyRun_StringFlags()" to mention the 
change there?

[1] https://github.com/cython/cython/issues/3695
[2] https://docs.python.org/3/c-api/veryhigh.html#c.PyRun_StringFlags
[3] https://docs.python.org/3/c-api/veryhigh.html#c.PyCompilerFlags

--
nosy: +scoder

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



[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

2020-06-20 Thread Stefan Behnel


Stefan Behnel  added the comment:

I ran into this, too. I agree that the "hackcheck" loop on heap types is 
probably wrong.

https://github.com/python/cpython/blob/04fc4f2a46b2fd083639deb872c3a3037fdb47d6/Objects/typeobject.c#L5947-L5977

It was written at a time (Py2.3?) when (practically) only Python implemented 
types were heap types, not extension types. I think what it tried to do was to 
find the builtin base type of a Python type, and check that no-one played 
tricks on the C slot functions of that C implemented type. With extension types 
implemented as heap types, having a different slot function in there is a 
perfectly valid thing.

I'll call in a couple of people since I'm also not sure how to fix the 
"hackcheck".

I'll also leave Py3.7 in the list of affected Python versions since we still 
have a short week before its final non-secfix-release. :)

--
nosy: +gvanrossum, petr.viktorin, scoder
type:  -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9

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



[issue40704] PyIter_Check fails when compiling in the Limited API

2020-06-19 Thread Stefan Behnel


Stefan Behnel  added the comment:

You can see it from the tags on the commit, it was fixed in Py3.8.

Duplicate of issue 33738.

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.6, Python 3.7

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



[issue40704] PyIter_Check fails when compiling in the Limited API

2020-06-19 Thread Stefan Behnel


Stefan Behnel  added the comment:

It should be replaced with an actual function, which can be inline in the 
non-limited case.

--
nosy: +scoder
stage:  -> needs patch
type:  -> compile error
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7

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



[issue40989] [C API] Remove _Py_NewReference() and _Py_ForgetReference() from the public C API

2020-06-17 Thread Stefan Behnel


Stefan Behnel  added the comment:

I looked into the freelists a bit more and (as always) it's not quite that 
simple. Calling _Py_NewReference() allows keeping the "ob_type" pointer in 
place, whereas PyObject_INIT() requires a blank object in order to set the type 
and properly ref-count heap types.

I think what that means is that there are at least two different cases for 
freelists: those that only keep the bare object memory alive (and can also 
support subtypes of the same size), and those that keep the (cleared) object 
alive, including its type. For the first, PyObject_INIT() works. For the 
latter, _Py_NewReference() seems the right helper function.

The advantage of keeping the object as it is is the much simpler freelist code 
in tp_dealloc(). All it needs to do is 1) clear the ref-counted object fields 
(if any) and 2) put it in the freelist. No other C-API interaction is needed. 
If we only want to keep the object memory, then we need C-API support in both 
tp_new() and tp_dealloc().

If _Py_NewReference() is removed/hidden, then it would be nice if there was a 
replacement for the use case of initialising an object from a freelist that 
already knows its type.

--

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



[issue40989] [C API] Remove _Py_NewReference() and _Py_ForgetReference() from the public C API

2020-06-17 Thread Stefan Behnel


Stefan Behnel  added the comment:

To add to the list, Cython also calls _Py_NewReference() in its async generator 
code, which uses a free-list. That code was mostly copied from the 
CPython-internal implementation.

Other freelist implementations in Cython call PyObject_INIT() instead, so I 
guess calling _Py_NewReference() directly here isn't actually required and 
could be avoided.

--
nosy: +scoder

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



[issue40703] PyType_FromSpec*() overwrites the type's "__module__"

2020-06-10 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 9419158a3e67ba2eadf33215568003ed723b0a98 by Miss Islington (bot) 
in branch '3.9':
bpo-40703: Let PyType_FromSpec() set "type.__module__" only if it is not set 
yet. (GH-20273) (GH-20782)
https://github.com/python/cpython/commit/9419158a3e67ba2eadf33215568003ed723b0a98


--

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



[issue40703] PyType_FromSpec*() overwrites the type's "__module__"

2020-06-10 Thread Stefan Behnel


Change by Stefan Behnel :


--
stage: patch review -> test needed

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



[issue40703] PyType_FromSpec*() overwrites the type's "__module__"

2020-06-10 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 24b8bad6d30ae4fb37ee686a073adfa5308659f9 by scoder in branch 
'master':
bpo-40703: Let PyType_FromSpec() set "type.__module__" only if it is not set 
yet. (GH-20273)
https://github.com/python/cpython/commit/24b8bad6d30ae4fb37ee686a073adfa5308659f9


--

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



[issue36543] Remove old-deprecated ElementTree features (part 2)

2020-06-10 Thread Stefan Behnel


Stefan Behnel  added the comment:

The xml.etree.cElementTree module is restored. We'll see about what to do with 
it later. It hurts less to keep it around than to delete it.

I think this ticket can be closed.

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

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



[issue36543] Remove old-deprecated ElementTree features (part 2)

2020-06-10 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 3b97d1becbe08cf56c58d9c740a4622cbf6285fd by Miss Islington (bot) 
in branch '3.9':
bpo-36543: Revert "bpo-36543: Remove the xml.etree.cElementTree module." 
(GH-20117) (GH-20780)
https://github.com/python/cpython/commit/3b97d1becbe08cf56c58d9c740a4622cbf6285fd


--

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



[issue36543] Remove old-deprecated ElementTree features (part 2)

2020-06-10 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset ec88e1bca81a167e6d5c0ac635e22f84298cb1df by Serhiy Storchaka in 
branch 'master':
bpo-36543: Revert "bpo-36543: Remove the xml.etree.cElementTree module." 
(GH-20117)
https://github.com/python/cpython/commit/ec88e1bca81a167e6d5c0ac635e22f84298cb1df


--

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



[issue20928] xml.etree.ElementInclude does not include nested xincludes

2020-06-08 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 301f0d4ff9b6bd60599eea0612904f65a92e6dd9 by Shantanu in branch 
'master':
bpo-33187: Document 3.9 changes to xml.etree.ElementInclude.include (GH-20438)
https://github.com/python/cpython/commit/301f0d4ff9b6bd60599eea0612904f65a92e6dd9


--

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



[issue33187] Document ElementInclude (XInclude) support in ElementTree

2020-06-08 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 301f0d4ff9b6bd60599eea0612904f65a92e6dd9 by Shantanu in branch 
'master':
bpo-33187: Document 3.9 changes to xml.etree.ElementInclude.include (GH-20438)
https://github.com/python/cpython/commit/301f0d4ff9b6bd60599eea0612904f65a92e6dd9


--

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



[issue40724] Support buffer protocol with type specs

2020-06-07 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue40724] Support buffer protocol with type specs

2020-06-07 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 1d711f2e31e02b2e9cbe4f109bf79541f56c35a2 by Miss Islington (bot) 
in branch '3.9':
bpo-40724: Fix return type of test helper function 
heapctypewithbuffer_releasebuffer() (GH-20685) (GH-20690)
https://github.com/python/cpython/commit/1d711f2e31e02b2e9cbe4f109bf79541f56c35a2


--

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



[issue40724] Support buffer protocol with type specs

2020-06-07 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 1e4fa91104a03c44baa241326102cbec42d387f1 by Miss Islington (bot) 
in branch '3.9':
bpo-40724: Support setting buffer slots from type specs (GH-20648) (GH-20683)
https://github.com/python/cpython/commit/1e4fa91104a03c44baa241326102cbec42d387f1


--

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



[issue40724] Support buffer protocol with type specs

2020-06-06 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset f7c4e236429606e1c982cacf24e10fc86ef4462f by scoder in branch 
'master':
bpo-40724: Support setting buffer slots from type specs (GH-20648)
https://github.com/python/cpython/commit/f7c4e236429606e1c982cacf24e10fc86ef4462f


--

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



[issue40724] Support buffer protocol with type specs

2020-06-05 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue40724] Support buffer protocol with type specs

2020-05-22 Thread Stefan Behnel


New submission from Stefan Behnel :

As far as I can see it in typeslots.h [1], the buffer protocol is still not 
supported when using type specs:

/* Disabled, see #10181 */
#undef Py_bf_getbuffer
#undef Py_bf_releasebuffer

It seems that the discussion in issue 10181 did not lead anywhere at the time 
(2010-2012).

I'm not talking about the limited API or the stable ABI here, I'm talking about 
using type specs to define an extension type. The work-around is to manually 
set "PyTypeObject->tp_as_buffer" after creating the type, but since 
PyType_Ready() then does not see that struct pointer, you also still have to 
make sure that the type correctly inherits the slots from the base type if 
you're not defining all of them yourself.

Can we just add support for the above slots?

[1] 
https://github.com/python/cpython/blob/ca829102213c466ffecb1e464be5c8cb3967d961/Include/typeslots.h#L2-L4

--
components: C API
messages: 369561
nosy: ncoghlan, paul.moore, petr.viktorin, pitrou, scoder, skrah, vstinner
priority: normal
severity: normal
status: open
title: Support buffer protocol with type specs
type: enhancement
versions: Python 3.10, Python 3.9

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



[issue40703] PyType_FromSpec*() overwrites the type's "__module__"

2020-05-20 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue40703] PyType_FromSpec*() overwrites the type's "__module__"

2020-05-20 Thread Stefan Behnel


New submission from Stefan Behnel :

The PyType_FromSpec() functions set the type's "__module__" attribute at the 
end:

https://github.com/python/cpython/blob/0509c4547fc95cc32a91ac446a26192c3bfdf157/Objects/typeobject.c#L3154-L3172

There are only two possible cases, either it finds a module name in the spec 
name and sets "__module__" from that, or it outputs a deprecation warning. Both 
behaviours are annoying because they ignore anything that the type already has 
in its dict, e.g. a property entry from the "members" or "getset" structs.

Since this code can't really be moved before the call to "PyType_Ready()" 
(which creates the type's dict and populates it), I think the best fix would be 
to first check if "__module__" is already in the dict and only otherwise take 
care of setting it.

I noticed this when trying to make the "__module__" attribute of Cython's 
coroutine type work with type specs, which should actually return the instance 
specific module name, i.e. the module that defines the coroutine, not the 
module that defines the type. This would normally be solved with an entry in 
"members", but that is discarded by the code above. While this approach means 
that the type does not have its own "__module__" entry, I think the use cases 
of pickling and documentation support it, because they care about the module 
name of the instance, not of the type.

I think working around this behaviour is somewhat easy by creating a new 
descriptor with PyDescr_NewMember() and re-adding it after calling 
PyType_FromSpec*(), so this is something that can just be fixed in Py3.9+.

Relevant tickets: issue 15146 for setting "__module__" and issue 20204 for the 
deprecation warning.

--
components: C API
messages: 369476
nosy: ncoghlan, petr.viktorin, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyType_FromSpec*() overwrites the type's "__module__"
type: behavior
versions: Python 3.10, Python 3.9

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



[issue22622] ElementTree only writes declaration when passed encoding

2020-05-18 Thread Stefan Behnel


Stefan Behnel  added the comment:

Right, thanks. Closing since this works in Py3.

--
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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



[issue22079] Ensure in PyType_Ready() that base class of static type is static

2020-05-12 Thread Stefan Behnel


Stefan Behnel  added the comment:

Since it's not clear from this ticket what the original problem was, is there a 
chance it could have been related to issue 35810?

--
nosy: +scoder

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



[issue40575] _PyDict_GetItemIdWithError() should call _PyDict_GetItem_KnownHash()

2020-05-10 Thread Stefan Behnel


Change by Stefan Behnel :


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

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



[issue40575] _PyDict_GetItemIdWithError() should call _PyDict_GetItem_KnownHash()

2020-05-10 Thread Stefan Behnel


Stefan Behnel  added the comment:


New changeset 6067d4bc3ce5ff4cfa5b47ceecc84a3941bc031c by scoder in branch 
'master':
bpo-40575: Avoid unnecessary overhead in _PyDict_GetItemIdWithError() (GH-20018)
https://github.com/python/cpython/commit/6067d4bc3ce5ff4cfa5b47ceecc84a3941bc031c


--

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



[issue38787] PEP 573: Module State Access from C Extension Methods

2020-05-10 Thread Stefan Behnel


Change by Stefan Behnel :


--
pull_requests: +19334
pull_request: https://github.com/python/cpython/pull/20024

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



[issue40575] _PyDict_GetItemIdWithError() should call _PyDict_GetItem_KnownHash()

2020-05-09 Thread Stefan Behnel


Change by Stefan Behnel :


--
keywords: +patch
pull_requests: +19329
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20018

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



[issue40575] _PyDict_GetItemIdWithError() should call _PyDict_GetItem_KnownHash()

2020-05-09 Thread Stefan Behnel


Change by Stefan Behnel :


--
components: +Interpreter Core
keywords: +easy (C)

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



  1   2   3   4   5   6   7   8   9   10   >