[issue41818] Lib/pty.py major revision

[Soumendra Ganguly]

Change by Soumendra Ganguly :


--
pull_requests: +22598
pull_request: https://github.com/python/cpython/pull/23740

___
Python tracker 

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

[issue39717] Fix exception causes in tarfile module

[Ethan Furman]

Change by Ethan Furman :


--
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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

[issue39717] Fix exception causes in tarfile module

[Ethan Furman]

Change by Ethan Furman :


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

___
Python tracker 

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

[issue41559] Add support for PEP 612 to typing.py

[Guido van Rossum]

Guido van Rossum  added the comment:

I started doing this in the original code (long ago when PEP 484 was brand
new) but have since realized that this makes the typing module both slow
and hard to maintain. We should not follow this example. I do think we
should try to keep `__args__` hashable, casting `[int, str]` to `(int,
str)` sounds right.

--

___
Python tracker 

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

[issue42609] Eval with too high string multiplication crashes newer Python versions

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +methane

___
Python tracker 

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

[issue42609] Eval with too high string multiplication crashes newer Python versions

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue40747] sysconfig.get_config_var("py_version_nodot") should return 3_10

[Steve Dower]

Steve Dower  added the comment:

This has been blocking it: 
https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513

Pablo (PEP delegate) has just posted his rejection though, so it will be fixed 
when packaging changes back to "310" from "3_10" and updates percolate out 
through the ecosystem.

Since moving to "4.x" is a breaking change, we can change to any system we like 
at that point. Well in advance of 31.0 being ambiguous.

--
resolution:  -> rejected
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

[issue41559] Add support for PEP 612 to typing.py

[Ken Jin]

Ken Jin  added the comment:

The pyre version in their __init__.py looks like they took your advice for
letting the static checker do the work wholeheartedly.

I'm not in favour of type checking either. Just that the pre-existing code
does it for me.

Not type checking when seeing ~P in __parameters__ would work, just that
__args__ will be unhashable (like you mentioned) so things will be slower
due to no type cache. Maybe we can cast the [int, str] to (int, str), that
should work with cache for most cases. And unlike the Callable issue -
since we don't need to ensure runtime correctness - we can ignore any weird
effects to __args__ and __parameters__ in ParamSpec, like TypeVars not
collecting etc.

--

___
Python tracker 

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

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Karl Nelson]

Karl Nelson  added the comment:

Oddly that was the only exception that I got.  When I hit continue it proceeded 
without issue and the dll was loaded correctly.   However, when I try without 
the debugger attached the error reappears.   So this is one of those 
Schrodinger errors.   I know the error is there because I see it when we run on 
the CI and on a local machine,  but all attempts to isolate it say that is 
should not exist.  There can't really be a path that is different when 
compiling then loading from a pyc unless this is some type of uninitialized 
variable issues where we just happened to have been unfortunate enough to hit 
it.

--

___
Python tracker 

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

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Steve Dower]

Steve Dower  added the comment:

Replicating also requires installing Java (I got as far as the build failing), 
which is going to have to wait until I have time to spin up a throwaway machine 
:)

That exception is a normal part of the import process and should be being 
handled. It's not the same one that eventually terminates the program.

I'd continue past that one and keep continuing until you hit one that looks 
like "DLL initialization routine failed". That *should* come out of the DLL 
that is actually failing, which Python isn't able to identify, and will give us 
hints toward the actual root cause.

--

___
Python tracker 

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

[issue42083] PyStructSequence_NewType broken in 3.8

[Steve Stagg]

Steve Stagg  added the comment:

It looks like the segfault was fixed in 
https://github.com/python/cpython/commit/88c2cfd9ffbcfc43fd1364f2984852a819547d43

as part of https://bugs.python.org/issue41832.

The code in this area of typeobject.c looks a bit different, now, but the 
backport seems simple?

Simple testcase:

#include 
#include 
int main() {
Py_Initialize();
PyStructSequence_Field fields[2] = {
{NULL, NULL}
};
PyStructSequence_Desc d = {"test", NULL, [0], 0};
PyStructSequence_NewType();
Py_Finalize();
}

