Nick Coghlan added the comment:
Thanks for the feedback and updates folks! If we decide to make any further
changes, I think they will be best handled as a new issue :)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Nick Coghlan added the comment:
I updated some of the issue metadata and added a question mark to the issue
title to help make it clearer that this would require a PEP level conceptual
enhancement to the language, rather than being about documenting an existing
concept.
PEP 557's
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue32225>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan :
For documentation of this feature, I'd suggest adding a new subsection after
https://docs.python.org/3/reference/datamodel.html#customizing-attribute-access
(but at the same level), called "Customizing module attribute access".
That can then
Nick Coghlan added the comment:
This is still a valid docs issue, although PEP 562's module __getattr__ and
__dir__ will provide a simpler alternative for most of the cases that
previously required setting the __class__ attribute:
https://www.python.org/dev/peps/pep-0562/
So I
Nick Coghlan added the comment:
New changeset 9c19b020249c451891affd81751947321a1e6957 by Nick Coghlan in
branch 'master':
bpo-32002: Refactor C locale coercion tests (GH-4369)
https://github.com/python/cpython/commit/9c19b020249c451891affd81751947
Nick Coghlan added the comment:
Regarding super().__init__(): I added ExitStack to contextlib2 first, so I was
thinking in the Py2/3 compatible subset when I wrote the original docs. We can
freely change that for the standard library recipes.
Regarding the "how to create a copy"
Nick Coghlan added the comment:
Declaring "I intend for instances of this class to be immutable" isn't a fuzzy
concept - it's in the same vein as other type hints, like "I intend for this to
be a string". The part that's fuzzy is how well Python actually en
Nick Coghlan added the comment:
When executing a sys.path entry, you're executing that *entire* entry (whether
it's a directory or zipfile). This isn't a bug, and it isn't in conflict with
the assurances offered by isolated mode (it would only be a problem if running
Nick Coghlan added the comment:
(However, the behaviour Steve is describing suggests that sys.path[0]
initialisation may have problems on Windows that the test suite isn't picking
up - "-I" should *not* add the script directory to the path, and directory
execution shoul
Nick Coghlan added the comment:
Yep, the requirement for supporting multiple interpreters is just that you
either avoid relying on C global state entirely, or else correctly synchronise
access to it. Multi-phase initialisation just provides a few nudges in the
direction of doing that more
Nick Coghlan added the comment:
_PyCoreConfig.ignore_environment was part of the initial PEP 432 implementation
that I wrote.
It's that due to the design goal that once the refactoring is complete, an
embedding application should be able to control *all* the settings through the
c
New submission from Nick Coghlan :
While discussing https://bugs.python.org/issue32145, I noticed that
ExitStack.callback *always* adds a wrapper function, even when the `args` and
`kwds` parameters are both empty.
For plain callbacks that aren't receiving any extra arguments, it wou
Nick Coghlan added the comment:
I'm not clear on what you mean about allowing arbitrary names for the instance
creation function - at that point we're back to subclasses not being able to
use the default `pop_all()` implementation at all, and needing to duplicate the
state transfe
Nick Coghlan added the comment:
Another point in favour of the JSR approach is that it should make it
easier for tools like coverage.py to continue mapping opcode coverage to
line coverage.
I also like Serhiy's proposed strategy of separating the initial
introduction of the compiler
Nick Coghlan added the comment:
Would it be possible to deprecate (or at least stop enhancing) the current
datetime C API and add a new capsule based one instead?
We're trying to get extension module authors to *stop* relying on C level
globals, since it causes problems with:
- memory
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue31975>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +4929
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
On 31 December 2017 at 01:34, Paul Ganssle wrote:
> That said, I think it would be really good if we could get a fast path for
> timezone creation and access to the UTC singleton into the Python 3.7
> release. I think it's kind of a big dispari
Nick Coghlan added the comment:
https://bugs.python.org/issue32459 covers defining a module-reloading-friendly
way of using capsules.
For this issue, I now think it makes sense to just ignore that problem, and add
whatever you need to the existing API
New submission from Nick Coghlan :
After commenting [1] on the fact that the current datetime module C API [2] is
problematic due to its reliance on C level global variables, I discovered that
this is actually the outcome of our recommended approach to using capsules to
export a C API as
Nick Coghlan added the comment:
As per the comment at https://bugs.python.org/issue32445#msg309356, there's a
bug in my suggested changes to `ExitStack.pop_all()`: the right method to call
is ExitStack.push(), *not* ExitStack.callback() (the latter adds a wrapper
function to mak
Nick Coghlan added the comment:
Ah, you're right, I wasn't thinking clearly when I filed this - the correct
public API method to transfer existing exit stack entries to a new stack would
be "ExitStack.push()".
I'll make a note of that on the original issue.
---
Nick Coghlan added the comment:
Since the problem is specific to Python 2.7 and has been resolved in the
importlib based import implementation, I'm inclined to close this as "Won't
Fix".
The only reason I haven't is that if someone really wanted to dig in
Nick Coghlan added the comment:
Issue 32206 covers doing this for `pdb`. It relies on directly accessing
private APIs in the `runpy` module, but we can live with that, since `pdb` is
part of the standard library.
--
dependencies: +Run modules with pdb, cProfile command-line should
Nick Coghlan added the comment:
Linking back to the overall RFE for improved executable module support for
standard library modules that run other scripts:
https://bugs.python.org/issue9325
--
nosy: +ncoghlan
___
Python tracker
<ht
Nick Coghlan added the comment:
New changeset 9f1e5f1b7f074e026843a5d70834233a95a6bf9d by Nick Coghlan (Mario
Corchero) in branch 'master':
bpo-32206: Pdb can now run modules (GH-4752)
https://github.com/python/cpython/commit/9f1e5f1b7f074e026843a5d7083423
Nick Coghlan added the comment:
Thanks for the patch!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python
Nick Coghlan added the comment:
Re-opening for the CLI help updates.
--
resolution: fixed ->
stage: resolved -> needs patch
status: closed -> open
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
New changeset e46a8af450210ee5c7f0459ad6beddbc626ae60f by Nick Coghlan
(Nathaniel J. Smith) in branch 'master':
bpo-30579: Allow TracebackType creation and tb_next mutation from Python
(GH-4793)
https://github.com/python/cpyt
Nick Coghlan added the comment:
Thanks for the patch!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
+1 for creating separate issues and linking them from this one - while the risk
of breaking anything seems low, if we do cause a regression, multiple issues
and PRs provide better traceability than one giant issue for everything.
(I'm also not aware of a
Nick Coghlan added the comment:
I think https://github.com/python/cpython/pull/4458 is ready to go now, but I
expect it would benefit from a review before I merge it. If anyone has the time
to take a look, it would be much appreciated :)
However, I'd also like to get it in for 3.7.0a4
Nick Coghlan added the comment:
Thanks. I've added the dependencies, and also granted you triage permissions on
the tracker, so you should be able to edit dependencies yourself in the future.
--
dependencies: +Add an option to profile to run library module as a script, Add
an o
Nick Coghlan added the comment:
As David noted, we updated all the URL parsing functions to be polymorphic back
in 3.2:
https://docs.python.org/3/library/urllib.parse.html#parsing-ascii-encoded-bytes
We left the quoting functions alone, because they already had their own way of
dealing with
Nick Coghlan added the comment:
New changeset 9b99747386b690007027c3be2a5d7cfe3d3634f5 by Nick Coghlan in
branch 'master':
bpo-31975 (PEP 565): Show DeprecationWarning in __main__ (GH-4458)
https://github.com/python/cpython/commit/9b99747386b690007027c3be2a5d7c
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
While I do think it makes sense to enhance `dis` in this regard, I'm also
thinking it might be better to have that automatically fall back to a `python
-m inspect module:qualname` style lookup in the event that
`os.path.exists(infile)` is false
Nick Coghlan added the comment:
Adjusting target versions, as even though the status quo leads to mishandling
some input data, the fix is a feature request to make the behaviour
configurable, which restricts the change to 3.7+.
--
nosy: +ncoghlan
versions: -Python 2.7, Python 3.4
Nick Coghlan added the comment:
PSF link for Diana Clark's thread on python-ideas about this:
https://mail.python.org/pipermail/python-ideas/2017-September/047224.html (this
is the same thread Brett linked, just to the PSF archives rather than Google
G
Nick Coghlan added the comment:
If these warnings are being emitted when using setuptools, that's a bug in
setuptools (as it should be ensuring these are handled without warnings), and
can be reported over on https://github.com/pypa/setuptools/
If these warnings are being emitted when
Nick Coghlan added the comment:
I've assigned the PR and issue to myself, as the proposed addition in the PR
isn't quite right, but it isn't immediately obvious why not.
The gist of the problem is that the current docs are actually correct and
complete: modules are the first
Nick Coghlan added the comment:
The behaviour I'd expect to see:
"module:qual.name" -> "imports module, accesses module.qual.name"
"module.qual.name" -> "no implicit import, accesses module.qual.name"
"package.subm
Nick Coghlan added the comment:
As David notes, the issue in the example is the fact that you're setting
"__main__.a", so "a.py" never gets imported as a module - it gets a hit on the
parent module attribute, and hence stops there.
--
resolution: -> n
Nick Coghlan added the comment:
Regarding environment variables, note that they get used in two *very*
different ways:
1. The "persistent shell setting" case that Raymond describes. While setting
PYTHONBYTECODEPATH to always point to a RAM disk could make quite a bit of
sens
Nick Coghlan added the comment:
Ah, sorry, I misinterpreted Petr's comment, and then didn't look at the details
of your PR before commenting.
Having fixed that mistake, I agree that making the naive approach "just work&quo
Nick Coghlan added the comment:
Issue 19251 is still under consideration, so marking this as a duplicate,
rather than as rejected.
--
nosy: +ncoghlan
resolution: rejected -> duplicate
superseder: -> bitwise ops for bytes of equal length
___
Nick Coghlan added the comment:
I'm back in the embedded software world now, and hence working with the
combination of:
- low level serial formats (including fixed length CAN packets)
- C firmware developers that are quite capable of writing supporting
C-in-Python code using the sta
Nick Coghlan added the comment:
This issue isn't at the stage where a PR would help - the core question is
still "Should we add better native support for multi-byte bitwise operations?",
not the specifics of what they API might look like or how we would implement it.
Nick Coghlan added the comment:
Thanks for the link Serhiy (I'd forgotten about the struct changes proposed in
PEP 3118), but the existing struct formatting codes are fine for my purposes.
The question is whether we might be able to avoid some
bytes->Python-objects->bytes cycl
Nick Coghlan added the comment:
I believe the main argument for -X options is the fact that cmd on Windows
doesn't offer a nice way of setting environment variables as part of the
command invocation (hence "-X utf8", for example).
As far as setting values for X options goes,
Nick Coghlan added the comment:
I think Antoine's right that another venue (such as python-ideas) might be a
better venue for this discussion, but I'll still try to explain the potential
analogy I see to bytes.upper()/.lower()/etc: those operations let you treat
ASCII segments in
Nick Coghlan added the comment:
I think it would make sense to remove the exception wrapping from the
__set_name__ calls - I don't think we're improving the ease of understanding
the tracebacks by converting everything to a generic RuntimeError, and we're
hurting the U
New submission from Nick Coghlan :
Type creation currently wraps all exceptions raised by __set_name__ calls with
a generic RuntimeError:
https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7263
Unfortunately, this makes it difficult to use __set_name__ for descriptor
Nick Coghlan added the comment:
I filed https://bugs.python.org/issue33576 to cover removing the exception
wrapping from __set_name__ errors.
--
___
Python tracker
<https://bugs.python.org/issue21
Nick Coghlan added the comment:
Hmm, I wonder if the UX problem with the current chaining might be solved in a
different way, by doing something similar to what we did for codec exceptions
(where we want to try to mention the codec name, but also don't want to change
the exception type
Nick Coghlan added the comment:
While it does match Christian's original suggestion, I'm not taking the "bytes"
in the issue title as literally requiring that the feature be implemented as
operator support on the bytes type (implementing it on memoryview or a new view
ty
Nick Coghlan added the comment:
Yeah, the "transparent exception chaining" code falls into the category of code
that I'm both proud of (since it works really well in typical cases [1]) and
somewhat horrified by (since the *way* it works tramples over several
principles
Nick Coghlan added the comment:
I think the reference to RuntimeWarning in the docs is a typo (if it was only
going to be a warning, it could have been that from the start), and that
reference to RuntimeError in the code comment is correct.
So there's also a docs fix to make in 3.6 an
Nick Coghlan added the comment:
Also see
https://github.com/python/cpython/blob/55edd0c185ad2d895b5d73e47d67049bc156b654/Objects/exceptions.c#L2713
for the version we use in a few places to implicitly update the exception
message, while keeping the exception type and state the same (and
Nick Coghlan added the comment:
Rather than tracking this per object, you could potentially track it per arena
at the memory allocator level instead. Then if you really need the info (e.g.
when running the debug allocator), you can check it in a reliable way, but in
the normal case, you
Nick Coghlan added the comment:
Adding a low level callback based mechanism to ask another interpreter to do
work seems like a good way to go to me.
As an example of why that might be needed, consider the case of sharing a
buffer exporting object with another subinterpreter: when the
Nick Coghlan added the comment:
Yes, while weird, that's expected behaviour.
Rather than being due to absolute vs relative imports, the difference arises
from the fact that in "import pkg.module", the request is explicitly for a
submodule, so the submodule import always happ
Nick Coghlan added the comment:
Ouch, I'd completely missed the fact that this would affect the parsing of bare
strings to a simple AST (I was focused on functions and classes, as in Mark's
original example).
So even though I'm the author of https://bugs.python.org/issue
Nick Coghlan added the comment:
Not as a statement, but you can force it with importlib.import_module:
$ python3 -c "import pkg; pkg.submodule = 1; import importlib;
importlib.import_module('.submodule', 'pkg'); print(pkg.submodule)"
pkg
pkg.submodule
We'
Nick Coghlan added the comment:
Huh, I thought I cleaned those out when I made the compilation unconditional. I
guess not :)
The actual fix looks good to me, but the autoconf regeneration looks
unexpectedly noisy, so I've asked Benjamin Peterson to take a look
Nick Coghlan added the comment:
Just noting that I'm going to attempt an alternative, hopefully lower impact,
approach at implementing the reversion, which will be to modify
Parser/asdl_c.py to inject the following constructor postamble for ASDL nodes
that define both a "b
Nick Coghlan added the comment:
After looking at potential implementation approaches, I believe the following
would be the ASDL code generator changes needed to present the docstring as
part of the body in the Python API, while keeping it as a separate attribute in
the C API:
* in ast2obj
Nick Coghlan added the comment:
Ned, just adding you to the nosy list here, as I don't think this is a release
blocker per se (since nothing's actually *broken*), but the current state of
the PEP 538/540 docs is such that it isn't going to be clear to most readers
why both m
Nick Coghlan added the comment:
I'm aiming for this week, so with the docstring-AST-induced delay I should even
meet the original rc1 goal :)
--
___
Python tracker
<https://bugs.python.org/is
Nick Coghlan added the comment:
In that case, closing this as resolved. Folks interested in the idea of a
"suite" compilation mode to compile a series of statements without
special-casing the first one as a potential docstring, as well as the idea of a
dedicated DocString AST nod
Change by Nick Coghlan :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: compile error -> behavior
___
Python tracker
<https://bugs.python
Change by Nick Coghlan :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31014>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
Updated link to the ABI tracker report:
https://abi-laboratory.pro/tracker/timeline/python/
(The stable ABI report still has a separate entry on
http://upstream.rosalinux.ru/ but it links to the same report as I've linked
above)
I'm bumping thi
Change by Nick Coghlan :
--
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue19982>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
New changeset 9ef1b0690b90c526798b6b3125b0fa7ae98319a2 by Nick Coghlan (Mayank
Singhal) in branch 'master':
bpo-31215: Add version changed notes for OpenSSL 1.1.0 compatibility (GH-7346)
https://github.com/python/cpyt
Nick Coghlan added the comment:
While I wouldn't describe this as completely intentional (as it's an artifact
of the change-and-revert dance with 3.7 previously removing docstring nodes
from the AST entirely), I also wouldn't want to change it again at this late
stage of the
New submission from Nick Coghlan :
Talking to Berker on http://psf.upfronthosting.co.za/roundup/meta/issue644 I
noticed that docs for random.Random are currently embedded in the module
preamble text for https://docs.python.org/3/library/random.html and hence
really easy to miss.
It would be
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c49
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c49
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c49
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c49
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +7172
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
The rationale for documenting it in the porting section is that even though
this isn't a guaranteed stable interface, the output *does* potentially affect
development tools like Ned's coverage.py, as well as other implementations
attempting to adhe
Nick Coghlan added the comment:
Thanks for the PR, and your patience!
The change has now been merged for all active 3.x versions.
It turns out the 2.7 argparse code is still close enough to the 3.x code for
the automated backport to work, so the CI for that is currently running
Nick Coghlan added the comment:
Merged for 2.7 in
https://github.com/python/cpython/commit/458ed1b237150f5c59b6ab3e1a5241a672ac8cbd
Thank you for the PRs, Mayank!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Nick Coghlan added the comment:
I think the key concern here is that we *don't* consistently add modules to
sys.modules in the order their bodies are executed: we add them in a kind of
sawtooth order based on the imports from __main__, and the order of import
statements in the imp
Nick Coghlan added the comment:
It also occurred to me to ask whether or not moving modules to the end of
sys.modules each time they're successfully imported would help solve the
problem (albeit at the expense of making import cache hits more expensive).
I don't think it does, tho
Nick Coghlan added the comment:
New changeset 1bcb8a636857e3383d65aaf196f93edb949f2e79 by Nick Coghlan in
branch 'master':
bpo-33409: Clarify PEP 538/540 relationship (GH-7534)
https://github.com/python/cpython/commit/1bcb8a636857e3383d65aaf196f93e
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue11874>
___
___
Pyth
Nick Coghlan added the comment:
With PEPs 538 and 540 merged for Python 3.7 (so we'll almost always use UTF-8
instead of ASCII when the platform nominates the C or POSIX locale as the
currently active one), and Windows previously switching to assuming UTF-8
instead of mbcs for b
Nick Coghlan added the comment:
We don't have anyone clamouring for this, and the third party module
https://ftfy.readthedocs.io/en/latest/ has a lot more utilities for working
with messy binary inputs and incorrectly decoded text than we'd ever add to the
standard library, so I&
Nick Coghlan added the comment:
Correction: I just rejected my proposed wsgiref in issue 22264 as failing to
make a sufficient case for their practical utility, so that one is closed as
well :)
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
Adding a link to the first post in a series of articles from Victor Stinner
regarding the evolution over time of the text encoding assumptions in Python
3's operating system interfaces:
https://vstinner.github.io/python30-listdir-undecodable-filenames
Nick Coghlan added the comment:
New changeset b193fa996a746111252156f11fb14c12fd6267e6 by Nick Coghlan (Carl
Meyer) in branch 'master':
bpo-33499: Add PYTHONPYCACHEPREFIX env var for alt bytecode cache location.
(GH-6834)
https://github.com/python/cpyt
Nick Coghlan added the comment:
Merged as PYTHONPYCACHEPREFIX=path, -X pycache_prefix=path and
sys.pycache_prefix :)
I'll also update PEP 304 with a note saying a variant of the idea was
eventually accepted for Python 3.8.
--
resolution: -> fixed
stage: patch review -&g
Change by Nick Coghlan :
--
pull_requests: +7357
___
Python tracker
<https://bugs.python.org/issue33499>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
xtreak: if you're familiar with GitHub workflows, then we now accept docs and
code updates as GitHub PRs: https://devguide.python.org/pullrequest/
The parts about running the tests aren't exactly relevant here, what's more
relevant
Nick Coghlan added the comment:
Right, the HTML example was always a bit cutesy (hence the disclaimer in the
header), but it's hard to come up with a good illustrative example that isn't
already a native context manager in the standard library.
Perhaps it would make sense to
2701 - 2800 of 6301 matches
Mail list logo
