Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24584
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25915
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend Egeberg Aasland :
Suggesting to remove the statement pointer argument from _pysqlite_seterror(),
as it has been unused since commit 525269430a3f9fbb7287e4bb6b365ac216004980.
--
components: Extension Modules
messages: 393001
nosy: berker.peksag, erlendaasland
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24576
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25908
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend Egeberg Aasland :
The following optimisations can be applied to _pysqlite_connection_begin():
1. Return an int instead of a PyObject pointer
Per now, we do Py_RETURN_NONE and Py_DECREF(result) if
_pysqlite_connection_begin() was successful (normally the case
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24575
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25907
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend Egeberg Aasland :
Pr. now, we call sqlite3_column_count() for every iteration in the
_pysqlite_query_execute() loop. If detect_types is set, we call it twice for
every loop.
Suggesting to move it out of the loop and into the pysqlite_Statement object
Erlend Egeberg Aasland added the comment:
Thanks, Steve, that means a lot! Glad to help. Thank you for getting it into
beta1. Having the new event out there with the wrong object passed to it would
have been a tiny bit embarrassing
Change by Erlend Egeberg Aasland :
--
pull_requests: +24513
pull_request: https://github.com/python/cpython/pull/25825
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24510
pull_request: https://github.com/python/cpython/pull/25823
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24509
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/25822
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
Thanks! :) I'll fix the backports.
--
___
Python tracker
<https://bugs.python.org/issue43434>
___
___
Python-bug
Erlend Egeberg Aasland added the comment:
Steve, can we get this in before beta1 (bco. the bugfix)?
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
The PR accidentally fixes a bug in GH-25246 (bpo-43762):
The object passed to PySys_Audit() is now the connection object, not the module
object.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24504
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25818
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend Egeberg Aasland :
--
pull_requests: +24502
pull_request: https://github.com/python/cpython/pull/25816
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Victor:
> And in the "Porting to Python 3.10", I don't know if we should suggest
> reviewing metatypes implemented in C which overrides tp_setattro, to take the
> new flag in account.
I don't know either; perhaps someone else
Erlend Egeberg Aasland added the comment:
> Not sure what do you have in mind for the wiki
See https://meta.discourse.org/t/what-is-a-wiki-post/30801
--
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
test_grammar also needed a fix. It has been updated to use
import_helper.import_fresh_module in bpo-43995 (GH-25764).
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
> These lists are not complete, for example select.kevent was not listed
> whereas it has a bug.
If one of the admins could make that post into a wiki post, it would be open
for editing, making it easier to fill the holes in the
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24457
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25764
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend Egeberg Aasland :
To reproduce:
$ ./python.exe -m test test_typing test_grammar
0:00:00 load avg: 1.95 Run tests sequentially
0:00:00 load avg: 1.95 [1/2] test_typing
0:00:00 load avg: 1.95 [2/2] test_grammar
test test_grammar failed -- Traceback (most recent call
Erlend Egeberg Aasland added the comment:
I'll fix your typo ;) I'll include the rest of the test in the PR. I just
pushed it out quickly to get a review of the solution.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24447
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25757
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
Yes, the sqlite3 types are fine. I don't know why I included them in my earlier
post.
I cleared the tp_new markings for the sqlite3 types on the Discourse post,
since I can edit my posts over there, contrary to here on bpo
Change by Erlend Egeberg Aasland :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue43988>
___
___
Python-bugs-list mailing list
Un
New submission from Erlend Egeberg Aasland :
See https://github.com/python/cpython/pull/25748#discussion_r623849521:
"What do you think of adding support.assert_disallow_instanciation(type, *args)
function which would check for TypeError but also check the error message?
TypeError is
Erlend Egeberg Aasland added the comment:
Pablo & Serhiy, can we close this issue now?
--
___
Python tracker
<https://bugs.python.org/issue43916>
___
___
P
Change by Erlend Egeberg Aasland :
--
pull_requests: +24439
pull_request: https://github.com/python/cpython/pull/25750
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24437
pull_request: https://github.com/python/cpython/pull/25748
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Yes, I’ll have a look at it this afternoon. (On mobile now.)
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
nosy: +erlendaasland
nosy_count: 17.0 -> 18.0
pull_requests: +24435
pull_request: https://github.com/python/cpython/pull/25714
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
> Do you think that something should be changed? If yes, please open a new
> separated issue.
No, my comment was just for information :)
--
___
Python tracker
<https://bugs.python.org/i
Erlend Egeberg Aasland added the comment:
Included in GH-25743
--
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list mailin
Erlend Egeberg Aasland added the comment:
I just found it myself :) pushing out the PR now!
--
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Change by Erlend Egeberg Aasland :
--
pull_requests: +24433
pull_request: https://github.com/python/cpython/pull/25743
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Yep, I agree. From my coverage output, it seems that this branch is never
executed. BUT, that may of course be because there's no test that exercises
this branch.
--
___
Python tracker
<ht
Change by Erlend Egeberg Aasland :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Erlend Egeberg Aasland added the comment:
Ok! Did you see bpo-24912 regarding the ModuleType check?
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Victor:
> check_set_special_type_attr() is used to prevent setting the following
> attributes:
> [...]
> Right now, I cannot set the attribues on array.array type:
> [...]
> I guess that type_setattro() is
Erlend Egeberg Aasland added the comment:
If Berker does not disapprove, I'd like to apply GH-25413 and GH-25414 to the
installers, Steve & Ned.
--
___
Python tracker
<https://bugs.python.org/iss
Erlend Egeberg Aasland added the comment:
Steve, is it worth it to improve this?
--
___
Python tracker
<https://bugs.python.org/issue43434>
___
___
Python-bug
Erlend Egeberg Aasland added the comment:
> check_set_special_type_attr() must also be updated to check for
> Py_TPFLAGS_IMMUTABLETYPE flag.
Ok, lets just use this issue for the PR. I can fix it in an hour or so.
--
___
Python tracker
Erlend Egeberg Aasland added the comment:
Serhiy, would you mind reviewing the PR? bpo-43974 will clean up the changes
introduced to setup.py.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24404
pull_request: https://github.com/python/cpython/pull/25714
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24403
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25714
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
IMO, we can drop most (all?) of the huge comment before the check in
object_set_class(). History is preserved in the git log. Contrary to
Py_TPFLAGS_HEAPTYPE, using Py_TPFLAGS_IMMUTABLETYPE speaks for itself. We might
reduce it to just refer
New submission from Erlend Egeberg Aasland :
Use Py_TPFLAGS_IMMUTABLETYPE iso. Py_TPFLAGS_HEAPTYPE in object_set_class().
See also:
- bpo-43908 (particularly msg392286)
- bpo-24912
-
https://github.com/python/cpython/blob/e047239eafefe8b19725efffe7756443495cf78b/Objects/typeobject.c#L4620
Erlend Egeberg Aasland added the comment:
> Erlend: Do you want to write such change?
Sure, I'll have a go at it. Thanks.
--
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
Shreyan, see msg391954 earlier in this thread:
"I also think you should try to separately land small patches that add the
IMMUTABLETYPE flag to a few very public types, e.g. array.array and the three
in _sre (which are exported by
Change by Erlend Egeberg Aasland :
--
pull_requests: +24387
pull_request: https://github.com/python/cpython/pull/25697
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24386
pull_request: https://github.com/python/cpython/pull/25696
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
See msg391933, Shreyan. I think Christian will take care of his types :)
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Oh, well, SQLITE_DEFAULT_MEMSTATUS=0 does in fact affect PRAGMA
soft_heap_limit. Looks like I'm left with only SQLITE_OMIT_AUTOINIT, then :)
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Here's a list of the SQLite recommended compile-time options (only):
- macOS (v11.2.3) (SQLite v3.32.3) defines SQLITE_DEFAULT_WAL_SYNCHRONOUS=1
- Homebrew (SQLite v3.35.4) does not define any of the recommended compile-time
options
- Debian Buster
Erlend Egeberg Aasland added the comment:
As noted in
https://github.com/python/cpython/pull/25414#issuecomment-828501078,
SQLITE_OMIT_DEPRECATED also leaves out PRAGMA's, which can break applications.
I'll update the PR's to leave it out
Erlend Egeberg Aasland added the comment:
I suggest applying the following safe options for the installers:
# SQLITE_DEFAULT_MEMSTATUS
Memory status is currently not available in the sqlite3 API, so there's no need
for SQLite to keep track of this. If we add such an API (not likely, IMO
Erlend Egeberg Aasland added the comment:
Thanks, Serhiy.
--
___
Python tracker
<https://bugs.python.org/issue43916>
___
___
Python-bugs-list mailing list
Unsub
Change by Erlend Egeberg Aasland :
--
pull_requests: +24355
pull_request: https://github.com/python/cpython/pull/25666
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
pull_requests: +24354
pull_request: https://github.com/python/cpython/pull/25665
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
nosy: -erlendaasland
___
Python tracker
<https://bugs.python.org/issue43955>
___
___
Python-bugs-list mailing list
Unsub
Erlend Egeberg Aasland added the comment:
Thank you, Steve!
--
___
Python tracker
<https://bugs.python.org/issue43492>
___
___
Python-bugs-list mailin
Erlend Egeberg Aasland added the comment:
> I've not seen any failing tests for GH-25653 on the CI or on my computer.
That would be GH-25520. GH-25653 is the slightly related issue/PR. Both are
passing CI, though.
--
___
Python tracker
<
Erlend Egeberg Aasland added the comment:
> Are you two collaborating?
No, but any help is of course appreciated.
--
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
Shreyan, are you running the tests against the PR, or something else? Have you
tried make clean (or git clean -fdx)?
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
I've not seen any failing tests for GH-25653 on the CI or on my computer.
The PR is based off of 1b1f9852bda85c01ef124858f293e9c13e04ffce, which is
pretty recent. I can rebase onto master, but I don't see any need for it as
long as the tests suite
Erlend Egeberg Aasland added the comment:
> The second most important part here is also adding regression tests so this
> doesn't happen.
I've started adding tests. I'm not sure if I need to wrap them with
@cpython_only.
Some of the types are hidden deep inside the implementations,
Erlend Egeberg Aasland added the comment:
For that to work, you'd have to add a flag in PyType_FromModuleAndSpec, set the
flag if (slot->slot == Py_tp_new && slot->pfunc == NULL) in the slots for loop,
and then reset tp_new _after
Erlend Egeberg Aasland added the comment:
> Alternatively we can make PyType_FromSpec() setting tp_new to NULL if there
> is explicit {Py_tp_new, NULL} in slots.
Yes. It's not as explicit (and self-documenting) as _PyType_DisabledNew,
though. But it avoids expanding the
Erlend Egeberg Aasland added the comment:
Alternative approach:
Add _PyType_DisabledNew to Include/cpython, and add {Py_tp_new,
_PyType_DisabledNew} slot to affected types. Diff attached.
See GH discussion:
- https://github.com/python/cpython/pull/25653#issuecomment-827383246
- https
Erlend Egeberg Aasland added the comment:
> These tests should also be added when new types are converted in the future.
We should have a checklist for static to heap type conversion. I'm pretty sure
I've seen something like that in one of Victor's blogs. A new section in the
Dev Gu
Change by Erlend Egeberg Aasland :
--
pull_requests: +24344
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25653
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
Thanks Shreyan, but Steve prefers to update it himself:
https://github.com/python/cpython-source-deps/pull/22#issuecomment-705234459
Just having the sources in place does not really help; you need a new git tag,
which can only be pushed by core devs
Erlend Egeberg Aasland added the comment:
Steve & Ned: It would be nice if we could merge the PR's just before the
weekend, so we get up-to-date installers for the beta.
FYI, the SQLite forum has been quiet, and the fossil branch has not m
Change by Erlend Egeberg Aasland :
--
pull_requests: +24334
pull_request: https://github.com/python/cpython/pull/25641
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend Egeberg Aasland :
--
keywords: +patch
pull_requests: +24333
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25640
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend Egeberg Aasland :
--
keywords: +patch
Added file: https://bugs.python.org/file49989/patch.diff
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Pablo, I've made a patch for most of these (I've left out Christian's modules).
I've only added a couple of tests for now. Do you want all in one PR?
$ git diff main --stat
Lib/test/test_array.py | 4
Lib/test/test_unicodedata.py
Erlend Egeberg Aasland added the comment:
Christian:
> Can I get rid of the function with "{Py_tp_new, NULL}" [...]
Unfortunately not. The workaround in 993e88cf08994f7c1e0f9f62fda4ed32634ee2ad
does the trick though.
--
___
Python tr
Erlend Egeberg Aasland added the comment:
Ah, yes thanks for the heads up! I'll update the PR.
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
No problem, will do!
--
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list mailin
Erlend Egeberg Aasland added the comment:
You're right, that would become messy. Complementing existing test suites is a
better approach.
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
> Could you please land the new flag and typeobject.c code now?
I've only got two more questions before I mark it ready for review, and that's
regarding Guido's comment in msg391756:
Should the new flag also take care of __class__ assignm
Erlend Egeberg Aasland added the comment:
Is it worth it adding tests for this? I'm thinking a generic version of
msg391910 (maybe Lib/test/test_uninitialised_heap_types.py) coupled with a
dataset.
--
___
Python tracker
<https://bugs.python.
Erlend Egeberg Aasland added the comment:
Is there any way we can fix this in Objects/typeobject.c, or do we actually
have to patch every single type manually?
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Here's a plaintext version:
- 0b858cdd5d2021-01-04 Modules/cjkcodecs/multibytecodec.c
- _multibytecodec.MultibyteCodec
- c8a87addb1 2021-01-04 Modules/pyexpat.c
- pyexpat.xmlparser
- 75bf107c62 2021-01-02 Modules/arraymodule.c
Erlend Egeberg Aasland added the comment:
> Can you provide the error output log you're getting?
I don't think we should use more time on apply-to-all.diff, since it's probably
not going to be applied as it is anyway.
--
___
Python trac
Erlend Egeberg Aasland added the comment:
> Thank you for your work Erlend.
Anytime! I've updated the list now. There may still be errors, but I think it's
pretty accurate now.
--
___
Python tracker
<https://bugs.python.org/issu
Erlend Egeberg Aasland added the comment:
> It is incomplete.
Yes, I know. I'm working on completing it manually. Some of the static structs
were only partially initialised (most stop at tp_members). The rest of the
struct (including tp_new) would then be initialised to z
Erlend Egeberg Aasland added the comment:
> We need to check which static types had tp_new = NULL before they were
> converted to heap types
I did a quick git grep. Results pasted into the list over at
https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-type
Change by Erlend Egeberg Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue43916>
___
___
Python-bugs-list mailing list
Unsub
Erlend Egeberg Aasland added the comment:
> Let's post the list here and post a brief mention of this issue on
python-dev.
Attached. The list contains commits, commit dates, affected files, and the name
of the PyType_Spec variables (I _can_ resolve these to the actual type names,
bu
Erlend Egeberg Aasland added the comment:
Thanks for the background info, Guido! I'll prepare a list. Should we continue
the discussion on Discourse or python-dev?
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
The more I read about these issues, the more I feel reluctant to apply PR
25520. Why change the behaviour/traits of heap types without a proper
discussion (or PEP)? Applying this PR feels like an arbitrary change. All the
related issues and mailing
Erlend Egeberg Aasland added the comment:
Maybe it's better to send the event only if the connection succeeded:
diff --git a/Modules/_sqlite/module.c b/Modules/_sqlite/module.c
index 8dbfa7b38a..0220978cf2 100644
--- a/Modules/_sqlite/module.c
+++ b/Modules/_sqlite/module.c
@@ -97,6 +97,12
Erlend Egeberg Aasland added the comment:
Something like the attached patch, if I understand you correctly?
--
Added file: https://bugs.python.org/file49982/patch.diff
___
Python tracker
<https://bugs.python.org/issue43
Erlend Egeberg Aasland added the comment:
Good question. sqlite3_load_extension() loads an extension into a database
connection, so it would make sense to also pass the connection object. I'd say
we do it; it's a small change, and as you say: if we wanted to add it later, we
couldn't.
Ref
Erlend Egeberg Aasland added the comment:
> Does the test suite pass for apply-to-all.diff?
No, multiple tests fail. First test_distutils fails, then during the re-run,
test_multiprocessing_forkserver, test_multiprocessing_spawn, and test_pdb fail.
> Also, quite a hornet's nest
Change by Erlend Egeberg Aasland :
Removed file: https://bugs.python.org/file49979/apply-to-all.diff
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Pytho
Change by Erlend Egeberg Aasland :
Added file: https://bugs.python.org/file49980/apply-to-all.diff
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Pytho
Erlend Egeberg Aasland added the comment:
I've prepared a diff using grep & sed (see attached patch). Let me know if you
want it converted to a PR.
I've excluded the test and the _xx extension modules.
--
Added file: https://bugs.python.org/file49979/apply-to-all.
1 - 100 of 656 matches
Mail list logo
