[issue39462] DataClass typo-unsafe attribute creation & unexpected behaviour (dataclasses)

2020-01-27 Thread Marcel


New submission from Marcel :

After instantiation of a variable of a DataClass, it is possible to assign new 
attributes (that were not defined in defining the DataClass):

data.new_attribute = 3.0  # does NOT raise Error!

This gives unexpected behaviour: if you print the variable, then 
'new_attribute' is not printed (since it is not in the definition of the 
DataClass).

Assigning to an attribute is therefore not typo-safe (which users may expect 
from a DataClass).

I would expect the behaviour of the DataClass be consistent and typo-safe.

Attached is a file that demonstrates the bug (behaviour) and provides a 
'SafeDataClass' by overriding the __setattr__ method.

My suggestion would be to the adjust the library __setattr__ for the DataClass 
such that is will be typo-safe.

--
components: Library (Lib)
files: bug_demo_dataclass_typo_unsafe.py
messages: 360752
nosy: marcelpvisser
priority: normal
severity: normal
status: open
title: DataClass typo-unsafe attribute creation & unexpected behaviour 
(dataclasses)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48865/bug_demo_dataclass_typo_unsafe.py

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



[issue39462] DataClass typo-unsafe attribute creation & unexpected behaviour (dataclasses)

2020-01-27 Thread Marcel


Marcel  added the comment:

The demo-script also needs:

"from dataclasses import dataclass"

Sorry about this omission, I've attached the update

--
Added file: https://bugs.python.org/file48866/bug_demo_dataclass_typo_unsafe.py

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



[issue46375] io.BytesIO does not have peek()

2022-01-14 Thread Marcel Martin


New submission from Marcel Martin :

It would be great to be able to use peek() on BytesIO objects.

I have a function that gets passed a file-like object and uses peek() on it. 
This works for nearly all types of files relevant in my library, except BytesIO 
instances (which I use during testing), for which I need to add a small 
workaround using tell() and seek().

--
components: Library (Lib)
messages: 410552
nosy: marcelm
priority: normal
severity: normal
status: open
title: io.BytesIO does not have peek()
type: enhancement
versions: Python 3.11

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



[issue46375] io.BytesIO does not have peek()

2022-01-22 Thread Marcel Martin


Change by Marcel Martin :


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

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



[issue46375] io.BytesIO does not have peek()

2022-01-22 Thread Marcel Martin

Marcel Martin  added the comment:

I opened a PR, but I now wonder whether the missing peek() is by design.

First, I noticed that instead of using BytesIO directly, I can wrap the 
instance in an io.BufferedReader, which does have peek(). (It’s just a bit 
inconvenient.)

The second thing is that BytesIO is currently documented to inherit from 
BufferedIOBase, but if peek() is implemented, one could argue that BytesIO now 
should inherit from BufferedReader because it then has all the methods. And 
that seems to great a change from my perspective.

I’ll defer to someone more knowledgeable and do not mind at all if this issue 
is closed without action.

--

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



[issue8096] locale.format_string fails on mapping keys

2010-03-09 Thread Marcel Tschopp

New submission from Marcel Tschopp :

locale.format_string doesn't return same result as a normal "string" % format 
directive, but raises a TypeError.

>>> locale.format_string('%(key)s', {'key': 'Test'})
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.6/locale.py", line 225, in format_string
val[key] = format(perc.group(), val[key], grouping)
  File "/usr/local/lib/python2.6/locale.py", line 182, in format
formatted = percent % value
TypeError: format requires a mapping

--
components: Library (Lib)
messages: 100709
nosy: mtschopp
severity: normal
status: open
title: locale.format_string fails on mapping keys
type: behavior
versions: Python 2.6

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



[issue45387] GzipFile.write should be buffered

2021-10-06 Thread Marcel Martin


Change by Marcel Martin :


--
nosy: +marcelm

___
Python tracker 
<https://bugs.python.org/issue45387>
___
___
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

2019-11-13 Thread Marcel Plch


New submission from Marcel Plch :

Currently, there is not way to access per-module state from the methods of 
types defined in extension modules.

This PEP provides a fix to this issue.

PEP 573 - https://www.python.org/dev/peps/pep-0573/

Reference implementation - 
https://github.com/Dormouse759/cpython/tree/pep-c-rebase_newer