Segfault reproducible on 3.8 and 3.9

--
nosy: +stestagg

___
Python tracker 

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

[issue42618] Enhancement request for importing stacktraces from foreign sources

[Karl Nelson]

New submission from Karl Nelson :

In JPype, I am transfer stack information from Java into Python for diagnostics 
and display purposed.  Unfortunately, as the exception system is directly 
accessing traceback structure elements this cannot be replicated without 
creating traceback structures in C.   I have thus been forced to create new 
methods that create this using internal Python structures.  It would be much 
better if there were C API method to allow importing a foreign stack trace into 
Python.

Here is an example of the code used in JPype for reference.


```
// Transfer list of filenames, functions and lines to Python.
PyObject* PyTrace_FromJPStackTrace(JPStackTrace& trace)
{
PyTracebackObject *last_traceback = NULL;
PyObject *dict = PyModule_GetDict(PyJPModule);
for (JPStackTrace::iterator iter = trace.begin(); iter != trace.end(); 
++iter)
{
last_traceback = tb_create(last_traceback, dict,  
iter->getFile(),
iter->getFunction(), iter->getLine());
}
if (last_traceback == NULL)
Py_RETURN_NONE;
return (PyObject*) last_traceback;
}

PyTracebackObject *tb_create(   

PyTracebackObject *last_traceback,
PyObject *dict, 

const char* filename,
const char* funcname,
int linenum)
{
// Create a code for this frame.
PyCodeObject *code = PyCode_NewEmpty(filename, funcname, linenum);
// Create a frame for the traceback.
PyFrameObject *frame = (PyFrameObject*) 
PyFrame_Type.tp_alloc(_Type, 0);
frame->f_back = NULL;
if (last_traceback != NULL)
{
frame->f_back = last_traceback->tb_frame;
Py_INCREF(frame->f_back);
}
frame->f_builtins = dict;
Py_INCREF(frame->f_builtins);
frame->f_code = (PyCodeObject*) code;
frame->f_executing = 0;
frame->f_gen = NULL;
frame->f_globals = dict;
Py_INCREF(frame->f_globals);
frame->f_iblock = 0;
frame->f_lasti = 0;
frame->f_lineno = 0;
frame->f_locals = NULL;
frame->f_localsplus[0] = 0;
frame->f_stacktop = NULL;
frame->f_trace = NULL;
frame->f_valuestack = 0;
#if PY_VERSION_HEX>=0x0307
frame->f_trace_lines = 0;
frame->f_trace_opcodes = 0;
#endif
// Create a traceback
PyTracebackObject *traceback = (PyTracebackObject*)
PyTraceBack_Type.tp_alloc(_Type, 0);
traceback->tb_frame = frame;
traceback->tb_lasti = frame->f_lasti;
traceback->tb_lineno = linenum;
traceback->tb_next = last_traceback;
return traceback;
}

```

--
components: C API
messages: 382852
nosy: Thrameos
priority: normal
severity: normal
status: open
title: Enhancement request for importing stacktraces from foreign sources
type: enhancement

___
Python tracker 

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

