[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Mark Shannon]

Mark Shannon  added the comment:

This looks like a duplicate of https://bugs.python.org/issue42951

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

[Mark Dickinson]

Mark Dickinson  added the comment:

@Gautam

> I think it's out of scope for this issue.

Agreed. It was just a note in passing. I don't think it's worth opening a new 
issue, though, unless this is genuinely causing problems for someone. Just let 
it lie.

--

___
Python tracker 

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

[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Irit Katriel]

Irit Katriel  added the comment:

Not sure. Here we do set the recursion limit.

--

___
Python tracker 

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

[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Mark Shannon]

Mark Shannon  added the comment:

A recursion limit of 30 is effectively infinite.
With a debug build of 3.11, the time to execute grows very fast indeed, 
probably super-exponentially.

mark@nero:~/repos/cpython$ time ./python ~/test/test.py 15

real0m1.107s
user0m1.099s
sys 0m0.008s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 16

real0m4.468s
user0m4.464s
sys 0m0.004s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 17

real0m20.968s
user0m20.928s
sys 0m0.040s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 18

real2m29.562s
user2m29.270s
sys 0m0.140s


I would expect ./python ~/test/test.py 30 to take millions of years.

--

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Mark Dickinson]

Change by Mark Dickinson :


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

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Mark Dickinson]

Mark Dickinson  added the comment:

@Pablo: I'm adding you to the nosy list to get your opinion on whether (the 
backport of) GH-27772 can go into 3.10.0.rc2.

Summary: GH-27278 (which I reviewed and approved) and its backports fixed some 
undefined behaviour in complex exponentiation, but also introduced a behaviour 
change that affected NumPy: some exponentiation expressions that returned a 
result in 3.10.0b4 raise an OverflowError in 3.10.0.rc1.

GH-27772 reverts the behaviour change but keeps the fix for the undefined 
behaviour. Can the backport of GH-27772 to the 3.10 branch go in before 3.10.0 
final?

--
nosy: +pablogsal

___
Python tracker 

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

[issue44918] Unhandled Exception (Not Implemented) in HTMLParser().feed

[Mark Deen]

New submission from Mark Deen :

The hexadecimal sequence '3c215b02634717' when passed as an argument to 
HTMLParser()'s feed function results in the exception noted below. The code 
example below illustrates this exception.

from html.parser import HTMLParser

parser = HTMLParser()
parser.feed(bytearray.fromhex('3c215b02634717').decode('ascii'))


Traceback (most recent call last):
  File "poc.py", line 5, in 
parser.feed(bytearray.fromhex('3c215b02634717').decode('ascii'))
  File "/usr/lib/python3.9/html/parser.py", line 110, in feed
self.goahead(0)
  File "/usr/lib/python3.9/html/parser.py", line 178, in goahead
k = self.parse_html_declaration(i)
  File "/usr/lib/python3.9/html/parser.py", line 263, in parse_html_declaration
return self.parse_marked_section(i)
  File "/usr/lib/python3.9/_markupbase.py", line 149, in parse_marked_section
sectName, j = self._scan_name( i+3, i )
  File "/usr/lib/python3.9/_markupbase.py", line 390, in _scan_name
