Nick Coghlan added the comment:
I'd also ask whether the use case can be satisfied by rebinding __class__
instead of __bases__. That's far better defined than replacing the contents of
the bases list and attempting to dynamically recalcula
Nick Coghlan added the comment:
>From VA's description of the intended use case, this actually sounds a bit
>like a variant of https://bugs.python.org/issue29944: one reason that
>replacing C with a new dynamically constructed type won't work reliably is
>because som
Nick Coghlan added the comment:
New changeset 988fb28431d3a3fc5dc6eb657c8a4baacc04d9ce by Nick Coghlan (Cheryl
Sabella) in branch 'master':
bpo-11015: Update test.support documentation (GH-5610)
https://github.com/python/cpython/commit/988fb28431d3a3fc5dc6eb657c8a4b
Nick Coghlan added the comment:
I merged Cheryl's PR to the dev branch, and triggered the backport to 3.7. If
nobody beats me to it, I'll merge the latter tomorrow :)
--
assignee: docs@python -> ncoghlan
resolution: -> fixed
stage: patch review -&
Nick Coghlan added the comment:
New changeset a0b998df314370f00502efe7ad84206f5bb782ff by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-11015: Update test.support documentation (GH-5619)
https://github.com/python/cpython/commit/a0b998df314370f00502efe7ad8420
Nick Coghlan added the comment:
I think the aspect that makes this potentially worthy of a helper function is
the need to dynamically adjust the field width based on whether you're printing
an IPv4 address or an IPv6 one, whether you're printing it in binary or
hexadecimal, whet
Nick Coghlan added the comment:
I can reproduce this, but it looks to me like it's being triggered by UTF-8
mode rather than locale coercion (the "LC_ALL=C" setting will implicitly
disable locale coercion entirely):
```
$ LANG=C PYTHONCOERCECLOCALE=warn ./python -We -
Nick Coghlan added the comment:
For now, I'm going to close this as "out of date", with the guidance being
"Define a data class instead" (since that gets rid of the historical
boilerplate a different way: auto-generating suitable methods based on the
field declarat
Change by Nick Coghlan :
--
pull_requests: +5455
___
Python tracker
<https://bugs.python.org/issue30579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
It isn't InitVar that you want for that use case (that's just for passing extra
information to __post_init__).
Instead, you want:
extra_field = field(compare=False): int # Excluded from __hash__, __eq_, etc
You can also exclude a field from __h
Nick Coghlan added the comment:
New changeset aec7532ed3ccbd29d3429a3f375e25f956c44003 by Nick Coghlan in
branch 'master':
bpo-30579: Docs for dynamic traceback creation (GH-5653)
https://github.com/python/cpython/commit/aec7532ed3ccbd29d3429a3f375e25
Nick Coghlan added the comment:
We still need to the ".0" style temporary variables that are used for argument
names in the implicitly generated functions, but it's definitely plausible that
we're not actually using the "_[1]" style hidden variables anyw
Nick Coghlan added the comment:
Aye, definitely worth a thread on python-ideas. My rationale for suggesting
something based on the built-in numeric codes is that it makes it
straightforward for *users* to transfer knowledge from that mini-language.
As far as parsing goes, I was thinking of
Nick Coghlan added the comment:
Allowing for None-first and None-last ordering is a fair use case, but I'm not
sure a __key__ protocol is the right answer to that - as your own example
shows, it gets tricky when dealing with nested containers.
It may make sense to raise the questi
Nick Coghlan added the comment:
The python-ideas discussion didn't turn up any major concerns we hadn't already
considered, so you're in "wait for PR review" mode now. If you wanted to do a
self-review in the meantime, then
https://devguide.python.org/committing
Nick Coghlan added the comment:
+1 from me for making the change 3.7.0+ only - 3.6 isn't doing the right thing,
but given folks are relying on it doing the wrong thing, then let's leave it
alone given where it is in its lifecycle.
--
Nick Coghlan added the comment:
I've updated the issue title to reflect the revised proposal (i.e. using
__format__ rather than a new IP address specific method).
--
title: Add bits method to ipaddress -> Add __format__ method to i
Nick Coghlan added the comment:
For TESTFN_NONASCII vs TESTFN_UNICODE (inferred from reading the current code &
https://github.com/python/cpython/commit/8b219b2936d767bf6c6c17618db3a7b22fc2e865):
* TESTFN_NONASCII guarantees that it can be encoded and decoded with the
default filesy
Nick Coghlan added the comment:
As pure aliases, those wouldn't necessarily be that useful, as aside from
NameConstant, the field names are different (Num.n, Str.s, Bytes.s).
I do wonder whether it might be worth keeping "NameConstant", though, and use
that for Ellipsis
Nick Coghlan added the comment:
Ah, right - in that case, I think the subclasses would be worthwhile, as they
shouldn't be too much hassle to maintain for a release, and will provide a more
graceful migration for folks doing their own AST processing and gener
Nick Coghlan added the comment:
I'll also note that I made my comments above about writing a new PEP prior to
the migration to GitHub and the availability of a PR-based workflow for
reviewing PEP changes.
So consider the PR Cheryl linked and the post at
https://mail.python.org/pipe
Nick Coghlan added the comment:
+1 for the DeprecationWarning->SyntaxWarning->SyntaxError approach from me
(especially as 3.7 will make the existing deprecation warning visible in
interactive shells and __main__ modules by default).
--
___
Nick Coghlan added the comment:
We don't change the extension on optimised pyc files any more, we add an
optimisation marker to the name without changing the file extension:
https://www.python.org/dev/peps/pep-0488/
(This means `-O` and `-OO` don't tread on each othe
Nick Coghlan added the comment:
I think supporting "s" makes sense, as we're going to need to treat the empty
format string as implying "s" for backwards compatibility reasons:
>>> f"{v4}"
'1.2.3.4'
Right now, attempting to for
Nick Coghlan added the comment:
I believe the original rationale for the `__path__` check was to restrict that
branch to the case where we may need to import a not-yet-imported submodule in
order to get the attribute set appropriately.
However, giving a better error message for __all__ in
Change by Nick Coghlan :
--
pull_requests: -5640
___
Python tracker
<https://bugs.python.org/issue12345>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
With issue 17611 merged (which moves stack unwinding to the compiler), I expect
the exact details of this problem to have changed, but the general problem
still exists: Ctrl-C may lead to __exit__ (or __aexit__) not being called even
after __enter__ (or
Nick Coghlan added the comment:
_xxsubinterpreters has been added, and we'll use PEP 554 as the interim
documentation while it's only exposed for testing purposes.
--
resolution: -> fixed
stage: patch review -> resolved
status
Nick Coghlan added the comment:
I +1'ed Serhiy's patch for issue 32946, so we'll have to take that
micro-optimisation into account if we decide to rely on the Python level
`_handle_fromlist` to cover the "*" import case.
Given that optimisation, it's probably
Nick Coghlan added the comment:
New changeset 3a087beddd9f0955eb9080a6fd1499ff89ca74bf by Nick Coghlan (Nitish
Chandra) in branch 'master':
bpo-32836: Remove obsolete code from symtable pass (GH-5680)
https://github.com/python/cpython/commit/3a087beddd9f0955eb9080a6fd1499
Nick Coghlan added the comment:
(Bringing my response from core-mentorship over to the main tracker)
These APIs are exposed to embedding applications via the pylifecycle header:
https://github.com/python/cpython/blob/master/Include/pylifecycle.h#L143
While we technically *could* deprecate
Nick Coghlan added the comment:
Yeah, dropping _PyFrame_Init/Fini for 3.8+ would make sense.
It's PyByteArray_Init/Fini that probably aren't worth the hassle of removing,
since the lack of a leading underscore means they'd need to go through a
deprecation cycle.
--
re
New submission from Nick Coghlan :
The struct.Struct docs claim that creating and re-using a Struct object will be
noticeably faster than calling the module level methods repeatedly with the
same format string, as it will avoid parsing the format string multiple times:
https://docs.python.org
Nick Coghlan added the comment:
The note on https://docs.python.org/3/library/re.html#re.compile provides a
useful precedent for possible wording here, as the struct cache and the regex
cache are quite similar.
--
___
Python tracker
<ht
Nick Coghlan added the comment:
New changeset 308eab979d153f1ab934383dc08bc4546ced8b6c by Nick Coghlan (Eric
Appelt) in branch 'master':
bpo-26701: Add documentation for __trunc__ (GH-6022)
https://github.com/python/cpython/commit/308eab979d153f1ab934383dc08bc4546ced8b6c
-
New submission from Nick Coghlan :
(Note: I haven't categorised this yet, as I'm not sure how it *should* be
categorised)
Back when the __index__/nb_index slot was added, the focus was on allowing 3rd
party integer types to be used in places where potentially lossy conversion
wi
Nick Coghlan added the comment:
I think __trunc__ is special here, as it's called by a built-in type
constructor, whereas __floor__ and __ceil__ really are specific to their
respective math module functions. That said, I also wouldn't be opposed to
listing all 4 methods togethe
Nick Coghlan added the comment:
Marking this as a documentation enhancement request for now, but I think we
should also consider changing the type creation behaviour in 3.8 to implicitly
add __int__ and __trunc__ definitions when __index__ is defined, but they
aren't.
That way, no beha
Nick Coghlan added the comment:
New changeset f34e0d60e27acff3f9604ec63e9de36878c3743a by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-26701: Add documentation for __trunc__ (GH-6049)
https://github.com/python/cpython/commit/f34e0d60e27acff3f9604ec63e9de3
Nick Coghlan added the comment:
New changeset 1028ca4f04c14cf40a8f3e7951623a96ec0143c2 by Nick Coghlan (Miss
Islington (bot)) in branch '3.6':
bpo-26701: Add documentation for __trunc__ (GH-6050)
https://github.com/python/cpython/commit/1028ca4f04c14cf40a8f3e7951623a
Nick Coghlan added the comment:
I don't think we made any start-up changes that were specific to
PySys_AddWarnOption, so my suspicion is that the crash is going to be related
to a change in the constraints on either the unicode object creation or the
list append operation.
The att
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue33042>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
With both Eric's and Serhiy's updates merged, and issue 33039 broken out for
the __index__ oddities, this is resolved now.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Nick Coghlan added the comment:
Adding a bit of context from my prior email discussion with Hartmut: CPython
actually reads sys.warnoptions at the end of Py_Initialize (its the last thing
we do before the function returns).
It also reads sys._xoptions during startup, since that's one w
Nick Coghlan added the comment:
https://github.com/python/cpython/commit/b4d1e1f7c1af6ae33f0e371576c8bcafedb099db
(the first attempted fix for bpo-20891) is the last commit where the draft
test case patch applies cleanly.
That still segfaults, so I'll jump all the way back to 3.7.0a1, r
Nick Coghlan added the comment:
After reworking the patch to backport the pre-initialization embedding tests to
3.7.0a1, they *both* failed, as that was before Victor fixed Py_DecodeLocale to
work prior to initialization again.
As a result, I tried
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
Thanks for the report and pull request. Do you happen to know if setuptools is
also affected?
If yes, the problem will need to be reported & fixed there as well (otherwise
the maintainer metadata will still be missing for many publishers), if no, then
u
Nick Coghlan added the comment:
While I haven't definitely narrowed it down yet, I suspect it isn't your
changes that are the problem: since the reported crash relates to attempting to
access a not-yet-created thread state, `warnoptions` and `_xoptions` likely
need to become C lev
Nick Coghlan added the comment:
We allowed semi-standardised additional fields for an extended period with 1.2
(for Provides-Extra and Description-Content-Type), but folks mostly found it
confusingly ambiguous, so Dustin created PEP 566 to define them officially as
Metadata 1.3.
Given that
Nick Coghlan added the comment:
Patched test_capi results for 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 (the
global state consolidation commit): both pre-initialization tests fail
Patched test_capi results for bab21faded31c70b142776b9a6075a4cda055d7f (the
immediately preceding commit): both
Nick Coghlan added the comment:
New changeset c2b0b12d1a137ada1023ab7c10b8d9a0249d95f9 by Nick Coghlan (Marcel
Plch) in branch 'master':
bpo-32374: m_traverse may be called with m_state=NULL (GH-5140)
https://github.com/python/cpython/commit/c2b0b12d1a137ada1023ab7c10b8d9
Nick Coghlan added the comment:
This shouldn't affect the public ABI, so I don't think it's a blocker for the
ABI freeze, but it's a regression that effectively makes PySys_AddWarnOption
(and related APIs) unusable, so we should definitely fix it before shipping 3.7.
For
Nick Coghlan added the comment:
This isn't considered a security issue, as running "python3" interactively
behaves in exactly the same way (i.e. tracking changes to the current working
directory for the duration of the session), and running "python3 script.py"
Nick Coghlan added the comment:
Also, a small upstream community interaction tip: if you want people to
seriously consider your requests for changes in default behaviour (which
inevitably risk backwards compatibility breaks), don't start out by insulting
them.
Python's de
New submission from Nick Coghlan :
In https://bugs.python.org/issue33053#msg313966, jwilk noted that it isn't
obvious from https://docs.python.org/3/using/cmdline.html#cmdoption-m how to
keep the current directory from being added to `sys.path` when using the -m
switch. The answer is to
Nick Coghlan added the comment:
I've also separated out https://bugs.python.org/issue33095 (a docs issue about
making isolated mode more discoverable) based on the jwilk's comment that it
wasn't clear how to disable the default "add the current directory to
Nick Coghlan added the comment:
Regarding 2.7: if folks want this fixed on RHEL/CentOS, then they need to talk
to Red Hat about it, not the upstream CPython devs. I used to work there, and
was told multiple times by Red Hat executives that none of their customers
actually used Python, so the
Nick Coghlan added the comment:
I'm going to abuse the "third party" resolution type a bit and mark this as
closed (at least for now) on the basis of "use setuptools instead if you want
the improved behaviour".
I've also opened https://github.com/pypa/pa
Nick Coghlan added the comment:
"python -m mypkg.myscript" does the right thing as far as local packages are
concerned, whereas "python -m mypkg/myscript.py" will set you up for
double-import bugs.
Note that you can almost always trigger arbitrary non-obvious code execut
Nick Coghlan added the comment:
https://bugs.python.org/issue13475 is the existing enhancement request to
expose sys.path[0] management independently of the other execution isolation
features.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
This question recently came up again over in
https://bugs.python.org/issue33053#msg314040.
With the assorted startup refactorings that were landed for 3.7, it likely
makes sense to take another run at this for 3.8
Nick Coghlan added the comment:
It occurs to me that there may be some additional unshared context here: the
way `python -m pip` searches for the module to execute is much closer to the
way Windows searches for a command like `pip` (i.e. current directory first)
than it is to the way *nix
Nick Coghlan added the comment:
Donald made an interesting suggestion over on
https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331,
which was to have distutils stop overwriting the Author metadata with the
Maintainer metadata when both are specified and instead emit a
Change by Nick Coghlan :
--
pull_requests: +5914
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33042>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
The linked PR has the draft test case for this - it goes beyond the ones I used
to find the cause of the problem by actually checking that sys.warnoptions and
sys._xoptions have been populated as expected
Nick Coghlan added the comment:
(Adding the other import system maintainers to the nosy list, along with Ned as
the release manager for 3.6 and 3.7)
Summarizing my current thoughts on this:
I think the fact that "-m" currently adds the empty directory as sys.path[0]
instead of
Nick Coghlan added the comment:
Over in https://bugs.python.org/issue33053#msg314192, I came up with
`--basepath ` as another possible spelling (`--no-basepath` would then be
an option for turning it off.
The main argument *against* that name is that we use "base" to mean
Nick Coghlan added the comment:
Thinking about PySys_AddWarnOptionUnicode a little further, I'm not sure we
actually need to change anything in the implementation there - I think we can
just make it clearer in the docs that *only* PySys_AddWarnOption is supported
prior to Py_Initializ
Nick Coghlan added the comment:
Brett or Eric, any chance one of you could run with this for 3.7b3? I already
have a startup refactoring related regression that I'm aiming to have fixed
before then.
Thanks to Victor's refactoring work, there's at least a clear interception
Nick Coghlan added the comment:
Heh, apparently I forgot how IMPORT_FROM currently works some time between 2015
and 2017 :)
I agree this is out of date now, as the requested behaviour was already
implemented for 3.7
--
resolution: -> out of date
stage: -> resolved
status
Nick Coghlan added the comment:
Aye, this is the issue for making the API public, so it will stay open until
PEP 432 is actually accepted.
We switched to the pre-implement-changes-as-an-internal-CPython-refactoring
approach after we/I realised there was no feasible way to develop and
Nick Coghlan added the comment:
This is deliberate, and is covered in the documentation at
https://docs.python.org/3/using/cmdline.html#cmdoption-m where it says 'If this
option is given, the first element of sys.argv will be the full path to the
module file (while the module file is
New submission from Nick Coghlan :
Paul brought up recently [1] that with pip 10.0.0 due for release next month
[2], we'd really prefer to ship that in Python 3.7.0 (such that 3.7 launches
with PEP 518/517 pyproject.toml support), rather than shipping with 9.0.x and
then upgrading to 1
Nick Coghlan added the comment:
Possibly - we implemented ensurepip the way we did just because it was the
easiest option, not because we closely considered all the available approaches.
That would be a separate process improvement issue, though
Nick Coghlan added the comment:
PR has been updated to be mostly complete (just pending docs changes now), but
I think I've found a potential issue with the interaction between the way I've
currently implemented it and the way _Py_InitializeCore and
_Py_InitializeMainInterp
Nick Coghlan added the comment:
I added the new test case, and found to my surprise that it didn't fail, even
in debug mode (where there aren't any default filters).
The point I had missed was that even though warnoptions can be NULL in
CoreConfig, _Py_MainInterpreterConfig_Read en
New submission from Nick Coghlan :
While working on https://bugs.python.org/issue33042, I found it hard to keep
track of which kind of config struct a particular piece of code was referencing.
As a particularly relevant example, we currently have 3 different "warnoptions"
fields: t
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue33053>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +5970
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
PR posted with the change to use an absolute path for the starting working
directory in the "-m" case.
That PR also includes a change to improve the fidelity of the test suite: back
when I first wrote test_cmd_line_script, I was mainly focused on t
Nick Coghlan added the comment:
It turned out some tests in CPython's own test suite were implicitly relying on
the old behaviour where the current working directory automatically ended up on
sys.path (see the changes to test_bdb and test_doctest in the updat
Nick Coghlan added the comment:
While I've merged an initial fix for this (so it should be working again in
3.7.0b3), I'm not going to close the issue until folks have had a chance to
review and comment on the linked list based approach I've taken.
--
versio
Change by Nick Coghlan :
--
pull_requests: +5973
___
Python tracker
<https://bugs.python.org/issue33053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Initial fix has been merged to master, CI runs pending for the backport to 3.7
and a follow-up master branch PR to remove a debugging print I noticed when
resolving a test_import conflict in the backport.
I won't get to merging those until some time after
Change by Nick Coghlan :
--
pull_requests: +5974
___
Python tracker
<https://bugs.python.org/issue33053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
3.7 CI finished before I logged off for the night, so this is good to go for
3.7.0b3 now :)
--
priority: release blocker -> normal
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
New changeset a9e5d0e9ef27b14e34631d415e727a07d0f63bef by Nick Coghlan in
branch 'master':
bpo-33053: Remove test_cmd_line_script debugging print (GH-6237)
https://github.com/python/cpython/commit/a9e5d0e9ef27b14e34631d415e727a
Nick Coghlan added the comment:
Marking as fixed, since this is now the version likely to go out in 3.7.0b3 -
if we find further problems with it (beyond the potential enhancement discussed
above to make local directory usage opt-in), then those can go in a new issue.
--
resolution
Nick Coghlan added the comment:
New changeset bc77eff8b96be4f035e665ab35c1d06e22f46491 by Nick Coghlan in
branch 'master':
bpo-33042: Fix pre-initialization sys module configuration (GH-6157)
https://github.com/python/cpython/commit/bc77eff8b96be4f035e665ab35c1d0
Nick Coghlan added the comment:
New changeset d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b by Nick Coghlan in
branch 'master':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231)
https://github.com/python/cpython/commit/d5d9e02dd3c6df06a8dd9ce75ee9b5
Nick Coghlan added the comment:
New changeset ee3784594b33c72c3fdca6a71892d22f14045ab6 by Nick Coghlan in
branch '3.7':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231) (#6236)
https://github.com/python/cpython/commit/ee3784594b33c72c3fdca6a71892d2
Nick Coghlan added the comment:
Harmut, thanks for the status update!
Victor, the problem is that both sys.warnoptions and sys._xoptions get read by
Py_Initialize(), so setting them afterwards is essentially pointless - while
you do still change the contents of the sys attributes, doing so
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
Just noting that while I've closed this issue as fixed, I think we still have
quite a bit of work to do to get our handling of these pre-init config settings
to a place we're genuinely happy with (or as happy as backwards compatibility
constrai
Nick Coghlan added the comment:
I wouldn't expand the scope of contextlib.suppress, since it has a pretty clear
purpose: pretend the exception never happened. (This was even clearer with the
original "ignored" name, before I was talked into changing it to use the
current m
New submission from Nick Coghlan :
warnings.warn() offers a stacklevel parameter to make it easier to write helper
functions that generate warnings - by passing "stacklevel=2", you can ensure
the warning is attributed to the caller of the helper function, rather than to
the helpe
Nick Coghlan added the comment:
Given that issue 32002 and issue 30672 track the known challenges in testing
the expected locale coercion behaviour reliably, I'm going to go ahead and
close this overall implementation issue (the feature is there, and works in a
way we're happy w
Nick Coghlan added the comment:
Calling initexternalimports InitalizeMainInterpreter and from new_interpreter
is right, since we only want these importers on the metapath after we know
sys.path has been configured appropriately.
It's the call from InitializeCore that's questionable
Nick Coghlan added the comment:
It's a useful data point for folks trying to diagnose post-maintenance-update
failures when we upgrade pip on their behalf, rather than them explicitly doing
it themselves.
--
___
Python tracker
&
Nick Coghlan added the comment:
Added Łukasz to the nosy list, as I'd like his +1 before accepting this change
(I do still think it's a good idea, for the same reasons we added
partialmethod).
--
nosy: +lukasz.langa, ncoghlan
___
Pyth
2301 - 2400 of 6301 matches
Mail list logo