[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset 67b769f5157c9dad1c7dd6b24e067b9fdab5b35d by Alex Grönholm in 
branch 'master':
bpo-42059: Fix required/optional keys for TypedDict(..., total=False) (GH-22736)
https://github.com/python/cpython/commit/67b769f5157c9dad1c7dd6b24e067b9fdab5b35d


--

___
Python tracker 

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

[issue42617] Enhancement request for PyType_FromSpecWIthBases add option for meta class

[Karl Nelson]

New submission from Karl Nelson :

PyType_FromSpecWithBases is missing an argument for taking a meta class.  As a 
result it is necessary to replicate a large portion of Python code when I need 
to create a new heap type with a specified meta class.  This is a maintenance 
issue as replicating Python code is likely to get broken in future.

I have replicated to code from JPype so that it is clear how the meta class is 
coming into place.   PyJPClass_Type is derived from a 
PyHeapType with additional slots for Java to use and overrides allocation slots 
to that it can add extra slots (needs true multiple inheritance as it needed to 
add Java slots to types with mismatching memory layouts object, long, float, 
exception, ...).

This code could be made much safer if there were a PyType_FromSpecWithBasesMeta 
which used the meta class to allocate the memory (then I could safely override 
the slots after creation).
 

```
PyObject* PyJPClass_FromSpecWithBases(PyType_Spec *spec, PyObject *bases)
{
JP_PY_TRY("PyJPClass_FromSpecWithBases");
// Python lacks a FromSpecWithMeta so we are going to have to fake it 
here.
PyTypeObject* type = (PyTypeObject*) 
PyJPClass_Type->tp_alloc(PyJPClass_Type, 0); // <== we need to use the meta 
class here
PyHeapTypeObject* heap = (PyHeapTypeObject*) type;
type->tp_flags = spec->flags | Py_TPFLAGS_HEAPTYPE | Py_TPFLAGS_HAVE_GC;
type->tp_name = spec->name;
const char *s = strrchr(spec->name, '.');
if (s == NULL)
s = spec->name;
else
s++;
heap->ht_qualname = PyUnicode_FromString(s);
heap->ht_name = heap->ht_qualname;
Py_INCREF(heap->ht_name);
if (bases == NULL)
type->tp_bases = PyTuple_Pack(1, (PyObject*) & 
PyBaseObject_Type);
else
{
type->tp_bases = bases;
Py_INCREF(bases);
}
type->tp_base = (PyTypeObject*) PyTuple_GetItem(type->tp_bases, 0);
Py_INCREF(type->tp_base);
type->tp_as_async = >as_async;
type->tp_as_buffer = >as_buffer;
type->tp_as_mapping = >as_mapping;
type->tp_as_number = >as_number;
type->tp_as_sequence = >as_sequence;
type->tp_basicsize = spec->basicsize;
if (spec->basicsize == 0)
type->tp_basicsize = type->tp_base->tp_basicsize;
type->tp_itemsize = spec->itemsize;
if (spec->itemsize == 0)
type->tp_itemsize = type->tp_base->tp_itemsize;

// <=== Replicated code from the meta class 
type->tp_alloc = PyJPValue_alloc;
type->tp_free = PyJPValue_free;
type->tp_finalize = (destructor) PyJPValue_finalize;

// <= Replicated code from Python
for (PyType_Slot* slot = spec->slots; slot->slot; slot++)
{
   switch (slot->slot)
{
case Py_tp_free:
type->tp_free = (freefunc) slot->pfunc;
break;
case Py_tp_new:
type->tp_new = (newfunc) slot->pfunc;
break;
case Py_tp_init:
type->tp_init = (initproc) slot->pfunc;
break;
case Py_tp_getattro:
type->tp_getattro = (getattrofunc) slot->pfunc;
break;
case Py_tp_setattro:
type->tp_setattro = (setattrofunc) slot->pfunc;
break;
case Py_tp_dealloc:
type->tp_dealloc = (destructor) slot->pfunc;
break;
case Py_tp_str:
type->tp_str = (reprfunc) slot->pfunc;
break;
case Py_tp_repr:
type->tp_repr = (reprfunc) slot->pfunc;
break;
case Py_tp_methods:
type->tp_methods = (PyMethodDef*) slot->pfunc;
break;
case Py_sq_item:
heap->as_sequence.sq_item = (ssizeargfunc) 
slot->pfunc;
break;
case Py_sq_length:
heap->as_sequence.sq_length = (lenfunc) 
slot->pfunc;
break;
case Py_mp_ass_subscript:
heap->as_mapping.mp_ass_subscript = 
(objobjargproc) slot->pfunc;
break;
case Py_tp_hash:
type->tp_hash = (hashfunc) slot->pfunc;
break;
  

[issue42609] Eval with too high string multiplication crashes newer Python versions

[Steve Stagg]

Steve Stagg  added the comment:

In python 3.7/8, It's a stack overflow in the constant folding code.

On master, the overflow seems to come out of validate_expr.c.

* thread #1, name = 'python3', stop reason = signal SIGSEGV: invalid address 
(fault address: 0x7f7feff8)
frame #0: 0x557aadba python3`validate_expr(exp=0x602617c0, 
ctx=Load) at ast.c:224:16
   221  }
   222  return validate_exprs(exp->v.BoolOp.values, Load, 0);
   223  case BinOp_kind:
-> 224  return validate_expr(exp->v.BinOp.left, Load) &&
   225  validate_expr(exp->v.BinOp.right, Load);
   226  case UnaryOp_kind:
   227  return validate_expr(exp->v.UnaryOp.operand, Load);


300,000 ish stack frames of this:

frame #70832: 0x557aadbf 
python3`validate_expr(exp=0x6150af40, ctx=Load) at ast.c:224:16
frame #70833: 0x557aadbf 
python3`validate_expr(exp=0x6150b050, ctx=Load) at ast.c:224:16
frame #70834: 0x557aadbf 
python3`validate_expr(exp=0x6150b160, ctx=Load) at ast.c:224:16
frame #70835: 0x557aadbf 
python3`validate_expr(exp=0x6150b270, ctx=Load) at ast.c:224:16
frame #70836: 0x557aadbf 
python3`validate_expr(exp=0x6150b380, ctx=Load) at ast.c:224:16
frame #70837: 0x557aadbf 
python3`validate_expr(exp=0x6150b490, ctx=Load) at ast.c:224:16
frame #70838: 0x557aadbf 
python3`validate_expr(exp=0x6150b5a0, ctx=Load) at ast.c:224:16
frame #70839: 0x557aadbf 
python3`validate_expr(exp=0x6150b6b0, ctx=Load) at ast.c:224:16


On the one hand, pure python code should never segfault, on the other hand, 
`eval`ling untrusted input has bigger problems than a segfault on carefully 
crafted input.

--

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Antony Lee]

Change by Antony Lee :


--
nosy:  -Antony.Lee

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Antony Lee]

Antony Lee  added the comment:

Thanks for implementing!

--

___
Python tracker 

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