self.error("expected name token at %r"
  File "/usr/lib/python3.9/_markupbase.py", line 33, in error
raise NotImplementedError(
NotImplementedError: subclasses of ParserBase must override error()

--
components: Parser
messages: 399611
nosy: lys.nikolaou, md103, pablogsal
priority: normal
severity: normal
status: open
title: Unhandled Exception (Not Implemented) in HTMLParser().feed
type: security
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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

[Mark Dickinson]

Mark Dickinson  added the comment:


New changeset ad0a8a9c629a7a0fa306fbdf019be63c701a8028 by Gautam Chaudhuri in 
branch 'main':
bpo-16580: [doc] Add examples to int.to_bytes and int.from_bytes (GH-27760)
https://github.com/python/cpython/commit/ad0a8a9c629a7a0fa306fbdf019be63c701a8028


--

___
Python tracker 

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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

[Mark Dickinson]

Mark Dickinson  added the comment:

Merged. Thank you for the contribution!

--

___
Python tracker 

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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

[Mark Dickinson]

Change by Mark Dickinson :


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

[issue44917] interpreter hangs on recursion in both body and handler of a try block

[Irit Katriel]

Irit Katriel  added the comment:

Right, this is a duplicate of issue42951.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Random and infinite loop in dealing with recursion error for 
"try-except "

___
Python tracker 

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

[issue44919] TypedDict subtypes ignore any other metaclasses in 3.9+

[Nikita Sobolev]

New submission from Nikita Sobolev :

Some context. I have a `User` class defined as a `TypedDict`:

```python
from typing import TypedDict

class User(TypedDict):
name: str
registered: bool
```

Now, I want to check if some `dict` is an instance of `User` like so: 
`isinstance(my_dict, User)`. But, I can't. Because it raises 
`TypeError('TypedDict does not support instance and class checks')`. 

Ok. Let's change `__instancecheck__` method then. We can only do this in a 
metaclass:

```python
from typing import _TypedDictMeta

class UserDictMeta(_TypedDictMeta):
def __instancecheck__(cls, arg: object) -> bool:
return (
isinstance(arg, dict) and
isinstance(arg.get('name'), str) and
isinstance(arg.get('registered'), bool)
)


class UserDict(User, metaclass=UserDictMeta):
...
```

It looks like it should work. It used to work like this in Python3.7 and 
Python3.8.

But since Python3.9 it does not work.
Let's try to debug what happens:

```python
print(type(UserDict))  # 
print(UserDict.__instancecheck__(UserDict, {}))  # TypeError: TypedDict does 
not support instance and class checks
```

It looks like my custom `UserDictMeta` is completely ignored.
And I cannot change how `__instancecheck__` behaves.

I suspect that the reason is in these 2 lines: 
https://github.com/python/cpython/blob/ad0a8a9c629a7a0fa306fbdf019be63c701a8028/Lib/typing.py#L2384-L2385

What's the most unclear in this behavior is that it does not match regular 
Python subclass patterns. Simplified example of the same behavior, using only 
primite types:

```python
class FirstMeta(type):
def __instancecheck__(cls, arg: object) -> bool:
raise TypeError('You cannot use this type in isinstance() call')


class First(object, metaclass=FirstMeta):
...

# User space:

class MyClass(First): # this looks like a user-define TypedDict subclass
...


class MySubClassMeta(FirstMeta):
def __instancecheck__(cls, arg: object) -> bool:
return True  # just an override example


class MySubClass(MyClass, metaclass=MySubClassMeta):
...

print(isinstance(1, MySubClass))  # True
print(isinstance(1, MyClass))  # TypeError
```

As you can see our `MySubClassMeta` works perfectly fine this way.

I suppose that this is a bug in `TypedDict`, not a desired behavior. Am I 
correct?

--
components: Library (Lib)
messages: 399615
nosy: sobolevn
priority: normal
severity: normal
status: open
title: TypedDict subtypes ignore any other metaclasses in 3.9+
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue44914] tp_version_tag is not unique when test runs with -R :

[Mark Shannon]

Mark Shannon  added the comment:

Thanks for putting in the effort to find this.

I think the first step to fixing this is to formalize the semantics of 
`tp_version_tag`. Initially it was designed just for the method cache, but we 
have started using it as a unique identifier for the state of a class.
The two different uses have different requirements when the global version 
counter overflows. Possibly in other scenarios as well.

--

___
Python tracker 

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

[issue35203] Windows Installer Ignores Launcher Installer Options Where The Python Launcher Is Already Present

[Timothy Fleenor]

Timothy Fleenor  added the comment:

I am also having this same problem with python 3.9.5.. I am currently in 
windows 11 preview but it has also occurred for me in the windows 20h2 with no 
updates and caused a lot of issues running python for me including saying the 
pip command was not recognized.

--
nosy: +digidoggie18
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue44911] Leaked tasks cause IsolatedAsyncioTestCase to throw an exception

