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/issu
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
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
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
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
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
Change by Sebastian Berg :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46451>
___
___
Python-bugs-list
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
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/issu
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
&
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 >
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
Change by Sebastian Rittau :
--
nosy: +srittau
___
Python tracker
<https://bugs.python.org/issue46414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sebastian Rittau :
--
nosy: +srittau
___
Python tracker
<https://bugs.python.org/issue46006>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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 t
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 f
Sebastian Rittau added the comment:
Ref https://github.com/python/typeshed/pull/6317 for a discussion about this in
typeshed.
--
nosy: +srittau
___
Python tracker
<https://bugs.python.org/issue41
Sebastian Rittau added the comment:
I would ask you to reconsider this.
https://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path/67692#67692
is a highly active question on StackOverflow, and my answer basically provided
me all the karma I got there. For users
Sebastian Rittau added the comment:
All my projects now use werkzeug instead of the cgi module, so I can't confirm
whether this problem still exists. I'm fine with closing this as unreproducible
if no one else can reproduce it.
--
status: pendi
New submission from Sebastian Berg :
The PyType_FromSpec fails to take care about MetaClasses.
https://bugs.python.org/issue15870
Asks to create a new API to pass in the MetaClass. This issue is only about
"inheriting" the metaclass of the bases correctly. Currently, Pytho
Sebastian Berg added the comment:
Yeah, I will try and have a look. I had posted the patch, because the test
looked like a bit of a larger chunk of work ;).
> And I'm surprised that you're surprised :)
:). I am coming from a completely different angle, probably. Just if you
Sebastian Berg added the comment:
> But if tp_name is created dynamically, it could lead to a dangling pointer.
I will guess this is probably just an oversight/bug since the main aim was to
move towards heap-types, and opened an issue: https://bugs.python.org/issue45
New submission from Sebastian Berg :
As noted in the issue: https://bugs.python.org/issue15870#msg402800
`PyType_FromSpec` assumes that the `name` passed is persistent for the program
lifetime. This seems wrong/unnecessary: We are creating a heap-type, a
heap-type's name is stored
Sebastian Berg added the comment:
Just to note, that there are two – somewhat distinct – issues here in my
opinion:
1. `FromSpec` does not scan `bases` for the correct metaclass, which it could;
this could even be considered a bug?
2. You cannot pass in a desired metaclass, which may require
Change by Sebastian Koslowski :
--
nosy: +skoslowski
___
Python tracker
<https://bugs.python.org/issue40059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sebastian Berg added the comment:
I can make a PR from the patch (and add the `Py_tp_metaclass` slot if desired)
with a basic test here, if that is what is blocking things.
Fixing the type and size of the allocation (as the patch does) would allow me
to give people a way to create a new
Sebastian Rittau added the comment:
One thing I would strongly suggest for consistent terminology: Make "iterator"
mean an object that has both "__next()__" and "__iter()__". This is consistent
with how an iterator has been described in the glossary for a long t
Sebastian Berg added the comment:
I am still fighting with this (and the issues surrounding it) for NumPy. The
main point is that my new DTypes in NumPy are metaclasses that extend the
(heap)type struct.
That just feels right and matches the structure perfectly, but seems to get
awkward
Change by Sebastian Rittau :
--
keywords: +patch
pull_requests: +26297
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27833
___
Python tracker
<https://bugs.python.org/issu
New submission from Sebastian Rittau :
The new PEP 604 syntax for type unions should be mentioned more prominently in
the typing docs, starting with Python 3.10. I'm preparing a PR for discussion.
--
assignee: docs@python
components: Documentation
messages: 399919
nosy: docs@p
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 consist
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
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
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
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
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
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_
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
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/issu
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(val
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
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/issue38
Change by Sebastian Rittau :
--
pull_requests: +25599
pull_request: https://github.com/python/cpython/pull/27039
___
Python tracker
<https://bugs.python.org/issue38
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 warnin
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
<ht
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 i
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/issue38
Change by Sebastian Rittau :
--
pull_requests: +25307
pull_request: https://github.com/python/cpython/pull/26719
___
Python tracker
<https://bugs.python.org/issue38
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.p
Change by Sebastian Rittau :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue38460>
___
___
Python-bugs-list mailing list
Un
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
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/issue38
Change by Sebastian Rittau :
--
pull_requests: +24758
pull_request: https://github.com/python/cpython/pull/26113
___
Python tracker
<https://bugs.python.org/issue35
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/issu
Change by Sebastian Rittau :
--
nosy: +srittau
___
Python tracker
<https://bugs.python.org/issue38291>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sebastian Speitel added the comment:
Or maybe a cls argument which defaults to obj.__class__?
--
___
Python tracker
<https://bugs.python.org/issue43965>
___
___
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
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,
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_T
Sebastian Koslowski added the comment:
>>> import parent.child
first imports "parent" (successfully) but then fails, because the import code
has no knowledge of were to find ".child". This is because
a) the module "parent" is not marked as a package (
Sebastian Voigt added the comment:
The fix has only be done for 3.8, 3.9 and 3.10. Are 3.7 and 3.6 are not
impacted?
--
nosy: +squear
___
Python tracker
<https://bugs.python.org/issue41
Change by Sebastian Berg :
--
nosy: +seberg
___
Python tracker
<https://bugs.python.org/issue40522>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sebastian Wiedenroth added the comment:
Excellent analysis, that's it! I've also tested your patch on SmartOS and it
works great.
--
___
Python tracker
<https://bugs.python.o
Change by Sebastian Wiedenroth :
--
keywords: +patch
pull_requests: +22002
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23085
___
Python tracker
<https://bugs.python.org/issu
New submission from Sebastian Wiedenroth :
I'm investigating some test failures related to sendfile on illumos:
testCount (test.test_socket.SendfileUsingSendfileTest) ... FAIL
testCountSmall (test.test_socket.SendfileUsingSendfileTest) ... ok
testCountWithO
Sebastian Wiedenroth added the comment:
This patch has also been applied to the python versions shipped by OpenIndiana
and OmniOS for a long time. I'd say it's safe to merge.
--
nosy: +wiedi
___
Python tracker
<https://bugs.python.o
Sebastian Wiedenroth added the comment:
> Which Python version do you use?
Myself currently mostly python 3.8 via pkgsrc on SmartOS (one of the illumos
distributions).
OmniOS ships 3.7:
https://github.com/omniosorg/omnios-build/tree/master/build/python37
OpenIndiana ships at least
Sebastian Wiedenroth added the comment:
Please don't.
Even if Oracle doesn't care anymore, the open source illumos community does.
We (illumos) share the same uname "SunOS" and depend on this support.
I have offered to host an illumos buildbot in the past and that offer
New submission from Sebastian Rittau :
In typeshed (the repository for stdlib type annotations), we have defined a
bunch of types to support annotating WSGI interfaces. See
https://github.com/python/typeshed/blob/master/stdlib/2and3/_typeshed/wsgi.pyi
for the current version. Unfortunately
Sebastian Rittau added the comment:
For reference, this came up in
https://github.com/python/typeshed/issues/4639#issuecomment-706596656.
`typing.io` has never been in typeshed and we decided not to include it. It
looks as if it never gained any traction, especially since the types are
Sebastian Berg added the comment:
In NumPy ufuncs and datatype casting (iteration) we have the following setup:
user-code (releasing GIL) -> NumPy API -> 3rd-party C-function
(in the ufunc code, numpy is the one releasing the GIL, although others, such
as numba probably hook
New submission from Sebastian Berg :
In https://bugs.python.org/issue40826 it was defined that
`PyOS_InterruptOccurred()` can only be called with a GIL. NumPy had a few
places with very unsafe sigint handling (not thread-safe). But generally when
we are in a situation that catching sigints
Sebastian Berg added the comment:
Ok, I will just close it. It is painfully clear that e.g. `mmap` uses it this
way to prohibit closing, and also `memoryview` has all the machinery necessary
to do counting of how many exports, etc. exists.
I admit, this still rubs me the wrong way, and I
Sebastian G Pedersen added the comment:
Yes, I will update the PR before the end of next week.
--
___
Python tracker
<https://bugs.python.org/issue39
Sebastian G Pedersen added the comment:
Thanks again for the engagement.
I am also in favor of adding the encoding to the constructor. However,
following Giampaolo's comment, that utf-8 is standard and has been for a long
time (and the RFC dating back to year 1999), I am also in fav
Sebastian Rittau added the comment:
Code using this argument is in all likelihood already subtly broken, because it
depends on non-existing functionality. I believe that a "hard" break would be
better (for Python 3.9).
--
___
Pyth
Sebastian Rittau added the comment:
Shantanu points out in https://github.com/python/typeshed/pull/3715 that the
argument was made useless due to bpo-28009.
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Sebastian Rittau :
uuid.getnode() has an undocumented, keyword-only "getters" argument that gets
discarded immediately. This is confusing when using code inspection tools and
can give the wrong impression that you can somehow override the node getters
when yo
Sebastian Berg added the comment:
I went through Python, `array` seems to not break the logic. pickling has a
comment which specifically wants to run into the argument parsing corner case
above (I am not sure that it is really important). However,
`Modules/_testbuffer.c` (which is just test
Sebastian Berg added the comment:
Hmmm, it seems I had missed this chunk of PEP 3118 before:
> Exporters will need to define a bf_releasebuffer function if they can
> re-allocate their memory, strides, shape, suboffsets, or format variables
> which they might share through t
New submission from Sebastian Berg :
The current documentation of ``PyBuffer_Release()`` and the PEP is a bit fuzzy
about what the function can and cannot do.
When an object exposes the buffer interface, I believe it should always return
a `view` (in NumPy speak) of its own data, i.e. the
Sebastian G Pedersen added the comment:
Thank you for the feedback.
I will elaborate a little bit on the reasons and thoughts behind the pull
request:
Since RFC 2640, the industry standard within FTP Clients is UTF-8 (see e.g.
FileZilla here: https://wiki.filezilla-project.org
Sebastian Noack added the comment:
Yes, I could use LD_LIBRARY_PATH (after copying /usr/lib/libsqlcipher.so.0 to
/some/folder/libsqlite3.so), or alternatively LD_PRELOAD, and the sqlite3
stdlib module will just work as-is with SQLCipher. The latter is in fact what
I'm doing at the m
Sebastian Noack added the comment:
Well, the stdlib already depends on a third-party library here, i.e. SQLite3.
SQLCipher is a drop-in replacement for SQLite3 that adds support for encrypted
databases. In order to use SQLCipher, I'd have to build the sqlite3 module
against SQLC
New submission from Sebastian Noack :
SQLCipher is industry-standard technology for managing an encrypting SQLite
databases. It has been implemented as a fork of SQLite3. So the sqlite3 corelib
module would build as-is against it. But rather than a fork (of this module),
I'd rathe
Change by Sebastian G Pedersen :
--
keywords: +patch
pull_requests: +17443
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18048
___
Python tracker
<https://bugs.python.org/issu
Change by Sebastian G Pedersen :
--
components: Library (Lib)
nosy: SebastianGPedersen
priority: normal
severity: normal
status: open
title: ftplib uses latin-1 as default encoding
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Change by Sebastian Berg :
--
keywords: +patch
pull_requests: +17412
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18017
___
Python tracker
<https://bugs.python.org/issu
New submission from Sebastian Berg :
This is mainly an information request, so sorry if its a bit besides the point
(I do not mind if you just close it). But it seemed a bit too specific to get
answers in most places...
In Python you use argument clinic, which supports `METH_FASTCALL`, that
Sebastian Berg added the comment:
Thanks for the quick responses.
@Victor Stinner, I suppose you could change `numbers.Complex.__bool__()` by
adding the no-op bool to make it: `bool(self != 0)`.
But I am not sure I feel it is necessary. NumPy is a bit a strange in that it
uses its own
New submission from Sebastian Krause :
The following lines trigger a segmentation fault:
class E(BaseException):
def __new__(cls, *args, **kwargs):
return cls
def a(): yield
a().throw(E)
Source with a bit more explanation:
https://gist.github.com/coolreader18
Sebastian Berg added the comment:
Fair enough, we had code that does it the other way, so it seemed "too obvious"
since the current check seems mainly useful with few kwargs. However, a single
kwarg is super common in python, while many seem super rare (in any argument
clini
New submission from Sebastian Berg :
The keyword argument extraction/finding function seems to have a performance
bug/enhancement (unless I am missing something here). It reads:
```
for (i=0; i < nkwargs; i++) {
PyObject *kwname = PyTuple_GET_ITEM(kwnames, i);
/*
Change by Sebastian Berg :
--
keywords: +patch
pull_requests: +17049
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17576
___
Python tracker
<https://bugs.python.org/issu
New submission from Sebastian Szwarc :
As follow up to my recent bug error regarding segmentation fault.
Installed 2.7.17 on Mojave.
Because MySQLdb for reason unknown (SSL required error) is impossible to
install by PIP I used PyMysql and modified line as `import pymysql as MySQLdb`
There is
Sebastian Szwarc added the comment:
If someone really want to test
The test procedure should be as follows:
Get the EPFImporter tool
https://affiliate.itunes.apple.com/resources/documentation/epfimporter/
Set up your database and put relevant login information in EPFConfig
Get the simple
Sebastian Szwarc added the comment:
I strongly disagree. Python 2.7 is 2.7 -> if some new errors appeared
after upgrading between minor version this is not expected behaviour,
and therefore it means there is error in interpreter itself.
upgrading from 2.7 to 2.7 is not the same as upgrad
1 - 100 of 313 matches
Mail list logo