[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does

[Antony Lee]

Change by Antony Lee :


--
nosy:  -Antony.Lee

___
Python tracker 

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

[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does

[Antony Lee]

Antony Lee  added the comment:

Thanks!

--

___
Python tracker 

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

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Karl Nelson]

Karl Nelson  added the comment:

I managed to get the debugger attached (unfortunately I am not a windows 
programmer so I don't use these tools). 

It appears when loading from a pyc, it is attempting to open the directory as a 
Zip file which is throwing an exception resulting in a failure to load the 
internal _jpype module.   

Unfortunately this is outside my area as nothing in jpype nor _jpype is calling 
the zipimport module.  So it must be something internal to Python.  It is a 
major issue as I can't release to anaconda on windows until I can resolve the 
problem.   Can you direct me how to proceed?

Details:

zipimport.ZipImportError
  Message=not a Zip file
  StackTrace:
:88 in __init__

Replicating the problem is simple.   Download jpype from git, use "python 
setup.py develop" to create the module, run python -c  "import jpype", and 
repeat python -c "import jpype"

Screen shot of the visual studio error is shown.

--
Added file: https://bugs.python.org/file49665/Capture.PNG

___
Python tracker 

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

[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does

[Ethan Furman]

Change by Ethan Furman :


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

[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does

[Ethan Furman]

Ethan Furman  added the comment:


New changeset a65828717982e6a56382d7aff738478f5b5b25d0 by Ethan Furman in 
branch 'master':
bpo-34750: [Enum] add `_EnumDict.update()` support (GH-23725)
https://github.com/python/cpython/commit/a65828717982e6a56382d7aff738478f5b5b25d0


--

___
Python tracker 

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

[issue42609] Eval with too high string multiplication crashes newer Python versions

[Steve Stagg]

Steve Stagg  added the comment:

Looks like it was introduced by 
https://github.com/python/cpython/commit/7ea143ae795a9fd57eaccf490d316bdc13ee9065:

bpo-29469: Move constant folding to AST optimizer (GH-2858)

--
nosy: +stestagg

___
Python tracker 

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

[issue41559] Add support for PEP 612 to typing.py

[Guido van Rossum]

Guido van Rossum  added the comment:

For reference, here's what Pyre has (though it's an older version):

https://github.com/facebook/pyre-check/tree/master/pyre_extensions

--

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Ethan Furman]

Ethan Furman  added the comment:

Thank you for finding that, Antony.

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

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

[Tom Birch]

New submission from Tom Birch :

After https://github.com/python/cpython/pull/12946, there exists an issue on 
MacOS due to the two-level namespace for symbol resolution. If a C extension 
links against libpython.dylib, all symbols dependencies from the Python C API 
will be bound to libpython. When the C extension is loaded into a process 
launched by running the `python` binary, there will be two active copies of the 
python runtime. This can lead to crashes if objects from one runtime are used 
by the other.

https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-BCIHJBBF

See issue/test case here: https://github.com/PDAL/python/pull/76

--
components: C API, macOS
messages: 382841
nosy: froody, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: C Extensions on Darwin that link against libpython are likely to crash
type: crash
versions: Python 3.8, Python 3.9

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Ethan Furman]

Ethan Furman  added the comment:


New changeset efb13be72cbf49edf591936fafb120fe1b7d59f7 by Ethan Furman in 
branch 'master':
bpo-42385: [Enum] add `_generate_next_value_` to StrEnum (GH-23735)
https://github.com/python/cpython/commit/efb13be72cbf49edf591936fafb120fe1b7d59f7


--

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[Václav Brožek]

Václav Brožek  added the comment:

https://github.com/python/cpython/pull/23737 has the initial draft of the check 
against misspelled arguments.

--

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[Václav Brožek]

Change by Václav Brožek :


--
pull_requests: +22596
pull_request: https://github.com/python/cpython/pull/23737

___
Python tracker 

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

[issue41928] ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field

[Andrea Giudiceandrea]

Change by Andrea Giudiceandrea :


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

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Ethan Furman]

Change by Ethan Furman :


--
pull_requests: +22594
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23735

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[miss-islington]

miss-islington  added the comment:


New changeset 9fc571359af9320fddbe4aa2710a767f168c1707 by vabr-g in branch 
'master':
bpo-41877: Improve docs for assert misspellings check in mock (GH-23729)
https://github.com/python/cpython/commit/9fc571359af9320fddbe4aa2710a767f168c1707


--
nosy: +miss-islington

___
Python tracker 

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

[issue42385] adjust enum.auto's behavior for StrEnum to return the enum name

[Ethan Furman]

Change by Ethan Furman :


--
stage: patch review -> needs patch
title: Should enum.auto's behavior be adjusted for StrEnum to return the enum 
name? -> adjust enum.auto's behavior for StrEnum to return the enum name

___
Python tracker 

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

[issue41559] Add support for PEP 612 to typing.py

[Guido van Rossum]

Guido van Rossum  added the comment:

> class X(Generic[T, P]): ...
> 
> 1. X[int, [int, bool]] raises TypeError because second arg isn't a type (this 
> is easy to fix).

