[issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
sebastian added the comment: thank you very much... but: [...] the class and arguments are evaluated using the logging package's namespace. [...] does this mean, it is not possible to use user-defined handlers, naturally residing outside python's class library (and logging package), when applying fileConfig()? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1436> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4028] Problem compiling the multiprocessing module on sunos5
Sebastian added the comment: Yes, it is. I encountered it at Solaris9 with python 2.7.1. -- nosy: +SebaM6 ___ Python tracker <http://bugs.python.org/issue4028> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34350] Non obvious logging handler behaviour
New submission from Sebastian :
In Python 3.6.3 I can do:
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
logger.info("this does not work")
logging.info("PARTY")
logger.info("this works")
And it outputs:
INFO:root:PARTY
INFO:root:this works
The line
logging.info("PARTY")
seems to add a handler which makes the last line work. This is very confusing
behavior as it is not obvious that a call to "logging.info" mutates the state
of the logging subsystem and affects subsequent logging calls.
--
components: Library (Lib)
messages: 323224
nosy: oneofthose
priority: normal
severity: normal
status: open
title: Non obvious logging handler behaviour
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34350>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] PySys_Get
New submission from Sebastian :
Hi all,
I found a bug in the exception handler. When I
start the app without any arguments I get an
output I expect:
__main__:2:DeprecationWarning: Deprecated function.
When I run the app with arguments, the arguments
are printed somehow in the exception output:
-test=HALLO:1:DeprecationWarning: Deprecated function
Can anyone please confirm?
Bye, Seb
[code]
#include "Python/Python.h"
static PyObject *testfunc(PyObject *self, PyObject *args, PyObject *keywords)
{
PyErr_Warn(PyExc_DeprecationWarning, "Deprecated function.");
Py_RETURN_NONE;
}
static PyMethodDef testmod[] =
{
{"testfunc", (PyCFunction)testfunc, METH_NOARGS, "Prints out a text to
stdout."},
{NULL}
};
int main (int argc, char **argv)
{
Py_Initialize();
PySys_SetArgv(argc, argv);
PyObject *mod = Py_InitModule4("testmod", testmod, "", NULL,
PYTHON_API_VERSION);
if(mod == NULL) return -1;
PyRun_SimpleString( "import testmod\n"
"testmod.testfunc()");
Py_Finalize();
return 0;
}
[/code]
--
components: None
messages: 106306
nosy: Sebastian
priority: normal
severity: normal
status: open
title: PySys_Get
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8787>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] PySys_Get
Sebastian added the comment: Could anyone please correct the title? Thx :) -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: Oh, damn. I really forgot the argv filename thing. Nevermind :) But back to topic. __file__ might be not the best solution for that. What does Python when embedded, and __file__ is not set? That can happen when the source of your code is not a file (multiline textbox, ...) I would simply follow the way how the traceback solves this. Just print out the filename passed to: Py_CompileStringFlags(const char *str, const char *filename, int start, PyCompilerFlags *flags) PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit, PyCompilerFlags *flags) [...] -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: attached a patch for this issue now. Now it first uses the name of the script, instead of __file__. -- keywords: +patch Added file: http://bugs.python.org/file17461/_warnings.c.patch ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: any news on this? -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45383] PyType_FromSpec API fails to use metaclass of bases
Sebastian Berg added the comment:
Sorry, I need some time to dive back into this, so some things might be garbled
:). Yes, I do agree supporting a custom `tp_new` here seems incredibly tricky.
I have not thought about the implications of this, though.
> guess the safest option is to fail when the metaclass has a custom tp_new
That would seem OK, but I can't quite judge it. It may mean that I have to do
a custom factory to create new metaclass instances from Python, but that is
probably for the better anyway.
Now, calling `tp_new` is a bit useless, since from C we don't have a dict
anyway (at least not really). So yeah, this does not make sense at all for
most Python defined metaclasses... (they may want to inspect/mutate the dict)
> But at that point, this is duplicating a lot of existing functionality, and
> I'm starting to wonder if this wouldn't all be better with calling the
> metaclass instead.
I do not think I am following :(. My worry is that I want people to create a
MetaClass instance through C (but not be locked into static types forever).
My current thought is that I would like it be possible to do something like:
/* Create a new type object */
type_spec = {stuff};
newtype = PyType_FromSpec(&type_spec);
/* Finalize the MetaClass */
metatype_spec = {more_stuff};
PyArray_InitDTypeFromSpec(newtype, &metatype_spec);
Of course I can move this into a single function and create the class for the
user. But I am uncertain that piping everything through `tp_new` will help?
At some point I thought that the user should create a subclass, and I create
another class inheriting it. But it also seems convoluted and complicated.
I have no idea right now, but maybe there could also be a way to make creating
a metaclass-factory in C easier, rather than supporting `PyType_FromSpec` for
metaclasses.
(I.e. an `PType_InitFromSpec()` doing most of what `PyType_FromSpec` does, but
really meant to be only used be such metaclass factories.)
> - basicsize/itemsize could be allowed with __basicsize__/__itemsize__ in the
> dict.
Do we need this? I need the basicsize of the metaclass, but that of the class
seems fixed/OK?
> - flags: we could add mechanisms to set individual flags after the type is
> created, as needed.
Seems fine, yeah.
> - slots can usually be applied after the class is created; maybe there should
> be a public function for this.
> - members could theoretically be copied to individual descriptors; there
> doesn't seem much need for keeping tp_members around.
But a Python MetaClass (that the author may not even realize about) might need
access to these to work properly?
A bit far fetched, but...
--
___
Python tracker
<https://bugs.python.org/issue45383>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45383] PyType_FromSpec API fails to use metaclass of bases
Sebastian Berg added the comment: It is probably early, but I am starting to like the idea of a "C MetaClass factory" helper/indicator. It seems to me that yes, at least `tp_new` cannot be called reasonable for a class that is created in C, it is just too confusing/awkward to try to push the C stuff _through_ the Python API. (And the Python API is the typical one that should not be inconvenienced) Which gives two possibilities if I want this capability?: 1. Force use of a custom class factory in Python (i.e. not through `__new__`). But that seems hard, since I need to refuse `__new__()`!). 2. Use a class factor in C which never calls `__new__` and knows that this is OK. This is not my turf, so I like unholy, but maybe pragmatic things :). Would a slot/flag indicating `Py_using_metaclass_cinit_pretty_promise_please` "solve" these issues? I mean, we have two ways to create classes (C and Python), I am not sure it is plausible to untangle this on the MetaClass level, so maybe the only way forward is to embrace it: Some Python MetaClasses just can't be instantiated from C, because we don't know it will work. If we want to allow instantiating the MetaClass from C, we need some way to set this up. And either we cannot use `PyType_FromSpec` then, or we need to tell it that we know what we are doing. -- ___ Python tracker <https://bugs.python.org/issue45383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45383] PyType_FromSpec API fails to use metaclass of bases
Sebastian Berg added the comment: Fully, agree! In the end, `PyType_FromSpec` replaces `type.__new__()` (and init I guess) when working in C. In Python, we would call `type.__new__` (maybe via super) from the `metatype.__new__`, but right now, in C, the metatype cannot reliably use `PyType_FromSpec` in its own `metatype.__new__` to do the same. I agree with the scenarios: * If we do not have a custom `metatype.__new__` (init?) then `PyType_FromSpec` should have no reason to refuse doing the work, because nothing can go wrong. * If we do have a custom `tp_new` the user has to provide C API to create the metaclass instance. But they still need a way to call `type.__new__` in C (i.e. get what `PyType_FromSpec` does, and promising to do the rest). `PyType_ApplySpec` would provide that way to create a custom `metatype.__new__` in C when `PyType_FromSpec()` would otherwise reject it to make the first scenario safe. A flag probably can do the same. I have no preference, `ApplySpec` seems great to me. -- ___ Python tracker <https://bugs.python.org/issue45383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45383] PyType_FromSpec API fails to use metaclass of bases
Sebastian Berg added the comment: Well, what we need is a way to say: I am calling `type.__new__` (i.e. PyType_FromSpec) on purpose from (effectively) my own `mytype.__new__`? That is, because right now I assume we want to protect users from calling PyType_FromSpec thinking that it is equivalent to calling `class new(base)` when it may not be if base is a metaclass. So calling `PyType_FromSpec` might refuse to work if it finds a custom `metaclass.__new__` (init?). I don't really see that it matters if we only support effectively this from C: ``` class MyMetaClass(type): def __new__(cls, *args, **kwargs): self = type.__new__(...) # this is PyType_FromSpec # more stuff ``` So, I thought telling `PyType_FromSpec` that we are "inside" a custom `__new__` is sufficient and that even as a flag passed as part of the spec could be enough. But... I agree that I do not quite see that it would be pretty, so it probably was a bad idea :). Plus, if you add a new method it should also solves the issue of setting the `tp_type` slot to the metaclass explicitly when it is not implicit by inheritance (which is the only thing I care about). (PyType_FromSpec and PyType_ApplySpec will still need to do the work of resolving the metaclass from the base classes, though.) -- ___ Python tracker <https://bugs.python.org/issue45383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45383] PyType_FromSpec API fails to use metaclass of bases
Sebastian Berg added the comment: Btw. huge thanks for looking into this! Let me know if I can try to help out (I can make due with static metatypes, but my story seems much clearer if I could say: Well with Py 3.11 you can, and probably should, do it dynamically.). I had lost a lot of time chasing "metaclass should just work" followed by "but I can't get it right without bad hacks". And now the solution seems fairly clear, which is amazing :)! -- ___ Python tracker <https://bugs.python.org/issue45383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters
Change by Sebastian Rittau : -- nosy: +srittau ___ Python tracker <https://bugs.python.org/issue46006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46414] Add typing.reveal_type
Change by Sebastian Rittau : -- nosy: +srittau ___ Python tracker <https://bugs.python.org/issue46414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Possibly bad interaction with tracing and cython?
New submission from Sebastian Berg :
Starting here, but there could be Cython interaction or something else in
theory. But, when running the following:
* Python 3.10.1 (not 3.9.9, debug version or not)
* Setting a tracing function (not setting a trace-function will fix the issue)
* Running Cython (maybe also C code) calling back into Python (the best I can
tell)
It can happen that module globals in the called funtions scope seem to be
modified. Oddly enough to a value used in the locals of that function?!
The pandas issue:
https://github.com/pandas-dev/pandas/issues/41935
has a reproducer (sorry that it takes NumPy and pandas for now). I will paste
it at the end here also.
I can find that the value is modified by the time the `trace` function is
called. No other "trace" triggers are processed before in this example (Cython
calls other functions in NumPy, but all of those are C implemented, so I guess
that is why).
The function in question (unlike all?) should further be called with
`__Pyx_PyFunction_FastCall`, so that is probably an important data point:
Fastcall protocol seems involved.
(Reproducible using NumPy 1.21.5 and Pandas 1.3.5, but except maybe pandas due
to the Cython version, I don't expect version dependency.)
The output of the script is very brief:
Something happened here, `np.core.numeric.dtype IS np.dtype`
call None
The full reproducer script is:
import sys
import numpy as np
import pandas as pd
from numpy.core import numeric
stop = False
def trace(frame, event, arg):
global stop
if stop:
return None
if np.core.numeric.dtype is not np.dtype:
print("Something happened here, `np.core.numeric.dtype IS np.dtype`")
print(frame, event, arg)
stop = True
else:
print(frame, event, arg)
return trace
sys.settrace(trace)
pd._libs.lib.maybe_convert_objects(np.array([None], dtype=object))
For completeness, the Cython code calling the NumPy function in question, is
(likley, there is more, this is Cython, I just cut it out a bit :)):
#if CYTHON_FAST_PYCALL
if (PyFunction_Check(__pyx_t_5)) {
PyObject *__pyx_temp[3] = {__pyx_t_2, __pyx_t_6, Py_False};
__pyx_t_15 = __Pyx_PyFunction_FastCall(__pyx_t_5, __pyx_temp+1-__pyx_t_8,
2+__pyx_t_8); if (unlikely(!__pyx_t_15)) __PYX_ERR(0, 2441, __pyx_L1_error)
__Pyx_XDECREF(__pyx_t_2); __pyx_t_2 = 0;
__Pyx_GOTREF(__pyx_t_15);
__Pyx_DECREF(__pyx_t_6); __pyx_t_6 = 0;
} else
#endif
--
components: Interpreter Core
messages: 411082
nosy: seberg
priority: normal
severity: normal
status: open
title: Possibly bad interaction with tracing and cython?
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Possibly bad interaction with tracing and cython?
Sebastian Berg added the comment:
Ahh, a further data-point. The name from the module scope that is overwritten
IS a parameter name used in the function locals. Strangly, if I modify the
tracing to print more:
stop = 0
def trace(frame, event, arg):
global stop
if stop > 10:
return None
if np.core.numeric.dtype is not np.dtype:
#print("Something happened here, `np.core.numeric.dtype IS np.dtype`")
print(np.core.numeric.dtype)
print(frame, event, arg)
stop += 1
else:
print(frame, event, arg)
return trace
Then what I get is:
None
call None
None
line None
None
line None
None
line None
None
line None
bool
So, upon entering the function, the value is (already) cleared/set to None
(which is correct of course for `dtype=None`) and then while the function runs
storing into the function locals _mutates_ the module global?
For the fact that it keeps changing during the function run, points very
strongly at CPython?
--
___
Python tracker
<https://bugs.python.org/issue46451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46494] Mention typing_extensions in the typing documentation
Sebastian Rittau added the comment: Sounds like a good idea. I would put it into the introduction. I hear it will easily be missed in other sections. Wouldn't a link to PyPI make more sense than a GitHub link? -- ___ Python tracker <https://bugs.python.org/issue46494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Tracing causes module globals to be mutated when calling functions from C
Change by Sebastian Berg : -- title: Possibly bad interaction with tracing and cython? -> Tracing causes module globals to be mutated when calling functions from C ___ Python tracker <https://bugs.python.org/issue46451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Tracing causes module globals to be mutated when calling functions from C
Sebastian Berg added the comment: Thanks for having a look. I have confirmed this is related to Cython (no pandas/NumPy involved) – repro at https://github.com/seberg/bpo46451. What happens under the hood in Cython is probably: https://github.com/cython/cython/blob/master/Cython/Utility/ObjectHandling.c#L2569-L2611 Which generates `PyEval_EvalCodeEx`, and I could not repro with just a `PyObject_FastCallDict`, so I assume Cython is doing something wrong and will open an issue there, but if you have a quick tip as to what might wrong, that could be nice :). Otherwise, will just close this, and may reopen if Cython hits a wall. -- ___ Python tracker <https://bugs.python.org/issue46451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Tracing causes module globals to be mutated when calling functions from C
Change by Sebastian Berg : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Tracing causes module globals to be mutated when calling functions from C
Sebastian Berg added the comment: Not reopening for now, but I will note again that (AFAIK) Cython uses `PyEval_EvalCodeEx`, and the docs say that it is not used internally to CPython anymore. So it seems pretty plausible that the bug is in `PyEval_EvalCodeEx` and not the generated Cython code? -- ___ Python tracker <https://bugs.python.org/issue46451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46451] Tracing causes module globals to be mutated when calling functions from C
Sebastian Berg added the comment: While I have a repro for Python, I think the pre release of cython already fixes it (and I just did not regenerated the C sources when trying, I guess. A `git clean` to the rescue...). -- ___ Python tracker <https://bugs.python.org/issue46451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46609] Generator-based coroutines in Python 3.10 docs
New submission from Sebastian Rittau : Currently, the Python 3.10.2 documentation at https://docs.python.org/3/library/asyncio-task.html?highlight=coroutine#asyncio.coroutine says: "Note: Support for generator-based coroutines is deprecated and is scheduled for removal in Python 3.10." Python 3.10 still has support for those (although it emits a warning), so the note should be updated. -- assignee: docs@python components: Documentation messages: 412352 nosy: docs@python, srittau priority: normal severity: normal status: open title: Generator-based coroutines in Python 3.10 docs versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12998] Memory leak with CTypes Structure
Sebastian Wiesner added the comment: Why should it? After all, you're sort of abusing ctypes by repeatedly creating Struture types over and over again. C structures that you might want to wrap with these types are fixed and known at the time of programming, so there is never a need to create the same Structure type twice. Thus the set of Structure subclasses created during the live-time of a program is both, fixed and small, so there is no need to limit the cache size. -- nosy: +lunar ___ Python tracker <http://bugs.python.org/issue12998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher added the comment: Since the patches are not applicable to Py 3.x and Py 2.7 is stable I'm closing this bug. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12505] python interpreter not handle wildards properly
Sebastian Ramacher added the comment: That is definitely not python's job. That is the duty of your shell and python should never expand that. And it would lead to platform specific behavior as one can see with the following script: import sys import subprocess if __name__ == "__main__": if len(sys.argv) == 1: subprocess.Popen([sys.executable, __file__, "foo", "*"]) else: print sys.argv[1:] With setargv.obj the argument would be expanded on Windows whereas on any other platform it just prints [foo, *]. -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue12505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4028] Problem compiling the multiprocessing module on sunos5
Sebastian M added the comment:
One more thing, as I tried to rebuild whole python I've encountered on
following problem:
building '_multiprocessing' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-IInclude -I./Include -I/usr/local/include
-I/home/malyska/bld/python_sol10/Python-2.7.1/Include
-I/home/malyska/bld/python_sol10/Python-2.7.1 -c
/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.c
-o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o
gcc -shared
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o
build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o
-L/home/malyska/bld/python_sol10/install/lib -L/usr/local/lib -o
build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so: symbol sem_timedwait:
referenced symbol not found
so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see:
elif platform.startswith('sunos5'):
macros = dict(
HAVE_SEM_OPEN=1,
HAVE_FD_TRANSFER=1
)
#HAVE_SEM_TIMEDWAIT=0,
libraries = ['rt']
thanks
--
___
Python tracker
<http://bugs.python.org/issue4028>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12873] 2to3 incorrectly handles multi-line imports from __future__
Changes by Sebastian Wiesner : -- nosy: +lunar ___ Python tracker <http://bugs.python.org/issue12873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12873] 2to3 incorrectly handles multi-line imports from __future__
Sebastian Wiesner added the comment: More precisely, the bug is, that 2to3 refactors the "print()" invocation in "test1.py" though it shouldn't because a "print_function" future import is present at the beginning of "test1.py". The cross-check with "test2.py" shows that this is due to the multi-line future import in "test1.py" because the line-break in the import statement is the only difference between both files. -- ___ Python tracker <http://bugs.python.org/issue12873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12844] Support more than 255 arguments
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue12844> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher added the comment: Any news on that? -- ___ Python tracker <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10467] io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end.
New submission from Sebastian Hagen : io.BytesIO().readinto() does not correctly handle the case of being called on a BytesIO object that has been seeked past the end of its data. It consequently ends up reading into unallocated memory, and (typically?) segfaulting if used in this manner. I've confirmed that this bug exists in the same fashion in 2.6, 2.7, 3.0, 3.1 and 3.2; the following demonstration code works on all of these. Demonstration: >>> import io; b = io.BytesIO(b'bytes'); b.seek(42); b.readinto(bytearray(1)) 42 Segmentation fault I'm attaching a simple patch against r32a3:85355 that fixes this problem. -- components: IO files: bio_readinto_1.patch keywords: patch messages: 121618 nosy: sh priority: normal severity: normal status: open title: io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end. type: crash versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19656/bio_readinto_1.patch ___ Python tracker <http://bugs.python.org/issue10467> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
New submission from Sebastian Spaeth : imaplib's Time2Internaldate returns invalid (as localized) INTERNALDATE strings. Appending a message with such a time string leads to a: 19 BAD Command Argument Error. 11 (for MS Exchange IMAP servers) it returned "26-led-2011 18:23:44 +0100", however: http://tools.ietf.org/html/rfc2060.html defines: date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" so it expects an English date format. imaplib's Time2Internaldate uses time.strftime() to create the final string which uses the current locale, returning things such as: "26-led-2011 18:23:44 +0100" rather than "26-Jan-2011 18:23:44 +0100". For the right thing to do, we would need to set locale.setlocale(locale.LC_TIME, '') to get English formatting or we would need to use some home-grown parser that hardcodes the proper terms. -- components: Library (Lib) messages: 127186 nosy: spaetz priority: normal severity: normal status: open title: imaplib: Time2Internaldate() returns localized strings type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: P.S. To replicate this in ipython: import locale, imaplib locale.setlocale(locale.LC_ALL,'de_CH.utf8') imaplib.Time2Internaldate(220254431) Out[1]: '"24-Dez-1976 06:47:11 +0100"' (Note the German 'Dez' rather than 'Dec') -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: CC'ing lavajoe as he seemed to be busy with some of imaplib's Date stuff the last couple of days. -- nosy: +lavajoe ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: I think I found the issue he mentioned, however it was about the functions taking the local time (rather than UTC), which is fine. The problem is that Time2Internaldate is used for every .append() operation internally, producing invalid dates which are handed to the IMAP server. So in most cases, the IMAP server will silently ignore the time and use the current time (as per IMAP RFC) or it will complain and barf out (as the MS Exchange server rightly does. So this is more than just an inconvenience, it outright prevents intenational users from APPENDing new messages to a server (or silently bodges the message date) as there is no way around using that function... Sorry if this sounds like whining :-) I don't even have a patch handy... -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: > Added file: imaplib_Time2Internaldate_locale_fix.patch The patch looks very good to me and works. I agree that we should be returning a bytearray but this is should not be part of this issue. For all that it's worth: Signed-off-by: Sebastian Spaeth -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
sebastian serrano <[EMAIL PROTECTED]> added the comment: Running with python -O the timing gets a little closer between Lock and RLock. This code won't be easy to improve in performance. The heaviest call is current_thread(), used at lines: 117:me = current_thread() 137:if self.__owner is not current_thread(): and only consist on: 788: def current_thread(): 789: try: 790: return _active[_get_ident()] 791: except KeyError: 792: ##print "current_thread(): no current thread for", _get_ident() 793: return _DummyThread() Simple profiler dump: $../python-trunk/python -O rlock.py time Lock 0.720541000366 time RLock 4.90231084824 44 function calls in 0.982 CPU seconds Ordered by: internal time, call count ncalls tottime percall cumtime percall filename:lineno(function) 100.3040.0000.3900.000 threading.py:116(acquire) 100.2780.0000.3600.000 threading.py:136(release) 10.2320.2320.9820.982 rlock.py:27(testRLock) 200.1680.0000.1680.000 threading.py:788(current_thread) 10.0000.0000.0000.000 threading.py:103(__init__) 10.0000.0000.0000.000 threading.py:98(RLock) 10.0000.0000.0000.000 threading.py:76(__init__) 00.000 0.000 profile:0(profiler) -- nosy: +sserrano ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4163] textwrap wordsep_re Unicode
New submission from Sebastian Kirsche <[EMAIL PROTECTED]>: The attached patch makes textwrap work with strings containing dashes and Unicode alphabetic characters. In addition, it fixes the test case for issue 1149508, which no longer failed after temporarily undoing the corresponding change. Example 1: print textwrap.fill(u'Die Empfänger-Auswahl', 13) Output without patch: Die Empf änger-Auswahl With patch: Die Empfänger- Auswahl Example 2: print textwrap.fill(u'aa ää-ää', 7) Output without patch: aa ää-ää With patch: aa ää- ää -- components: Library (Lib) files: textwrap-umlauts.patch keywords: patch messages: 75037 nosy: skirsche severity: normal status: open title: textwrap wordsep_re Unicode type: behavior versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file11848/textwrap-umlauts.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher <[EMAIL PROTECTED]> added the comment: At least a response, finally. > * Any reason why PySys_SetPath(char *) is left out? I guess it I just missed it. > * Same for PySys_SetArgv(int, char **) That one is non-trivial and requires some rewriting of PySys_SetArgv. And I didn't have the time to look into it any further. I attached an updated patch. Added file: http://bugs.python.org/file11999/sysmodule_const_char_r67215.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4411] __mro__ documentation
New submission from Sebastian Wiesner <[EMAIL PROTECTED]>: The documentation of Python 2.6 and 2.7 only mentions the class attribute "__mro__" in ABC documentation and in Data model documentation when explaining description invocation (see search results: http://docs.python.org/dev/search.html?q=__mro__&check_keywords=yes&area=default) Imho __mro__ lacks documentation in "Standard Type Hierachy", where special attributes of fundamental data types are documented. -- assignee: georg.brandl components: Documentation messages: 76355 nosy: georg.brandl, lunar severity: normal status: open title: __mro__ documentation versions: Python 2.7 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
New submission from Sebastian Rittau <[EMAIL PROTECTED]>: The attached patch removes all instances of the deprecated "apply" function from distutils and thereby fixes warnings when run with -3. -- components: Distutils files: distutils.diff keywords: patch messages: 77233 nosy: srittau severity: normal status: open title: distutils: -3 warnings (apply) versions: Python 2.6 Added file: http://bugs.python.org/file12263/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
Sebastian Rittau <[EMAIL PROTECTED]> added the comment: Oops, missed a closing parenthesis. Added file: http://bugs.python.org/file12264/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
Changes by Sebastian Rittau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file12263/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4578] compiler: -3 warnings
New submission from Sebastian Rittau <[EMAIL PROTECTED]>: The attached patch replaces all instances of "x.has_key(k)" method calls by "k in x". It also replaces one call to parser.ast2tuple by parser.st2tuple. This removes deprecation warnings when running in -3 mode. -- components: Library (Lib) files: compiler.diff keywords: patch messages: 77238 nosy: srittau severity: normal status: open title: compiler: -3 warnings versions: Python 2.6 Added file: http://bugs.python.org/file12266/compiler.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4578] compiler: -3 warnings
Sebastian Rittau <[EMAIL PROTECTED]> added the comment: I'd like to see this fixed, just to decrease the amount of warning spam I get when testing my own packages. It seems that one of my dependecies that I have no control over is pulling this in. Adding a warning when this module is important seems like a good idea, though. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Sebastian Rittau added the comment: A timedelta.toseconds method (or equivalent) makes no sense. The number of seconds in a day is not fixed (due to leap seconds) and relying on such a method would introduce subtle bugs. The only way to find out the number of seconds in a range of dates is if you have a concrete date range. -- nosy: +srittau ___ Python tracker <http://bugs.python.org/issue1673409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2155] optparse.OptionGroup with_statement context handling
Sebastian Rittau added the comment: This API is too "magical" to my liking and doesn't really reflect what context manager's are supposed to do, i.e. handling resources. Also, I don't see much advantage over: group = OptionGroup(parser, "Group name") group.add_option(...) parser.add_option_group(group) Finally, the __exit__ handler adds the option group to the parser in any case, whether there was an exception raised inside the block or not. -- nosy: +srittau ___ Python tracker <http://bugs.python.org/issue2155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Sebastian Rittau added the comment:
Leap second handling is usually configurable. Default on Debian Linux
(but similar on RHEL and SuSE):
>>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s"))
31536000
After doing "cp /usr/share/zoneinfo/right/Europe/Berlin /etc/localtime":
>>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s"))
31536001
Also, NTP servers usually get this right. I don't think, Python should
promote a wrong date handling by default, even if it's convenient.
___
Python tracker
<http://bugs.python.org/issue1673409>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4949] Constness in PyErr_NewException
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue4949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47082] No protection: `import numpy` in two different threads can lead to race-condition
Sebastian Berg added the comment: To add to this: it would seem to me that the side-effects of importing should be guaranteed to only be called once? However, IO or other operations could be part of the import side-effects and release the GIL. So even a simple, pure-Python, package could run into this same issue and probably won't even realize that they can run into it. (Assuming I understand how this is happening correctly.) So it would seem to me that either: * Python should lock on the thread level or maybe the `sys.modules` dictionary? * The `threading` module could somehow ensure safety by hooking into the import machinery? * Packages that may release the GIL or have side-effects that must only be run once have to lock (i.e. NumPy). (But it seems to me that many packages will not even be aware of possible issues.) -- nosy: +seberg ___ Python tracker <https://bugs.python.org/issue47082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47082] No protection: `import numpy` in two different threads can lead to race-condition
Sebastian Berg added the comment:
Thanks, so there should already be a lock in place (sorry, I missed that). But
somehow we seem to get around it?
Do you know what may cause the locking logic to fail in this case? Recursive
imports in NumPy itself? Or Cython using low-level C-API?
I.e. can you think of something to investigate that may help NumPy/Cython to
make sure that locking is successful?
/* Cythons Import code (slightly cleaned up for Python 3 only): */
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list, int level) {
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
{
if (level == -1) {
if ((1) && (strchr(__Pyx_MODULE_NAME, '.'))) {
module = PyImport_ImportModuleLevelObject(
name, global_dict, empty_dict, list, 1);
if (!module) {
if (!PyErr_ExceptionMatches(PyExc_ImportError))
goto bad;
PyErr_Clear();
}
}
level = 0;
}
if (!module) {
module = PyImport_ImportModuleLevelObject(
name, global_dict, empty_dict, list, level);
}
}
bad:
Py_XDECREF(empty_list);
Py_XDECREF(empty_dict);
return module;
}
--
___
Python tracker
<https://bugs.python.org/issue47082>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42012] typing support in wsgiref
Change by Sebastian Rittau : -- keywords: +patch pull_requests: +30392 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32335 ___ Python tracker <https://bugs.python.org/issue42012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37980] regression when passing numpy bools to sorted(..., reverse=r)
Change by Sebastian Berg : -- nosy: +seberg ___ Python tracker <https://bugs.python.org/issue37980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37980] regression when passing numpy bools to sorted(..., reverse=r)
Sebastian Berg added the comment: I applaud the stricter rules in general, as Mark noted nicely, the issue is that `__index__` is maybe a strange way to achieve that for bools (it is not like `123` is a clean bool)? `__nonzero__` coerces to bools, there is no `__bool__` to convert to bool safely. Basically: this seems to force numpy to back down from saying that `list[np.True_]` will be invalid in the future. (And we cannot just get rid of our bools unfortunately). -- ___ Python tracker <https://bugs.python.org/issue37980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38258] ctypes ignores when a DLL function is called with too many arguments
New submission from Sebastian Ernst :
A c-function with the following signature ...
```C
int16_t __stdcall __declspec(dllimport) square_int(
int16_t a
);
```
... is being called with ctypes:
```python
def test_error_callargs_unconfigured_too_many_args():
dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
square_int = dll.square_int
with pytest.raises(ValueError):
a = square_int(1, 2, 3)
```
Expected result: If the function is called with too many (positional) arguments
(in the example 3 instead of 1), a `ValueError` should be raised. This is the
case for at least CPython 3.4 to 3.7.
Actual result: "Nothing", i.e. no exception. The described test "fails". The
function is called without an error - with CPython 3.8.0b4.
If this behavior is intended, is has not been (as far as I can tell) documented.
--
components: ctypes
messages: 353021
nosy: smernst
priority: normal
severity: normal
status: open
title: ctypes ignores when a DLL function is called with too many arguments
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38258] ctypes ignores when a DLL function is called with too many arguments
Sebastian Ernst added the comment:
Thanks a lot for the clarification, Eryk. I did not notice that it was
deprecated behavior.
For the "too many arguments" case I guess this is not an issue. However, just
for the symmetry of things, I also looked at calling a function with TOO FEW
arguments.
```C
int16_t __stdcall __declspec(dllimport) mul_ints(
int16_t a,
int16_t b
)
{
return a * b;
}
```
```python
def test_error_callargs_unconfigured_too_few_args():
dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
mul_ints = dll.mul_ints
with pytest.raises(ValueError):
a = mul_ints(7)
```
As expected after your explanation, also no error in CPython 3.8 (i.e. the test
fails, while is passes on CPython <= 3.7). If I run this manually, I even get a
"result":
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> a = mul_ints(7)
>>> a
445564 # !
>>> 445564/7 # Just looking at where this result is coming from ...
63652.0
```
Re-starting Python (3.8) and (intentionally) misconfiguring the function
interestingly also does not change the result:
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> mul_ints.argtypes = (ctypes.c_int16,)
>>> a = mul_ints(7)
>>> a
445564 # Apparently, this is deterministic?!?
```
Just out of curiosity, where is this data coming from?
This ONLY way to prevent things like this to happen is to actually correctly
configure the function:
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> mul_ints.argtypes = (ctypes.c_int16, ctypes.c_int16)
>>> mul_ints(7)
Traceback (most recent call last):
File "", line 1, in
TypeError: this function takes 2 arguments (1 given)
```
This should very CLEARLY be mentioned in the documentation ...
--
___
Python tracker
<https://bugs.python.org/issue38258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38450] 3.8 Release Notes: IDLE section dupe
New submission from Sebastian Rittau : In the 3.8 release notes (https://docs.python.org/3.8/whatsnew/3.8.html), the section "IDLE and idlelib" is duplicated as "idlelib and IDLE". Also, the section "gc" and "gzip" between them are not sorted alphabetically like the rest of the list. -- assignee: docs@python components: Documentation messages: 354464 nosy: docs@python, srittau priority: normal severity: normal status: open title: 3.8 Release Notes: IDLE section dupe versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38460] 3.8 Release Notes: document asyncio exception changes
New submission from Sebastian Rittau : In Python 3.8 asyncio exceptions were consolidated into the new module "asyncio.exceptions". Previously they were spread out over several modules. While the documentation always mandated to import the exceptions from top-level "asyncio", code that incorrectly imported directly from the submodules will break. -- assignee: docs@python components: Documentation messages: 354577 nosy: docs@python, srittau priority: normal severity: normal status: open title: 3.8 Release Notes: document asyncio exception changes versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38461] 3.8 Release Notes: "curses" misspelled as "ncurses"
New submission from Sebastian Rittau : The "curses" module is misspelled and sorted as "ncurses" in the release notes. -- messages: 354579 nosy: srittau priority: normal severity: normal status: open title: 3.8 Release Notes: "curses" misspelled as "ncurses" ___ Python tracker <https://bugs.python.org/issue38461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38463] 3.8 Release Notes: Link to SSLContext.post_handshake_auth missing
New submission from Sebastian Rittau : The link to SSLContext.post_handshake_auth in the "ssl" section in the release notes is missing. -- assignee: docs@python components: Documentation messages: 354582 nosy: docs@python, srittau priority: normal severity: normal status: open title: 3.8 Release Notes: Link to SSLContext.post_handshake_auth missing versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38464] documentation for NormalDist.quantiles(): missing argument
New submission from Sebastian Rittau : The documentation for NormalDist.quantiles() (https://docs.python.org/3.8/library/statistics.html#statistics.NormalDist) is missing the "n" argument from the definition. -- assignee: docs@python components: Documentation messages: 354584 nosy: docs@python, rhettinger, srittau priority: normal severity: normal status: open title: documentation for NormalDist.quantiles(): missing argument versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38466] threading.excepthook doc talks about "object"
New submission from Sebastian Rittau : The documentation of threading.excepthook (https://docs.python.org/3.8/library/threading.html#threading.excepthook) talks about "object", when it only has a "thread" attribute: "Storing object using a custom hook can resurrect it if it is set to an object which is being finalized. Avoid storing object after the custom hook completes to avoid resurrecting objects." I believe this is a copy and paste error from sys.unraisablehook. -- assignee: docs@python components: Documentation messages: 354588 nosy: docs@python, srittau, vstinner priority: normal severity: normal status: open title: threading.excepthook doc talks about "object" versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38467] Misspelled argument names for typing.get_origin and get_args
New submission from Sebastian Rittau : The arguments for typing.get_origin() and typing.get_args() are named "typ" in the documentation (https://docs.python.org/3.8/library/typing.html#typing.get_origin), while they are named "tp" in the implementation. Important if used as keyword argument. -- assignee: docs@python components: Documentation messages: 354590 nosy: docs@python, srittau priority: normal severity: normal status: open title: Misspelled argument names for typing.get_origin and get_args versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38467] Misspelled argument names for typing.get_origin and get_args
Change by Sebastian Rittau : -- keywords: +patch pull_requests: +16326 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16753 ___ Python tracker <https://bugs.python.org/issue38467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38467] Misspelled argument names for typing.get_origin and get_args
Sebastian Rittau added the comment: https://github.com/python/cpython/pull/16753 -- ___ Python tracker <https://bugs.python.org/issue38467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38484] HTMLParser.handle_starttag should mention that value can be None
New submission from Sebastian Rittau : The documentation for HTMLParser.handle_starttag (https://docs.python.org/3/library/html.parser.html#html.parser.HTMLParser.handle_starttag) should mention that the value of an attribute can be `None` for argument-less attributes. I can submit a PR if wanted. -- assignee: docs@python components: Documentation messages: 354719 nosy: docs@python, srittau priority: normal severity: normal status: open title: HTMLParser.handle_starttag should mention that value can be None versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38460] 3.8 Release Notes: document asyncio exception changes
Sebastian Rittau added the comment: Also it seems there are various new arguments and methods in asyncio that are not in the release notes. (Via https://github.com/python/typeshed/issues/2313). -- ___ Python tracker <https://bugs.python.org/issue38460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38627] Add copy() method to pathlib
New submission from Sebastian Linke :
pathlib.Path() could wrap shutil.copy() with something like this:
def copy(self, target):
if not self.is_file():
# No support for directories here
raise ValueError("Path must point to a regular file")
# copy() appends filename when Path is copied to a directory
# see shutil.copy() docstring and source for details
target = shutil.copy(self, target)
return self.__class__(target)
--
components: Library (Lib)
messages: 355616
nosy: seblin
priority: normal
severity: normal
status: open
title: Add copy() method to pathlib
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue38627>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38627] Add copy() method to pathlib
Sebastian Linke added the comment: Docstring could be: Copy file content and permission bits of this path to the target path and return a new Path instance pointing to the target path. If target is a directory, the base filename of this path is added to the target and a new file corresponding to the target is created. If target points to an existing file, that file is overwritten. -- ___ Python tracker <https://bugs.python.org/issue38627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43608] `bytes_concat` and Buffer cleanup
New submission from Sebastian Berg :
`pybytes_concate` currently uses the following code to get the data:
va.len = -1;
vb.len = -1;
if (PyObject_GetBuffer(a, &va, PyBUF_SIMPLE) != 0 ||
PyObject_GetBuffer(b, &vb, PyBUF_SIMPLE) != 0) {
PyErr_Format(PyExc_TypeError, "can't concat %.100s to %.100s",
Py_TYPE(b)->tp_name, Py_TYPE(a)->tp_name);
goto done;
}
I don't actually know if it is realistically possible to issues here (I ended
up here by chasing the wrong thing). But this (and the identical code in
`bytearray`) strictly rely on `view->len` not being modified on error (or else
may not clean `va`)!
That seems wrong to me? Although, I now saw that `PyBuffer_GetBuffer` says:
If the exporter cannot provide a buffer of the exact type, it MUST raise
PyExc_BufferError, set view->obj to NULL and return -1.
Pretty much all code in NumPy (and cpython as far as I can tell), will
guarantee that `obj` (and `len` probably) is untouched on error, but it will
not set it to NULL!
I can see some wisdom in NULL'ing `view->obj` since it means the caller can
call `PyBuffer_Release` unconditionally (but then we have to explicitly do
that!). But realistically, it seems to me the realistic thing is to say that a
caller must never release an unexported buffer and make no assumption about its
content?
(Which doesn't mean I won't ensure NumPy will keep `len` and `obj` unmodified
or NULL `obj` on error.)
--
components: C API
messages: 389428
nosy: seberg
priority: normal
severity: normal
status: open
title: `bytes_concat` and Buffer cleanup
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43608>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43965] dataclasses.replace breaks when __init__ is overrriden in subclass
New submission from Sebastian Speitel : from dataclasses import dataclass, replace @dataclass() class A: a: int class B(A): def __init__(self): super().__init__(a=1) obj1 = B() obj2 = replace(obj1, a=2) File "/usr/lib/python3.9/dataclasses.py", line 1284, in replace return obj.__class__(**changes) TypeError: __init__() got an unexpected keyword argument 'a' When a class extends a dataclass and overrides `__init__`, `replace` still accepts it as a dataclass according to the PEP but fails at constructing, since the `__init__`-signature doesn't match anymore. -- components: Library (Lib) messages: 392174 nosy: SebastianSpeitel priority: normal severity: normal status: open title: dataclasses.replace breaks when __init__ is overrriden in subclass type: behavior versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43965] dataclasses.replace breaks when __init__ is overrriden in subclass
Sebastian Speitel added the comment: One solution I thought of was to return not an object of the same instance, but one of the same dataclass, which would allow the implementation to traverse the class hierachy of the object and create an instance of the first dataclass-class (or class with same __init__ signature) it finds with the changes applied. This would at least allow using replace instead of it just failing in more cases. But according to the PEP > Creates a new object of the same type of [the] instance the returned object has to have the same type. -- ___ Python tracker <https://bugs.python.org/issue43965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43965] dataclasses.replace breaks when __init__ is overrriden in subclass
Sebastian Speitel added the comment: Or maybe a cls argument which defaults to obj.__class__? -- ___ Python tracker <https://bugs.python.org/issue43965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Change by Sebastian Rittau : -- nosy: +srittau ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Change by Sebastian Rittau : -- keywords: +patch pull_requests: +24757 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26113 ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35089] Remove typing.io and typing.re from documentation
Change by Sebastian Rittau : -- pull_requests: +24758 pull_request: https://github.com/python/cpython/pull/26113 ___ Python tracker <https://bugs.python.org/issue35089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment: I opened a PR to remove their mention from the docs for now. I can look into how to add a deprecation warning to a module if no one else beats me to it. -- ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44261] SocketType documentation misleading
New submission from Sebastian Rittau : The documentation of socket.SocketType (https://docs.python.org/3/library/socket.html?highlight=sockettype#socket.SocketType) is misleading. It states: This is a Python type object that represents the socket object type. It is the same as type(socket(...)). This is untrue. socket.SocketType is in reality re-exported from _socket, where it is an alias for class _socket.socket, a super type of class socket.socket. I think that either the documentation should be fixed, or SocketType should be moved to socket and made an alias of socket.socket. -- assignee: docs@python components: Documentation messages: 394665 nosy: docs@python, srittau priority: normal severity: normal status: open title: SocketType documentation misleading ___ Python tracker <https://bugs.python.org/issue44261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38460] 3.8 Release Notes: document asyncio exception changes
Change by Sebastian Rittau : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue38460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38460] 3.8 Release Notes: document asyncio exception changes
Sebastian Rittau added the comment: Closing per the comments by Andrew and Raymond and the fact that 3.8 has been released for quite some while now. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Change by Sebastian Rittau : -- pull_requests: +25307 pull_request: https://github.com/python/cpython/pull/26719 ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment: And I opened a second PR (for Python 3.11 only) to issue a deprecation warning when typing.io or typing.re gets imported. -- ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment: Thank you for fixing this, Ken, the PR looks good to me. Overall it looks as if the the Azure pipeline should be fixed, though. It's not ideal that the tests pass while running the PR, but not in other situations. Also, the warnings suppression is not really obvious. -- ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment: Ken: We still need to remove these modules in Python 3.12+. Should we open a separate issue, reopen this one, or just handle it after the Python 3.11 branch has been created? -- ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment:
We could easily do what Ken did in PR-26811, and add
"warnings.filterwarnings("default", category=DeprecationWarning)" to the test,
but I would like to understand what is going on first. It seems the warnings
are generated by test_builtin_with_more_than_four_children, which doesn't
operate on typing directly. Here is a repro, without tests:
srittau@blitz:~/Projekte/cpython (typing-io *)$ ./python -Wall
Python 3.11.0a0 (heads/main:17f94e2888, Jul 5 2021, 19:19:04) [GCC 8.3.0] on
linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> import typing
>>> doc = pydoc.TextDoc()
>>> x = doc.docclass(object)
/home/srittau/Projekte/cpython/Lib/pydoc.py:1344: DeprecationWarning: typing.io
is deprecated, import directly from typing instead. typing.io will be removed
in Python 3.12.
if not cls.__name__.startswith("_") and cls.__module__ == "builtins"),
/home/srittau/Projekte/cpython/Lib/pydoc.py:1344: DeprecationWarning: typing.re
is deprecated, import directly from typing instead. typing.re will be removed
in Python 3.12.
if not cls.__name__.startswith("_") and cls.__module__ == "builtins"),
>>>
Same warning when calling "help(object)". This is not great. I assume that it
is somehow related to pydoc.docclass() iterating over the the items of typing,
but only if typing was imported. Please not that "io" and "re" are not part of
typing.__all__.
I will investigate more.
--
___
Python tracker
<https://bugs.python.org/issue38291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Change by Sebastian Rittau : -- pull_requests: +25599 pull_request: https://github.com/python/cpython/pull/27039 ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment:
pr-27039 suppresses warnings when accessing `typing.{re,io}.__module__`, which
should fix this warning.
--
___
Python tracker
<https://bugs.python.org/issue38291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Sebastian Rittau added the comment: typing.io is not referenced in either the tests or the implementation for pydoc. What happens is basically: typing.io is a class, so its derived from object. When formatting the docstring for object, the formatter queries the __module__ attribute of all sub-classes of object, including typing.io, so that it can include the sub-classes in its output: -- Help on class object in module builtins: class object | The base class of the class hierarchy. | | When called, it accepts no arguments and returns a new featureless | instance that has no instance attributes and cannot be given any. | | Built-in subclasses: | anext_awaitable | async_generator | async_generator_asend | async_generator_athrow | ... and 88 other subclasses | [...] -- Before the PR this failed, as accessing any typing.io.__module__ printed the warning. -- ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12178] csv writer doesn't escape escapechar
Sebastian Bank added the comment:
Thanks Tal.
AFAICT there was an undocumented change in behaviour related to this fix.
Python 3.9 quotes values with escapechar:
```
import csv
import io
kwargs = {'escapechar': '\\'}
value = 'spam\\eggs'
print(value)
with io.StringIO() as buf:
writer = csv.writer(buf, **kwargs)
writer.writerow([value])
line = buf.getvalue()
print(line.strip())
with io.StringIO(line) as buf:
reader = csv.reader(buf, **kwargs)
(new_value,), = reader
print(new_value)
spam\eggs
"spam\eggs"
spameggs
```
- quotes escapechar
- fails to double the escapechar (this bug)
Btw, from
https://docs.python.org/3/library/csv.html#csv.QUOTE_MINIMAL
> only quote those fields which contain special characters
> such as delimiter, quotechar or any of the characters in lineterminator.
this seems incorrect because escapechar is not mentioned (but at the same time
it says 'such as') and maybe better matching the name 'minimal' (or one might
expect 'more' quoting as a better default).
Python 3.10:
https://github.com/python/cpython/blob/5c0eed7375fdd791cc5e19ceabfab4170ad44062/Lib/test/test_csv.py#L207-L208
See also https://github.com/xflr6/csv23/actions/runs/1027687524
--
___
Python tracker
<https://bugs.python.org/issue12178>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38291] Deprecate the typing.io and typing.re pseudo-modules
Change by Sebastian Rittau : -- pull_requests: +25857 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/27312 ___ Python tracker <https://bugs.python.org/issue38291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44809] Changelog missing removal of StrEnum etc.
New submission from Sebastian Rittau : It seems that at some point StrEnum and a few other members were added to Python 3.10. I think they were present in 3.10 beta 2, but it seems they were removed by beta 4. While the Changelog at https://docs.python.org/3.10/whatsnew/changelog.html mentions that they were added, there is no note about their removal again. -- assignee: docs@python components: Documentation messages: 398760 nosy: docs@python, srittau priority: normal severity: normal status: open title: Changelog missing removal of StrEnum etc. versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44809> ___ ___ 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
Sebastian Berg added the comment: The fix broke NumPy (see also https://github.com/numpy/numpy/pull/19612) It seems incorrect. After all, it doesn't matter much whether the float can be converted to an integer correctly (or even if it returns an undefined value), so long `int_value == float_value` remains sensible. The old cast cast integers to complex when they were out of range (which is fine), the new code raises an error instead. -- nosy: +seberg ___ Python tracker <https://bugs.python.org/issue44698> ___ ___ 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
Sebastian Berg added the comment: Hmm, sorry, I overshot/misread :(. The thing that the NumPy test-suite trips over is that: c_powi(inf+0j, 3) seems to not raise, but: _Py_c_pow(inf+0j, 3.+0j) (or nan+0.j rather then inf+0j) does seem to raise (returning `nan+nanj` in both cases). If this is the `inf` code path, raising an error may actually be fix and the integer code path should maybe also do it. -- ___ Python tracker <https://bugs.python.org/issue44698> ___ ___ 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
Sebastian Berg added the comment: (Sorry for the spam. I think we can/should just hard-code the expected values in the NumPy test-suite. So this is not actually an issue for NumPy and probably just warrants a double-check that the behaviour change is desirable.) -- ___ Python tracker <https://bugs.python.org/issue44698> ___ ___ 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
Sebastian Berg added the comment: Thanks for looking into it! `cpow` is indeed complicated. We had some discussion in NumPy about `0**y` branch cuts (I did yet not finish it, because thinking about the branch cuts is tricky). It is almost reassuring that the C standard also hedges out :). Although, it means that there is no reliance on math libraries if we want to treat the special cases more carefully :(. -- ___ Python tracker <https://bugs.python.org/issue44698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44861] csv.writer stopped to quote values with escapechar with csv.QUOTE_MINIMAL in Python 3.10
New submission from Sebastian Bank :
AFAICT there was an undocumented change in behaviour related to the fix of
https://bugs.python.org/issue12178 (also reported in
https://bugs.python.org/issue12178#msg397440):
Python 3.9 quotes values with escapechar:
```
import csv
import io
kwargs = {'escapechar': '\\'}
value = 'spam\\eggs'
print(value)
with io.StringIO() as buf:
writer = csv.writer(buf, **kwargs)
writer.writerow([value])
line = buf.getvalue()
print(line.strip())
with io.StringIO(line) as buf:
reader = csv.reader(buf, **kwargs)
(new_value,), = reader
print(new_value)
spam\eggs
"spam\eggs"
spameggs
```
- quotes escapechar
- fails to double the escapechar (https://bugs.python.org/issue12178)
>From https://docs.python.org/3/library/csv.html#csv.QUOTE_MINIMAL
> only quote those fields which contain special characters
> such as delimiter, quotechar or any of the characters in
> lineterminator.
The previous behaviour seems incorrect because escapechar is not explicitly
mentioned, but at the same time the docs says 'such as'.
The new might better matching the name 'minimal', but at the same time one
might regard 'quote when in doubt' as a safer behaviour for the default quoting
rule.
Python 3.10:
https://github.com/python/cpython/blob/5c0eed7375fdd791cc5e19ceabfab4170ad44062/Lib/test/test_csv.py#L207-L208
See also https://github.com/xflr6/csv23/actions/runs/1027687524
--
components: Library (Lib)
messages: 399188
nosy: ebreck, taleinat, xflr6
priority: normal
severity: normal
status: open
title: csv.writer stopped to quote values with escapechar with
csv.QUOTE_MINIMAL in Python 3.10
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44861>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44861] csv.writer stopped to quote values with escapechar with csv.QUOTE_MINIMAL in Python 3.10
Sebastian Bank added the comment: IIUC there is no way to work around this from client/downstream code (to get the olf 3.6 to 3.9 behaviour), so this might break assertions on the output of `csv.writer` for users of `escapechar` whenever the data to be written contains the escapcechar (e.g. calculating a hash/checksum). -- ___ Python tracker <https://bugs.python.org/issue44861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44861] csv.writer stopped to quote values with escapechar with csv.QUOTE_MINIMAL in Python 3.10
Sebastian Bank added the comment: The 3.9 behaviour is write: "spam\eggs" The 3.10 behaviour is write: spam\\eggs I think at least the change in csv.QUOTE_MINIMAL behviour should be documented (maybe adding hint to avoid the `escapechar` option for consistent output). -- ___ Python tracker <https://bugs.python.org/issue44861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