--
components: Extension Modules
messages: 356533
nosy: Dormouse759, ncoghlan, petr.viktorin, scoder, terry.reedy
priority: normal
severity: normal
status: open
title: PEP 573: Module State Access from C Extension Methods
type: enhancement
versions: Python 3.9

___
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



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

2019-11-13 Thread Marcel Plch


Change by Marcel Plch :


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

___
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



[issue38895] performance degradation creating a mock object (by factor 7-8)

2019-11-23 Thread Marcel Zięba

Marcel Zięba  added the comment:

I've also tested it and can confirm it.

Master branch:
raw times: 8.43 sec, 7.26 sec, 8.16 sec, 8.4 sec, 7.31 sec  




  
10 loops, best of 5: 72.6 usec per loop

v3.8.0:
raw times: 13.6 sec, 11.9 sec, 11.6 sec, 11.7 sec, 12.3 sec 




  
10 loops, best of 5: 116 usec per loop 

v3.7.4:
raw times: 2.55 sec, 1.9 sec, 2.7 sec, 2.42 sec, 2.17 sec   




  
10 loops, best of 5: 19 usec per loop

--
nosy: +marseel
versions: +Python 3.9

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



[issue38895] performance degradation creating a mock object (by factor 7-8)

2019-11-23 Thread Marcel Zięba

Marcel Zięba  added the comment:

This is the first commit I've observed slow down:

77b3b7701a34ecf6316469e05b79bb91de2addfa

Especially this part looks suspicious
https://github.com/python/cpython/commit/77b3b7701a34ecf6316469e05b79bb91de2addfa#diff-ff75b1b83c21770847ade91fa5bb2525R366

--

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



[issue38895] performance degradation creating a mock object (by factor 7-8)

2019-11-25 Thread Marcel Zięba

Marcel Zięba  added the comment:

"It seems creating the signature of NonCallableMock.__init__ per mock creation 
is expensive and since it doesn't change can we just create the signature once 
and set it as a module level attribute? There might still be room for some more 
optimisations here to reduce the impact."

This is already done in master branch ;)


"This could be moved to _get_child_mock so that the Mock creation itself for 
all other mocks and common use case is faster. Creating child mocks will have 
the iscoroutine function check performed where maybe we can populate the 
_spec_async list and use it for subsequent calls."

This seems like a reasonable solution.
I've tested it and it improves mock creation speed 2x.

Do you mind if I create PR for it? I would like to start contributing to 
CPython ;)

--

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