How would you fix it? By just allowing it? But then X.__args__ would be 
unhashable (see the other issue we're working on together).

> 2. X[int, ...] raises TypeError because for the same reason. One way to fix 
> this is to automatically convert Ellipsis to EllipsisType just like how we 
> already convert None to NoneType. Only problem now is that Callable[[...], 
> int] doesn't raise TypeError. Should we just defer the problem of validating 
> Callable to static type checkers instead?

I don't like using EllipsisType here, because this notation doesn't mean that 
we accept an ellipsis here -- it means (if I understand the PEP correctly) that 
we don't care about the paramspec.

> class Z(Generic[P]): ...
> 
> 3. Z[[int, str, bool]] raises TypeError, same as 1.

Same comment.

> 4. Z[int, str, bool] raises TypeError, but for too many parameters (not 
> enough TypeVars). This one troubles me the most, current TypeVar substitution 
> checks for len(__args__) == len(__parameters__).

The code should check that __parameters__ is (P,) for some ParamSpec P, and 
then transform this internally as if it was written Z[[int, str, bool]] and 
then typecheck that.

**BUT...**

How about an alternative implementation where as soon as we see that there's a 
ParamSpec in __parameters__ we just don't type-check at all, and accept 
anything? Leave it to the static type checker. Our goal here should be to 
support the syntax that PEP 612 describes so static type checkers can implement 
it, not to implement all the requirements described by the PEP at runtime.

I wonder what Pyre has in its stub files for ParamSpec -- maybe we can borrow 
that?

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22593
pull_request: https://github.com/python/cpython/pull/23734

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

STINNER Victor  added the comment:

> a simple test with the tools/freeze/hello.py example was successfull with 
> your patch and the newest cpython from github.

Oh great, thanks for your quick feedback! I applied your PR to master and I 
will backport it to 3.9.

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b5c7b38f5ebbc84b5b80192db1743d3e1cdcf4c5 by Victor Stinner in 
branch 'master':
bpo-42591: Export missing Py_FrozenMain() symbol (GH-23730)
https://github.com/python/cpython/commit/b5c7b38f5ebbc84b5b80192db1743d3e1cdcf4c5


--

___
Python tracker 

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

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

[Om G]

Change by Om G :


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

___
Python tracker 

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

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

[Om G]

New submission from Om G :

During optimization, the compiler deletes blocks that are marked as 
unreachable. In doing so, it can render jump instructions that used to jump 
over the now-deleted blocks redundant, since simply falling through to the next 
non-empty block is now equivalent.

An example of a place where this occurs is around "if condition: statement; 
else: break" style structures (see attached proof of concept code below), but 
this is a general case and could occur in other places.

Tested on the latest 3.10 branch including all recent compile.c changes.

--
files: jmptest.py
messages: 382834
nosy: OmG
priority: normal
severity: normal
status: open
title: Redundant jump instructions due to deleted unreachable bytecode blocks
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49664/jmptest.py

___
Python tracker 

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

[issue41559] Add support for PEP 612 to typing.py

[Ken Jin]

Ken Jin  added the comment:

> and was surprised that C.__parameters__ was (T,) instead of (T, P).
Alright, I just fixed that :).

I'm now encountering many problems with how typing works which prevent what PEP 
612 declare as valid from not throwing an error (these are all examples copied 
from the PEP)::

class X(Generic[T, P]): ...

1. X[int, [int, bool]] raises TypeError because second arg isn't a type (this 
is easy to fix).

2. X[int, ...] raises TypeError because for the same reason. One way to fix 
this is to automatically convert Ellipsis to EllipsisType just like how we 
already convert None to NoneType. Only problem now is that Callable[[...], int] 
doesn't raise TypeError. Should we just defer the problem of validating 
Callable to static type checkers instead?

class Z(Generic[P]): ...

3. Z[[int, str, bool]] raises TypeError, same as 1.

4. Z[int, str, bool] raises TypeError, but for too many parameters (not enough 
TypeVars). This one troubles me the most, current TypeVar substitution checks 
for len(__args__) == len(__parameters__).


I have a feeling your wish of greatly loosening type checks will come true ;). 
Should we proceed with that? That'd fix 1, 2, 3. The only showstopper now is 4. 
A quick idea is to just disable the check for len(__args__) == 
len(__parameters__) if there's only a single ParamSpec in __parameters__.

--

___
Python tracker 

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

[issue30459] PyList_SET_ITEM could be safer

[Petr Viktorin]

Petr Viktorin  added the comment:

> The change respects the documentation which always documented the result type 
> as "void".