[Bar Harel]

Change by Bar Harel :


--
nosy: +michael.foord

___
Python tracker 

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

[issue44918] Unhandled Exception (Not Implemented) in HTMLParser().feed

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy:  -pablogsal

___
Python tracker 

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

[issue44914] tp_version_tag is not unique when test runs with -R :

[Ken Jin]

Ken Jin  added the comment:

@Mark, agreed about properly defining the semantics.

For the current bug: I've narrowed it down to a corner case in how the -R tests 
work:

1. On each run cleanup, libregrtest will clear the type cache 
https://github.com/python/cpython/blob/6f84656dc188191225c8d5cdfd2a00de663988d0/Lib/test/libregrtest/refleak.py#L170

2. This calls PyType_ClearCache, which sets the global next_version_tag counter 
to 0 
https://github.com/python/cpython/blob/cee67fa66129b5d1db5c8aa3884338f82f0da3de/Objects/typeobject.c#L292.

3. On next run, since runs and type cache is deterministic, we end up with 
exact same tp_version_tag for the type.

4. This repeats every run until crash.

One possible fix: we can tell sys._clear_type_cache to not reset 
next_version_tag to 0 (it can use another function, since PyType_ClearCache is 
part of public C API and shouldn't be modified).

This seems like a bug in libregrtest, the type method cache and tp_version_tag 
aren't at fault for this specific scenario. I'm submitting a PR soon.

--

___
Python tracker 

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

[issue44918] Unhandled Exception (Not Implemented) in HTMLParser().feed

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Seems similar to https://bugs.python.org/issue38573

--
nosy: +xtreak

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> GH-27772 reverts the behaviour change but keeps the fix for the undefined 
> behaviour. Can the backport of GH-27772 to the 3.10 branch go in before 
> 3.10.0 final?

Thanks for checking with me! 

Given that this is fixing a bug that we introduced in rc1, I think it makes 
sense to backport to fix it. I have reviewed the code in GH-27772 and is 
contained enough, so I think is a good idea to go ahead.

Thanks Mark for all the work!

--

___
Python tracker 

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

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I'm keeping track to the 3.10 backports to the second rc so could you add me as 
a reviewer for the backport?

--

___
Python tracker 

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

[issue44904] Erroneous behaviour for abstract class properties

[Alex Waygood]

Alex Waygood  added the comment:

This same bug (where classmethod properties are accidentally called by other 
parts of Python) is also present for non-abstract class properties, and has the 
side effect of causing doctest.py to crash with a fairly incomprehensible 
`AttributeError`:

Script:

class Untestable:
"""
>>> Untestable.my_classmethod_property
'Oh no!'
"""

@classmethod
@property
def my_classmethod_property(cls):
return 'Oh no!'


if __name__ == '__main__':
import doctest
doctest.testmod()

Output:

Traceback (most recent call last):
  File "C:/Users/Alex/classmethod_properties_bug.py", line 13, in 
doctest.testmod()
  File "C:\Users\Alex\.conda\envs\WebGame39\lib\doctest.py", line 1955, in 
testmod
for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "C:\Users\Alex\.conda\envs\WebGame39\lib\doctest.py", line 939, in 
find
self._find(tests, obj, name, module, source_lines, globs, {})
  File "C:\Users\Alex\.conda\envs\WebGame39\lib\doctest.py", line 1001, in 
_find
self._find(tests, val, valname, module, source_lines,
  File "C:\Users\Alex\.conda\envs\WebGame39\lib\doctest.py", line 1028, in 
_find
val = getattr(obj, valname).__func__
AttributeError: 'str' object has no attribute '__func__'

--
nosy: +AlexWaygood
Added file: https://bugs.python.org/file50218/classmethod_properties_bug.py

___
Python tracker 

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

[issue44914] tp_version_tag is not unique when test runs with -R :

[Mark Shannon]

Change by Mark Shannon :


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

___
Python tracker 

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

[issue44914] tp_version_tag is not unique when test runs with -R :

[Mark Shannon]

Mark Shannon  added the comment:

PyType_ClearCache() is documented as:

Clear the internal lookup cache. Return the current version tag.

Modifying it to do what it is documented to do fixes this bug :)

--

___
Python tracker 

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

[issue44920] Support UUIDv6, UUIDv7, and UUIDv8 from the new version of RFC4122

[Steve Simmons]

New submission from Steve Simmons :

Three new types of UUIDs have been proposed in the latest draft of the next 
version of RFC4122. Full text of that draft is in [1] (published 21 April 2021; 
draft period ends 21 Oct 2021).

Support for these should be included in uuid.py for Python 3.11, with backport 
for 3.9 and 3.10. The timetable for Python 3.11 should fit with the end of the 
IETF draft period.

Implementation should be similar to the existing UUID classes in uuid.py, the 
prototypes in [2], or even parts of my own uuid6 version [3].

[1] https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format
[2] https://github.com/uuid6/prototypes/tree/main/python
[3] https://github.com/stevesimmons/pyuuid6/blob/main/uuid6.py

--
components: Library (Lib)
messages: 399624
nosy: stevesimmons
priority: normal
severity: normal
status: open
title: Support UUIDv6, UUIDv7, and UUIDv8 from the new version of RFC4122
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue44921] dict subclassing is slow