[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x

2020-01-28 Thread Marcel Plch


Marcel Plch  added the comment:

Is currently anybody actively working on this? Please, report what you have 
found out, if so.
I'd like to start digging into this tomorrow and possibly avoid any duplicit 
work.

--

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



[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace

2020-02-26 Thread Marcel Plch


New submission from Marcel Plch :

Steps to reproduce:

$ wget https://www.python.org/ftp/python/3.9.0/Python-3.9.0a4.tar.xz
$ tar xvf Python-3.9.0a4.tar.xz
$ cd Python-3.9.0a4
$ ./configure --with-dtrace
$ make -j12
/usr/bin/ld: libpython3.9.a(ceval.o): in function `_PyEval_EvalFrameDefault':
/home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1117: undefined reference 
to `python_function__entry_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1254: 
undefined reference to `python_line_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:3697: 
undefined reference to `python_function__return_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1445: 
undefined reference to `python_line_semaphore'

...

/usr/bin/ld: libpython3.9.a(gcmodule.o):(.note.stapsdt+0x70): undefined 
reference to `python_gc__done_semaphore'
collect2: error: ld returned 1 exit status
make: *** [Makefile:709: Programs/_testembed] Error 1


Additional info:
$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--
components: Build
messages: 362700
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: Python 3.9.0a4 fails to build when configured with --with-dtrace
type: compile error
versions: Python 3.9

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



[issue42173] Drop Solaris support

2020-11-01 Thread Marcel Hofstetter


Change by Marcel Hofstetter :


--
nosy: +jomasoftmarcel

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



[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST

2019-07-19 Thread Marcel Plch


New submission from Marcel Plch :

Problem:
If you want to override CFLAGS by setting EXTRA_CFLAGS, they may have no effect 
if there are contrary flags in the CFLAGS_NODIST variable.

How to reproduce:
make CFLAGS_NODIST="-O2" EXTRA_CFLAGS="-Og"

If you look at GCC arguments, there is -O2 present *after* the -Og flag. This 
means -Og gets ignored.

--
components: Build
messages: 348168
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: EXTRA_CFLAGS get overrided by CFLAGS_NODIST
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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



[issue37631] EXTRA_CFLAGS get overrided by CFLAGS_NODIST

2019-07-22 Thread Marcel Plch


Marcel Plch  added the comment:

I believe you mean this downstream issue: 
https://bugzilla.redhat.com/show_bug.cgi?id=1712977

That issue is but only a consequence of a bad flag handling.
The bad flag handling affects not only test_gdb on that specific architecture, 
but the entire optimization level on all architectures, hence causing 
inconveniences in debugging in general on all architectures. It's a pure chance 
that one test caught this specific case.

It might also cause inconveniences with other use-cases for EXTRA_CFLAGS, as 
they might get overridden by CFLAGS_NODIST.

You can get the erroneous output by running the reproducer. That is:

$./configure
...
$ make CFLAGS_NODIST="-O2" EXTRA_CFLAGS="-Og"
gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
  -Og -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Werror=implicit-function-declaration -O2 
-I./Include/internal  -I. -I./Include-DPy_BUILD_CORE -o Programs/python.o 
./Programs/python.c

-Og from EXTRA_CFLAGS gets overridden by -O2 from CFLAGS_NODIST.

--

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



[issue30974] os.samefile / shutil._samefile: following symlinks

2017-07-20 Thread Marcel Partap

New submission from Marcel Partap:

Don't know whether it should be considered a documentation or behavioral issue, 
but os.samefile calls os.stat() on given files, following symlinks. Does this 
really "test whether two pathnames reference the same actual file"? I'd 
consider os.lstat() more suited for that.

This bites me every time I want to overwrite a symlink with its referenced file 
using ranger.

--
messages: 298708
nosy: eMPee584
priority: normal
severity: normal
status: open
title: os.samefile / shutil._samefile: following symlinks
type: behavior
versions: Python 2.7

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



[issue30403] PEP 547: Running extension modules using -m switch

2017-09-01 Thread Marcel Plch

Marcel Plch added the comment:

Sorry for not responding for so long, I didn't work on Python through the 
summer because of some other matters.

Re-execution of the module is not possible, because there is a check on the C 
level, If you call exec_in_module() on an already initialized module, it'll 
raise ImportError.

Also, because of this check, there is the restriction for py_mod_create. 
"Modules" defining this slot might not be module objects at all, so they might 
not have the module state pointer (which is used to flag if the module was 
initialized).

--

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



[issue30403] PEP 547: Running extension modules using -m switch

2017-09-08 Thread Marcel Plch

Marcel Plch added the comment:

I have made a patch both for cython and cpython implementing a way to use 
Py_mod_create in cython.

Basically module def that specifies a new "Py_mod_cython" slot are excluded 
from the rule of no module creation, so these modules can be executed directly 
even though they specify Py_mod_create.

Is this approach safe or does it make easy for things to go wrong?

cpython - 
https://github.com/Traceur759/cpython/commit/51a7508d176b23dcf3547b970cf7e6a50898aae2

cython - 
https://github.com/Traceur759/cython/commit/2ca706e10f469cd38947eecd8b92c142532b20bc

--

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



[issue30177] pathlib.resolve(strict=False) only includes first child

2017-05-18 Thread Marcel Plch

Changes by Marcel Plch :


--
pull_requests: +1744

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



[issue30403] Running extension modules using -m switch

2017-05-19 Thread Marcel Plch

New submission from Marcel Plch:

Currently the -m switch does not work with extension modules:

$ python3 -m math

/usr/bin/python3: No code object available for math


In order to enable extension modules to behave like Python source modules,
the -m switch should be supported.

Please, see this proof of concept:
https://github.com/Traceur759/cpython/tree/main_c_modules

--
components: Extension Modules
messages: 293954
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: Running extension modules using -m switch
type: enhancement
versions: Python 3.7

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



[issue30403] Running extension modules using -m switch

2017-05-23 Thread Marcel Plch

Changes by Marcel Plch :


--
pull_requests: +1845

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



[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'

2017-05-26 Thread Marcel H

Marcel H added the comment:

I want to see this fixed in python3.x as well, please :) the patch should be 
the same

--
nosy: +Marcel H2
versions: +Python 3.6, Python 3.7

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



[issue19717] resolve() fails when the path doesn't exist

2017-05-28 Thread Marcel Plch

Changes by Marcel Plch :


--
pull_requests: +1930

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



[issue12706] timeout sentinel in ftplib and poplib documentation

2018-01-24 Thread Marcel Widjaja

Change by Marcel Widjaja :


--
pull_requests: +5156
stage: needs patch -> patch review

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



[issue29673] Some gdb macros are broken in 3.6

2018-03-16 Thread Marcel Plch

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +5888
stage:  -> patch review

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



[issue29673] Some gdb macros are broken in 3.6

2018-03-16 Thread Marcel Plch

Marcel Plch  added the comment:

I have created a PR here - https://github.com/python/cpython/pull/6126

The problem was, indeed, change in the code structure. The macro checked for 
presence inside of PyEval_EvalFrame() using address of a neighbouring function.
Also, arguments to PyEval_EvalFrame() were changed, so the macro responsible 
for printing of the frame needed a little tweak.

--
nosy: +Dormouse759

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



[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

2018-05-10 Thread Marcel Plch

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +6441
stage:  -> patch review

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



[issue31862] Port the standard library to PEP 489 multiphase initialization

2017-10-24 Thread Marcel Plch

New submission from Marcel Plch :

PEP 489 introduced multiphase initialization of extension and built-in modules.
Now, almost no module in the standard library supports this feature. This 
should be improved to prepare Python for better testing of subinterpreters.

Many benefits of PEP 489 don't apply to stdlib modules. However, the PEP 
effectively says that by using multi-phase init, the module author "promises" 
that the module is "subinterpreter-friendly" [0]. So, when porting, each module 
should be checked that it e.g. doesn't use mutable process-global state.

I'd like to port stdlib to multi-phase init, starting with the easier modules, 
to:
- get familiar with contributing to CPython,
- check and track which modules are already "subinterpreter-friendly", and
- figure out how and where PEP 489 is lacking (beyond what is discussed in 
the PEP itself).


[0]: 
https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

--
components: Extension Modules
messages: 304914
nosy: Dormouse759, encukou, ncoghlan
priority: normal
severity: normal
status: open
title: Port the standard library to PEP 489 multiphase initialization
type: enhancement
versions: Python 3.7

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



[issue31862] Port the standard library to PEP 489 multiphase initialization

2017-10-24 Thread Marcel Plch

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +4078
stage:  -> patch review

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



[issue31901] atexit callbacks only called for current subinterpreter

2017-10-30 Thread Marcel Plch

New submission from Marcel Plch :

`Py_FinalizeEx()` only executes callbacks from the subinterpreter from which 
Py_FinalizeEx is called.

What is the expected behavior here?
Should the callbacks be specific to individual subinterpreters?

--
components: Extension Modules
messages: 305233
nosy: Dormouse759, encukou, ncoghlan
priority: normal
severity: normal
status: open
title: atexit callbacks only called for current subinterpreter
type: behavior
versions: Python 3.7

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



[issue31901] atexit callbacks should be run at subinterpreter shutdown

2017-11-28 Thread Marcel Plch

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +4527
stage:  -> patch review

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



[issue31901] atexit callbacks should be run at subinterpreter shutdown

2017-12-04 Thread Marcel Plch

Marcel Plch  added the comment:

I created a PR with fix on this issue - 
https://github.com/python/cpython/pull/4611

This makes Py_EndInterpreter() call atexit callbacks for the subinterpreter it 
is destroying.

It doesn't make Py_Finalize() end all subinterpreters, as the current 
implementation of subinterpreters makes it hard to do so. This is the same as 
the current behaviour: you need to end all subinterpreters before calling 
Py_Finalize().

--

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



[issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters.

2017-12-11 Thread Marcel Plch

Marcel Plch  added the comment:

> At a guess, the problem is because in atexit_callfuncs():
> 
>module = PyState_FindModule(&atexitmodule);
>if (module == NULL)
>return;

In #31901, I solved this problem by getiing rid of PyState_FindModule in the 
atexit code, using module state and PEP-489 multiphase initialization.

This needed some changes in the pystate and pylifecycle code, so the specific 
interpreter has a reference to its own atexit module. This way, 
Py_EndInterpreter() is able to call the callbacks for the given interpreter.

See: https://github.com/python/cpython/pull/4611

--

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



[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

2017-12-19 Thread Marcel Plch

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +4821
stage:  -> patch review

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



[issue12706] timeout sentinel in ftplib and poplib documentation

2017-12-29 Thread Marcel Widjaja

Marcel Widjaja  added the comment:

Greg, I wonder if you are planning to submit a PR for your patch? If not, I'm 
plan to take your patch, make some minor adjustment and submit a PR.

--
nosy: +mawidjaj

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



[issue29237] Create enum for pstats sorting options

2017-12-30 Thread Marcel Widjaja

Marcel Widjaja  added the comment:

I'd like to try to work on this one

--
nosy: +mawidjaj

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



[issue29237] Create enum for pstats sorting options

2018-01-04 Thread Marcel Widjaja

Change by Marcel Widjaja :


--
keywords: +patch
pull_requests: +4972
stage: needs patch -> patch review

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



[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

2018-01-09 Thread Marcel Plch

Change by Marcel Plch :


--
pull_requests: +4999

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



[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

2018-01-09 Thread Marcel Plch

Marcel Plch  added the comment:

I have created a PR at https://github.com/python/cpython/pull/5140
It contains documentation, plus, in --with-pydebug mode, it calls m_traverse to 
catch easy cases of not handling the m_state==NULL case early.

--

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



[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

2018-05-28 Thread Marcel Plch

Change by Marcel Plch :


--
pull_requests: +6779

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



[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

2018-06-15 Thread Marcel Plch


Marcel Plch  added the comment:

LTO may break the debug symbols and make GDB unusable.
There is an option, that fixes the issue: to use a -g switch in link flags.
Note that this slows loading of the debug symbols significantly.

I suggest these options as possible approaches:

1) make the configure script include -g in LDFLAGS when --enable-optimizations 
and --with-lto are used

2) same as 1), but only when --with-pydebug is also used.

3) document this problem and make the user aware that this possible fix (-g in 
link flags) exists

--
nosy: +Dormouse759

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



[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

2018-06-15 Thread Marcel Plch


Marcel Plch  added the comment:

Yes, but that is not a fix really in this case.
While it makes the test pass because it 'correctly' prints out unknown objects, 
it makes no real difference when actually debugging. The -g switch at link time 
makes the debug symbols readable and user is able to debug just as usual.

--

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



[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

2018-06-15 Thread Marcel Plch


Marcel Plch  added the comment:

Those -g switches you see there are during compile-time.
For this to work, you need to enable it also during link/time:
./configure --enable-optimizations --with-lto LDFLAGS="-g"

Except for py-bt, you should also try bt. With this link flag enabled, I can 
observe significant slowdown on my machine during the backtrace when using bt 
command (At least when I let the PGO do all the profiling, when compiled with 
the sed edit you posted here, I observe none).

--

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



[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

2018-06-15 Thread Marcel Plch


Change by Marcel Plch :


--
nosy: +petr.viktorin

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



[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

2018-06-18 Thread Marcel Plch


Marcel Plch  added the comment:

The problem is with this function:
static PyObject *
builtin_id(PyModuleDef *self, PyObject *v)
/*[clinic end generated code: output=0aa640785f697f65 input=5a534136419631f4]*/
{
return PyLong_FromVoidPtr(v);
}

It's a one-liner, so the compiler really likes to inline it.

Without the inline optimization, the additional "next" command makes a jump 
into the function.

But when the function is inlined and you set a breakpoint to it, the line is 
just seen as a function from the debugger, that means you already are inside 
and the "next" makes the debugger exit this line, and so the function.

More graphical explanation:
non-inline case:
br
{
next
   return PyLong_FromVoidPtr(v);

inline case:
br
   return PyLong_FromVoidPtr(v);
next
"Some code without access to the func arguments' debug symbols"


I propose two possible solutions:
1) Skip whole test_gdb when optimizations are used (who debugs with them 
anyway?)
2) Conditionalize the "next". (this could be hard as we would need to know when 
the function is inlined)

Also, I have found out that when configured with --with-pydebug and 
--enable-optimizations, tests stop to fail. (the failing bots are configuring 
with --enable-optimizations only)

--

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



[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

2018-06-18 Thread Marcel Plch


Marcel Plch  added the comment:

> It's already done, no? But the title issue is "-mcet -fcf-protection
> -O0" and -O0 disables optimizations.

Some of the simple tests are still run even with optimizations.
Disabled optimizations is what we want, because then the function doesn't get 
inlined --> the 'next' jumps in, not out.

--

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



[issue34097] ZIP does not support timestamps before 1980

2018-07-11 Thread Marcel Plch


Marcel Plch  added the comment:

I'm going to have a closer look at this and try to add the option.

--
nosy: +Dormouse759

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



[issue34097] ZIP does not support timestamps before 1980

2018-07-13 Thread Marcel Plch


Change by Marcel Plch :


--
keywords: +patch
pull_requests: +7805
stage:  -> patch review

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



[issue34097] ZIP does not support timestamps before 1980

2018-07-13 Thread Marcel Plch


Marcel Plch  added the comment:

I have created a PR for this: https://github.com/python/cpython/pull/8270

--

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



[issue34097] ZIP does not support timestamps before 1980

2018-08-02 Thread Marcel Plch


Marcel Plch  added the comment:

It seems reasonable, I'll have a look at it.

--

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



[issue34325] test_zipfile gets OverflowError in multiple buildbots

2018-08-03 Thread Marcel Plch


Change by Marcel Plch :


--
keywords: +patch
pull_requests: +8151
stage:  -> patch review

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



[issue34097] ZIP does not support timestamps before 1980

2018-08-10 Thread Marcel Plch


Change by Marcel Plch :


--
pull_requests: +8209
stage: resolved -> patch review

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



[issue34566] pipe read sometimmes returns EOF but returncode is still None

2018-09-03 Thread Marcel Plch


New submission from Marcel Plch :

TL;DR: For reproducer, please see attached file and the end of this description 
for a runner script.

It seems that when pipe is being read it has a chance of returning EOF and not 
setting the return code.
This bug affects all (or at least a broad set of) architectures and is present 
in all versions. (2.7 and 3.8 were tested).
This bug is not reproducible when configured using --with-pydebug flag.
As a result, any code relying on proper setting of the returncode attribute 
might (and probably is going to) fail.
---
$ for i in $(seq 1 1000); do ./python script.py; done | grep poll | sort | uniq 
-c

Actual output:
630 output: '', return code: 0, pollstatus=0
370 output: '', return code: None, pollstatus=None

Expected output:
1000 output: '', return code: 0, pollstatus=0

--
components: Library (Lib)
files: script.py
messages: 324508
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: pipe read sometimmes returns EOF but returncode is still None
versions: Python 3.8
Added file: https://bugs.python.org/file47782/script.py

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



[issue34566] pipe read sometimes returns EOF but returncode is still None

2018-09-03 Thread Marcel Plch


Marcel Plch  added the comment:

original downstream issue - https://bugzilla.redhat.com/show_bug.cgi?id=1623070

--
title: pipe read sometimmes returns EOF but returncode is still None -> pipe 
read sometimes returns EOF but returncode is still None

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



[issue34566] pipe read sometimes returns EOF but returncode is still None

2018-09-03 Thread Marcel Plch


Change by Marcel Plch :


--
type:  -> behavior

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



[issue18394] cgi.FieldStorage triggers ResourceWarning sometimes

2014-01-12 Thread Marcel Hellkamp

Marcel Hellkamp added the comment:

This change breaks existing applications.

The cgi.FieldStorage.file attribute is public and mentioned in the 
documentation. It even states "You can then read the data at leisure from the 
file attribute".

Consider this example::

form = cgi.FieldStorage()
fileitem = form.getfirst("userfile")
if fileitem and fileitem.file:
executor.submit(store_file, fileitem.file, fileitem.filename)

This code is no longer safe. The garbage collector might close the file handle 
while it is still referenced and accessed from the worker thread.

Another example is the bottle web framework. It uses cgi.FieldStorage for 
parsing only, extracts the valuable information and stores the result in its 
own data structures. The cgi.FieldStorage instance is lost. Python 3.4 breaks 
every single bottle application that works with file uploads.

How about implementing the context manager protocol for cgi.FieldStorage to 
resolve this issue?

--
nosy: +Marcel.Hellkamp

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



[issue9019] wsgiref.headers.Header() does not update headers list it was created with.

2010-06-17 Thread Marcel Hellkamp

New submission from Marcel Hellkamp :

The current (3.x) implementation of wsgiref.headers.Headers() does not match 
the documentation.

Documented behaviour:
"Any changes made to the new Headers object will directly update the headers 
list it was created with." (/Doc/library/wsgiref.rst)

Actual behaviour:
The initial headers list is not updated.

The error was introduced with revision 68205. See 
http://svn.python.org/view/python/branches/py3k/Lib/wsgiref/headers.py?view=diff&r1=68204&r2=68205

Revision 68204::
>>> from wsgiref.headers import Headers
>>> l = []
>>> h = Headers(l)
>>> h.add_header('Test','Test')
>>> l
[('Test', 'Test')]

Revision 68205::
>>> from wsgiref.headers import Headers
>>> l = []
>>> h = Headers(l)
>>> h.add_header('Test','Test')
>>> l
[]

--
components: Library (Lib)
messages: 108042
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: wsgiref.headers.Header() does not update headers list it was created 
with.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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



[issue29589] test_asyncio & test_multiprocessing_forkserver failed

2017-02-21 Thread Marcel Widjaja

Marcel Widjaja added the comment:

Both test_asyncio & test_multiprocessing_forkserver work for me. I'm on the 
latest 3.6 and Mac OS 10.11.6

--
nosy: +mawidjaj

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



[issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte issue.

2016-06-13 Thread Marcel Hellkamp

New submission from Marcel Hellkamp:

Discovered here: https://github.com/bottlepy/bottle/issues/856

If a multipart section has a "Content-Length" header, but no "filename" 
attribute in the "Content-Disposition" header, cgi.FieldStorage tries to write 
binary data to a temporary file opened in text-mode.

The problem here is that cgi.FieldStorage tries to decide if something is a 
binary file-upload or a unicode form-field, but it does so based on two 
different headers in two different places. If the headers contradict each other 
(form-fields usually don't have a Content-Length, file-uploads usually have a 
filename), parsing breaks with a TypeError.

Unfortunately, there are some HTTP client libraries out there that trigger this 
bug.



Here is what happens:

A "Content-Length" header causes `cgi.FieldStorage.length` to be is set (which 
is fine).
https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l550

If `length` has a value, `read_binary()` is used instead of `read_lines()` 
(which is questionable).
https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l733

`read_binary()` calls `make_file()` which creates the buffer file in text mode 
if it does not find a `filename` attribute in the "Content-Disposition" Header 
(which is somewhat okay).
https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l515
https://hg.python.org/cpython/file/3.4/Lib/cgi.py#l893

The bug is triggered if the last two steps disagree on the bytes vs. text 
question.

--
components: Library (Lib)
messages: 268460
nosy: Marcel Hellkamp
priority: normal
severity: normal
status: open
title: Inconsistency in cgi.FieldStorage() causes unicode/byte issue.
type: crash
versions: Python 3.4, Python 3.5

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



[issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError.

2016-06-13 Thread Marcel Hellkamp

Changes by Marcel Hellkamp :


--
title: Inconsistency in cgi.FieldStorage() causes unicode/byte issue. -> 
Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError.

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



[issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError.

2016-06-13 Thread Marcel Hellkamp

Marcel Hellkamp added the comment:

This should fix the issue.

--
keywords: +patch
Added file: http://bugs.python.org/file43378/foo.patch

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



[issue27308] Inconsistency in cgi.FieldStorage() causes unicode/byte TypeError.

2016-06-13 Thread Marcel Hellkamp

Marcel Hellkamp added the comment:

Looks like this is a duplicate to #24764 and already fixed. Sorry for the noise.

--

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



[issue23122] python@93442 breaks build if system Python is 2.6

2014-12-27 Thread Marcel Hellkamp

New submission from Marcel Hellkamp:

On CentOS 6.6 the system Python is 2.6. The use to set literals in 
Parser/adsl.py breaks the build process on these systems. The ./configure 
should ensure that a compatible version of python is available.

--
components: Build
messages: 233134
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: python@93442 breaks build if system Python is 2.6
type: compile error
versions: Python 3.5

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



[issue23122] python@93442 breaks build if system Python is 2.6

2014-12-27 Thread Marcel Hellkamp

Marcel Hellkamp added the comment:

"make touch" solved the problem. A clear case of RTFM :) Sorry for the noise.

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

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