Then, IMO, the documentation should be fixed.

> My expectation is that apart py-qt4, no project abuse these 3 macros.

That's not true; at least ALSA's python bindings use PyTuple_SET_ITEM as a 
lvalue as well.

--

___
Python tracker 

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

[issue30459] PyList_SET_ITEM could be safer

[STINNER Victor]

STINNER Victor  added the comment:

I checked: commit 0ef96c2b2a291c9d2d9c0ba42bbc1900a21e65f3 is part of Python 
3.10.0a3 (released 3 days ago).

--

___
Python tracker 

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

[issue30459] PyList_SET_ITEM could be safer

[STINNER Victor]

STINNER Victor  added the comment:

> This change goes directly against PEP 387.

The change respects the documentation which always documented the result type 
as "void".

3.10: https://docs.python.org/dev/c-api/tuple.html#c.PyTuple_SET_ITEM
3.5: https://docs.python.org/3.5/c-api/tuple.html#c.PyTuple_SET_ITEM
2.7: https://docs.python.org/2.7/c-api/tuple.html#c.PyTuple_SET_ITEM

This change is backward incompatible on purpose: it's to implement the 
documented behavior, and the macro was misused leading to a bug: 
"PyList_SET_ITEM (l, i, obj) < 0" in py-qt4.

I would also prefer a deprecation warning, but I don't see how do detect when a 
macro is abused to write "x = SET();" or "SET() = x;" Maybe a C linter could 
detect that, but I don't know any tool doing that.

The best we can do is to announce the change. That's why I documented in What's 
New in Python 3.10, and not only "hidden" in the Changelog:
https://docs.python.org/dev/whatsnew/3.10.html#id2

My expectation is that apart py-qt4, no project abuse these 3 macros.

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[Christian Bachmaier]

Christian Bachmaier  added the comment:

Dear Victor,

a simple test with the tools/freeze/hello.py example was successfull with your 
patch and the newest cpython from github.

1. git clone https://github.com/python/cpython.git
2. Applied a patch of your pull request
3. configure, make, amke install to xxx
4. freeze.py wants wants this for a very long time:
   ln -s /usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu
 /usr/local/lib/python3.10/config-3.10
5. python3 cpython/Tools/freeze.py -o frozen hello.py
6. cd frozen; make; ./hello
   Helo world...

Thanks again,
Chris

--

___
Python tracker 

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

[issue42614] Pathlib does not support a Cyrillic character 'й'

[Mihail Kirilov]

Mihail Kirilov  added the comment:

I am uploading an Archive with

1 - mac.png
Using a mac I cannot generate the other 'й', but I can load the file, it 
exists, but .name is wrong.

2 - linux.png
Using a linux the exact same thing generates the file not existing.

3 - The file itself.

It is very tricky to generate the problem on the mac I can hop on a call with 
you to show you exactly what I do.

--
Added file: https://bugs.python.org/file49663/Archive.zip

___
Python tracker 

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

[issue42614] Pathlib does not support a Cyrillic character 'й'

[Steven D'Aprano]

Steven D'Aprano  added the comment:

In addition, you are probably hitting normalization issues. There are two ways 
to get the Cyrillic character 'й' in your string, one of them is a single code 
point, the other is two code points:

>>> a = 'й'
>>> b = 'й'
>>> len(a), unicodedata.name(a)
(1, 'CYRILLIC SMALL LETTER SHORT I')
>>> len(b), unicodedata.name(b[0]), unicodedata.name(b[1])
(2, 'CYRILLIC SMALL LETTER I', 'COMBINING BREVE')

--

___
Python tracker 

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

[issue42614] Pathlib does not support a Cyrillic character 'й'

[Steven D'Aprano]

Steven D'Aprano  added the comment:

You are comparing the name with the file extension against the name without the 
file extension:

>>> "Файл на български.ldr" == "Файл на български"
False

--
nosy: +steven.daprano

___
Python tracker 

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

[issue30459] PyList_SET_ITEM could be safer

[Petr Viktorin]

Petr Viktorin  added the comment:

This change goes directly against PEP 387.

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue42614] Pathlib does not support a Cyrillic character 'й'

[Ronald Oussoren]

Ronald Oussoren  added the comment:

What platform are you using?

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue42614] Pathlib does not support a Cyrillic character 'й'