[Marco Sulla]

New submission from Marco Sulla :

I asked on SO why subclassing dict makes the subclass much slower in some 
operations. This is the answer by Monica 
(https://stackoverflow.com/a/59914459/1763602):

Indexing and in are slower in dict subclasses because of a bad interaction 
between a dict optimization and the logic subclasses use to inherit C slots. 
This should be fixable, though not from your end.

The CPython implementation has two sets of hooks for operator overloads. There 
are Python-level methods like __contains__ and __getitem__, but there's also a 
separate set of slots for C function pointers in the memory layout of a type 
object. Usually, either the Python method will be a wrapper around the C 
implementation, or the C slot will contain a function that searches for and 
calls the Python method. It's more efficient for the C slot to implement the 
operation directly, as the C slot is what Python actually accesses.

Mappings written in C implement the C slots sq_contains and mp_subscript to 
provide in and indexing. Ordinarily, the Python-level __contains__ and 
__getitem__ methods would be automatically generated as wrappers around the C 
functions, but the dict class has explicit implementations of __contains__ and 
__getitem__, because the explicit implementations 
(https://github.com/python/cpython/blob/v3.8.1/Objects/dictobject.c) are a bit 
faster than the generated wrappers:

static PyMethodDef mapp_methods[] = {
DICT___CONTAINS___METHODDEF
{"__getitem__", (PyCFunction)(void(*)(void))dict_subscript,METH_O | 
METH_COEXIST,
 getitem__doc__},
...

(Actually, the explicit __getitem__ implementation is the same function as the 
mp_subscript implementation, just with a different kind of wrapper.)

Ordinarily, a subclass would inherit its parent's implementations of C-level 
hooks like sq_contains and mp_subscript, and the subclass would be just as fast 
as the superclass. However, the logic in update_one_slot 
(https://github.com/python/cpython/blob/v3.8.1/Objects/typeobject.c#L7202) 
looks for the parent implementation by trying to find the generated wrapper 
methods through an MRO search.

dict doesn't have generated wrappers for sq_contains and mp_subscript, because 
it provides explicit __contains__ and __getitem__ implementations.

Instead of inheriting sq_contains and mp_subscript, update_one_slot ends up 
giving the subclass sq_contains and mp_subscript implementations that perform 
an MRO search for __contains__ and __getitem__ and call those. This is much 
less efficient than inheriting the C slots directly.

Fixing this will require changes to the update_one_slot implementation.

Aside from what I described above, dict_subscript also looks up __missing__ for 
dict subclasses, so fixing the slot inheritance issue won't make subclasses 
completely on par with dict itself for lookup speed, but it should get them a 
lot closer.

As for pickling, on the dumps side, the pickle implementation has a dedicated 
fast path 
(https://github.com/python/cpython/blob/v3.8.1/Modules/_pickle.c#L4291) for 
dicts, while the dict subclass takes a more roundabout path through 
object.__reduce_ex__ and save_reduce.

On the loads side, the time difference is mostly just from the extra opcodes 
and lookups to retrieve and instantiate the __main__.A class, while dicts have 
a dedicated pickle opcode for making a new dict. If we compare the disassembly 
for the pickles:

In [26]: pickletools.dis(pickle.dumps({0: 0, 1: 1, 2: 2, 3: 3, 4: 4}))  

 
0: \x80 PROTO  4
2: \x95 FRAME  25
   11: }EMPTY_DICT
   12: \x94 MEMOIZE(as 0)
   13: (MARK
   14: KBININT10
   16: KBININT10
   18: KBININT11
   20: KBININT11
   22: KBININT12
   24: KBININT12
   26: KBININT13
   28: KBININT13
   30: KBININT14
   32: KBININT14
   34: uSETITEMS   (MARK at 13)
   35: .STOP
highest protocol among opcodes = 4

In [27]: pickletools.dis(pickle.dumps(A({0: 0, 1: 1, 2: 2, 3: 3, 4: 4})))   

 
0: \x80 PROTO  4
2: \x95 FRAME  43
   11: \x8c SHORT_BINUNICODE '__main__'
   21: \x94 MEMOIZE(as 0)
   22: \x8c SHORT_BINUNICODE 'A'
   25: \x94 MEMOIZE(as 1)
   26: \x93 STACK_GLOBAL
   27: \x94 MEMOIZE(as 2)
   28: )EMPTY_TUPLE
   29: \x81 NEWOBJ
   30: \x94 MEMOIZE(as 3)
   31: (MARK
   32: KBININT10
   34: KBININT10
   36: KBININT11
   38: KBININT11
   40: KBININT12
   42: KBININT12
   44: KBININT13
   46: KBININT13
   48: KBININ

[issue44897] Integrate trashcan mechanism into _Py_Dealloc

[Neil Schemenauer]

Neil Schemenauer  added the comment:

As I suspected, the performance impact is significant (although pretty small).  
Based on Linux perf, it looks like the extra test+branch in _Py_Dealloc adds 
about 1% overhead.  pyperformance shows something similar, see attached reports 
(pypref-trashcan.txt and perf-annotate-trash.txt).

An idea I've been trying is to add another type slot, e.g. tp_call_dealloc.  It 
could be set by PyType_Ready().  It would be called by the Py_DECREF macro on 
refcnt going to zero.  If the object is non-GC and Py_TRACE_REFS is off, can 
make tp_call_dealloc actually be the tp_dealloc pointer.  If the type has the 
GC flag, point tp_call_dealloc to a _Py_Dealloc version that checks tp_is_gc 
and does the trashcan stuff.

Unfortunately, all types don't have PyType_Ready() called on them.  So, we 
cannot rely on tp_call_dealloc being set correctly.

--
Added file: https://bugs.python.org/file50219/pyperf-trashcan.txt

___
Python tracker 

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

[issue44897] Integrate trashcan mechanism into _Py_Dealloc

[Neil Schemenauer]

Change by Neil Schemenauer :


Added file: https://bugs.python.org/file50220/perf-annotate-trash.txt

___
Python tracker 

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

[issue42560] Improve Tkinter Documentation

[Mark Roseman]

Mark Roseman  added the comment:

Here's a very rough work-in-progress snapshot:
https://github.com/roseman/cpython/blob/tkinter-docs-snapshot-20210815/Doc/library/tkinter.rst

This includes:

1. Changes I'd mentioned to the intro, external resources, modules, architecture

2. Rewrite of the 'life preserver' mini-tutorial section using a very different 
approach.

3. A start on the reference section (replacing the random bits that were there 
with a categorized, but detail-free list of classes and common methods).

Anyone have any big picture thoughts at this point?

--

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

[issue44922] isinstance breaks on imported dataclasses

[Oleg Baskakov]

New submission from Oleg Baskakov :

Hey I was trying to import dataclasses from another file and somehow isinstance 
doesn't work anymore:
main.py:
```
import codegen
from dataclasses import dataclass

@dataclass
class AtomX:
my_symbol: str
quantity: str = ""

codegen.inheritance_map(AtomX("qwerty"))

```
codegen.py:
```
from main import AtomX

def inheritance_map(candidate):
assert isinstance(candidate, AtomX)
```

PS the same code with `assert candidate.__class__.__name__ == "AtomX"` works 
fine


Python 3.9.6 (v3.9.6:db3ff76da1, Jun 28 2021, 11:49:53) 
[Clang 6.0 (clang-600.0.57)] on darwin
I'm running inside of PyCharm

--
messages: 399628
nosy: baskakov
priority: normal
severity: normal
status: open
title: isinstance breaks on imported dataclasses
type: behavior
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

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

[Danya Sucharik]

Danya Sucharik  added the comment:

May I aks, how it to add a doctype now?

--
nosy: +sucharik
versions: +Python 3.8 -Python 3.5

___
Python tracker 

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

[issue42560] Improve Tkinter Documentation

[Terry J. Reedy]

Terry J. Reedy  added the comment:

> Anyone have any big picture thoughts at this point?

Yes.  For years, I have wanted major changes in out tkinter docs, but making 
them myself has never become a top priority for me over working directly on 
IDLE.  The latter has been hampered by the inadequate tkinter docs.  
Fortunately, I have learned to interpret the online tk docs.  But I would be 
happy work with you, Mark, to make something better.  My perspective is that of 
an competent but occasionally user who cannot keep all of tkinter in my head 
and needs a good reference that does not currently exist.

(I am currently working on two other writing projects, but one should be done 
in a few days.  So I should look at your proposals within a week.  I already 
reviewed and critiqued Mason's PR.)

I would like a complete, in some some sense, internal reference, which would 
would be able to correct ad further improve.  Complete means everything in the 
Shipman 8.5 references, but somewhat rearranged and more compact. Current 
references both external and internal, are variously obsolete, incomplete, and 
buggy.  The latter two apply to our internal ttk doc.  All external references 
suffer from being out of pydev control.

I don't see the tcl/tk versions as an issue.  First, the 3.x *tkinter* docs 
should document the features available in the 3.x version of the tkinter 
module.  It could mention that it should best be used with the most recent 
tcl/tk 8.6 possible.

Second, the Centos is about the only *nix distribution not having 8.6 
available.  On another thread where the question of using something new in 8.6 
came up, someone posted a link to a site with distribution versus tcl/tk 
information.  Unfortunately, I cannot find it.  The 8.6.z releases mostly add 
bugfixes.  The new-in-8.6 features listed on 
https://www.tcl.tk/software/tcltk/8.6.html should be in all or most all of 
8.6.z releases.

My 'biggest' idea is that we should document tk and ttk widgets together.  I 
don't think we should continue to treat ttk as just an optional, and by 
implication, 'advanced' add-on.  Each entry should be labelled tk, tk&ttk, or 
ttk.  Or perhaps there should be 3 subsections so labelled.  The ttk doc only 
has widget entries for ttk (only).  Perhaps the authors felt that full entries 
for 'tk&ttk' widgets would be mostly redundant with docs for the tk versions.  
I agree, and propose entries that cover both.

We should expand on what the ttk doc does in separately documenting options 
common to more than one widget. I would like to add 1) a table (matrix) of 
common option versus widget, with marks indicating which option can be used 
with which widget, and 2) links from each widget doc to the blocks of common 
widgets it uses.

The initial chapters of Shipman are mostly about possible values for some of 
the options.  These belong together in the 'Options' subsection.

--

___
Python tracker 

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

[issue44922] isinstance breaks on imported dataclasses

[Eric V. Smith]

Eric V. Smith  added the comment:

I get a circular import error:

Traceback (most recent call last):
  File "main.py", line 1, in 
import codegen
  File "/cygdrive/c/home/eric/codegen.py", line 1, in 
from main import AtomX
  File "/cygdrive/c/home/eric/main.py", line 9, in 
codegen.inheritance_map(AtomX("qwerty"))
AttributeError: partially initialized module 'codegen' has no attribute 
'inheritance_map' (most likely due to a circular import)

So I can't reproduce this problem.

--
nosy: +eric.smith

___
Python tracker 

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

[issue44921] dict subclassing is slow

[Jack DeVries]

Jack DeVries  added the comment:

There was a thorough discussion about the concerns associated with supporting 
dict subclasses in general here: bpo-32615

If I understand correctly, allowing dict subclasses to inherit __contains__ and 
__getitem__ will be a step towards supporting dict subclasses in a more broad 
context, like being able to use them as namespaces passed to exec. 

Ultimately, dictionaries are at the very heart of Cpython's implementation. I 
think it is reasonable to say that it is not possible or reasonable to support 
users in creating custom dict implantation with their own behavior. There is no 
good real world use case for it (please tell me if anyone has one), and it 
opens the door to enormous unnecessary complexity. 

Also related to dict subclassing:
bpo-15099
bpo-27561

Marco, I hope that the discussions I've linked will at least make it clear why 
cpython behaves this way, and what the concerns are especially around 
supporting user subclasses of dict. I noticed you tagged this bpo as 
performance, but there are significant negative performance implications around 
dict subclasses that you'll see in past discussions.

With this additional context in mind, what changes do you propose?

--
nosy: +jack__d

___
Python tracker 

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

[issue44888] ssl.OP_LEGACY_SERVER_CONNECT missing

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +26248
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27776

___
Python tracker 

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

[issue44922] isinstance breaks on imported dataclasses

[Oleg Baskakov]

Oleg Baskakov  added the comment:

Sorry, I forgot to add if __name__ line:
```
import codegen
from dataclasses import dataclass

@dataclass
class AtomX:
my_symbol: str
quantity: str = ""


if __name__ == "__main__":
codegen.inheritance_map(AtomX("qwerty"))

```

So the output:
```
Traceback (most recent call last):
  File "/Users/baskakov/PycharmProjects/main.py", line 11, in 
codegen.inheritance_map(AtomX("qwerty"))
  File "/Users/baskakov/PycharmProjects/codegen.py", line 5, in inheritance_map
assert isinstance(candidate, AtomX)
AssertionError

```

--
Added file: https://bugs.python.org/file50221/main.py

___
Python tracker 

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

[issue44922] isinstance breaks on imported dataclasses

[Eric V. Smith]

Eric V. Smith  added the comment:

You're importing main.py twice. The first is when you run "python main.py", 
where it has the module name '__main__'. The second time is in codegen.py, 
where it has the name 'main'. You create the AtomX instance as __main__.AtomX, 
but the isinstance check is against main.AtomX. Because the objects have 
different modules, they're not equal.

You can see this if you change the isinstance check to:

=
from main import AtomX
import sys

def inheritance_map(candidate):
assert isinstance(candidate, sys.modules['__main__'].AtomX)
==

Another way to see this if you add a print statement to the original codegen.py:

==
from main import AtomX

def inheritance_map(candidate):
print(f'{candidate=} {type(candidate)=} {AtomX=}')
assert isinstance(candidate, AtomX)
==

Which will print:
candidate=AtomX(my_symbol='qwerty', quantity='') type(candidate)= AtomX=
Notice the types refer to different modules, so they are distinct and unequal.

The easiest way around this is to not do any work in main.py, but instead 
create another module, import it from main.py, and do the work there.

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

___
Python tracker 

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