[Mihail Kirilov]

New submission from Mihail Kirilov :

I have a file with a Cirilyc name - "Файл на български", which when I load with 
path.Path and call name on it behaves differently

```
(Pdb) 
pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/Файл
 на български.ldr").name
'Файл на български.ldr'
(Pdb) 
pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/Файл
 на български.ldr").name[2]
'и'
(Pdb) 
pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/Файл
 на български.ldr").name == "Файл на български"
False
```

--
components: Unicode
messages: 382823
nosy: ezio.melotti, hidr0.frbg, vstinner
priority: normal
severity: normal
status: open
title: Pathlib does not support a Cyrillic character 'й'
type: crash
versions: Python 3.8

___
Python tracker 

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

[issue42612] Software Designer

[hai shi]

hai shi  added the comment:

Hi, Thanks for your report, Deepanshu. Can you upload your code in here?

Adding victor in this bpo, MAYBE he can give some suggestions about it.

--
nosy: +shihai1991, vstinner

___
Python tracker 

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

[issue42611] PEP 594

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue42613] freeze.py doesn't support sys.platlibdir different than lib nor multiarch

[STINNER Victor]

New submission from STINNER Victor :

Tools/freeze/freeze.py doesn't support config directory using multiarch nor 
directory using a sys.platlibdir different than "lib". In short, it doesn't 
work on Fedora 33 which uses:

/usr/lib64/python3.10/config-3.10-x86_64-linux-gnu/

It might be possible to copy/paste the code creating the config-xxx path from 
Lib/sysconfig.py to Tools/freeze/freeze.py, but I would prefer to reuse code if 
possible, to make the code more sustainable.

Maybe we can add a private function to get the path to the "config" directory.

Or even a public function.

--
components: Unicode
messages: 382821
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: freeze.py doesn't support sys.platlibdir different than lib nor multiarch
versions: Python 3.10

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[Václav Brožek]

Václav Brožek  added the comment:

https://github.com/python/cpython/pull/23729 is now a follow-up to improve docs 
and error message about the assert misspellings.

I'm now looking at the misspelled arguments: autospec and spec_set. These are 
accepted by patch, patch.object and patch.multiple, and spec_set is also 
accepted by create_autospec.

The three frequent misspellings I saw in our codebase are auto_spec, autospect 
and set_spec. I could add a check to look for them in kwargs, and also add an 
"unsafe" argument (default False), which, when True, disables the check. This 
would mimic what is already done for the misspelled asserts.

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

STINNER Victor  added the comment:

I wrote PR 23730 to fix the issue. Would it be possible for you to test it?

Since Python 3.9, symbols which are not explicitly exported are no longer 
exported. Python now uses -fvisibility=hidden.

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
nosy: +vstinner
nosy_count: 1.0 -> 2.0
pull_requests: +22590
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23730

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[Christian Bachmaier]

Christian Bachmaier  added the comment:

The file containing the source code is Python/frozenmain.c .

--

___
Python tracker 

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

[issue42591] Method Py_FrozenMain missing in libpython3.9

[Christian Bachmaier]

Christian Bachmaier  added the comment:

The same under Python 3.9.1 (Package from Debian bullseye/testing). As the 
method Py_FrozenMain is contained in the source code, maybe ist has something 
to do with the build process, a change in makefile? As far as I can see, the 
builder of the distribution packages call the makefile as provided.

Chris

--

___
Python tracker 

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

[issue41877] Check against misspellings of assert etc. in mock

[Václav Brožek]

Change by Václav Brožek :


--
pull_requests: +22589
pull_request: https://github.com/python/cpython/pull/23729

___
Python tracker 

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