Nick Coghlan added the comment:
This is a UX problem folks: dynamic unbounded lists are inherently problematic
in a line based information display.
For methods on a class, there's the natural constraint that broad class APIs
are a problem for a variety of reasons, but there's no such design
Nick Coghlan added the comment:
It's still the same problem - the underlying issue is that the with statement
machinery doesn't currently mask signals in the main thread while __enter__ and
__exit__ are running, so __enter__ and __exit__ methods written in Python are
also at risk of being
Nick Coghlan added the comment:
+1 from me for the idea of fixing Python 3.7 to correctly set sys.argv in this
case (and leaving everything else unmodified).
As far as further enhancement in Python 3.8 goes, perhaps that can be seen as
part of PEP 432, such that embedding applications have
Nick Coghlan added the comment:
Aye, this is a specific case of the general issue noted in
https://bugs.python.org/issue29988 (while it may be partially mitigated by
https://bugs.python.org/issue32949, it isn't a guarantee)
--
resolution: -> duplicate
stage: -> resolved
Nick Coghlan added the comment:
Note that an alternative option for clarifying the status of the "Are they
types or factory functions?" builtins would be for someone to review
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
and compare it to th
Nick Coghlan added the comment:
Marking memoryview, range, and tuple explicitly as classes, and making the
initial phrasing in the docs consistent across all the builtin
collection/container types sounds like a good improvement to me.
I agree with Raymond that we should leave whether
Nick Coghlan added the comment:
Ah, "the internal representation" was meant to refer a hypothetical
representation, rather than literally to CPython's actual implementation, but
now that you point it out, I agree my wording is ambiguous. I like Tim's
suggested r
Nick Coghlan added the comment:
OK, that makes sense to me. Given that, there'd be two changes proposed.
1. Replace the opening paragraph of
https://docs.python.org/3/library/stdtypes.html#bitwise-operations-on-integer-types
(the one I originally quoted when opening this issue
Nick Coghlan added the comment:
The restriction of the footnote to ``x & y``, ``x | y``, and ``x ^ y`` was
going to come from the fact that only those rows in the table will reference
the new note. However, it likely makes sense to repeat the relevant expressions
in the footnote as
Nick Coghlan added the comment:
I think we have a fairly different notion of what clarity means here - I have
no mental concept whatsoever of how to do two's complement arithmetic with an
infinite number of sign bits (I learned most of what I know about two's
complement by working
Nick Coghlan added the comment:
Reviewing the builtins in 3.7, I get the following results for builtin objects
that have defined subclasses immediately after interpreter startup:
=
>>> for name, obj in vars(builtins).items():
... if isinstance(obj, type) and name i
Nick Coghlan added the comment:
Right, the merged PR adds a simpler example that handles "ignore exceptions or
not" by selecting between suppress() and nullcontext().
The documentation still needs updating to improve or remove the file-based
example, and point out that for
Nick Coghlan added the comment:
Merged to master and 3.7 - any further wording tweaks can be handled as a
trivial docs-only PR, without needing additional tracker issues.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
title: Document
Nick Coghlan added the comment:
New changeset 5fe7c98a54d127759cfce323fab831008c945964 by Nick Coghlan in
branch 'master':
bpo-34009: Expand on platform support changes (GH-8022)
https://github.com/python/cpython/commit/5fe7c98a54d127759cfce323fab831008c945964
Nick Coghlan added the comment:
Thinking about this some more, I'm inclined to go the same way we did with
issue 33932: classify it as an outright regression, work out the desired
requirements for a missing embedding test case, and then fix the implementation
to pass the new test case.
My
Nick Coghlan added the comment:
New changeset c287545d62edf1a1ee65727d3c57befa8c99c13a by Nick Coghlan (Daniel
Porteous) in branch 'master':
bpo-34067: Include a more easily understood example for nullcontext (GH-8158)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
While Greg Smith and I both cringed at the idea when I first raised it, I'm
becoming more and more convinced that the only way we're going to be able to
make resource cleanup reliable is for with statements to have the ability to
disable signal handling while
Nick Coghlan added the comment:
New changeset 3f4d90d4d72921f16babd3f52d7df804916af224 by Nick Coghlan (Serhiy
Storchaka) in branch 'master':
bpo-34066: Disabled interruption before SETUP_WITH and BEFORE_ASYNC_WITH.
(GH-8159)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
encodings is only the *first* unfrozen Python module that we load - once you
get past that, then you'll find that we also load os.py and various other
things.
cx_freeze is an illustrative example to look at in that regard, as it
preconfigures the interpreter
Nick Coghlan added the comment:
That's certainly similar to the problems with contextlib.nested, but I don't
think it's as inherently flawed as nested was. What I'd suggest we change the
existing example to is this:
from functools import partial
from os import fspath
def
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue34057>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Aye, and I think from Miro's comments on your PR, making it apply some of the
same configuration settings that 3.6 and earlier applied is going to be
required to get fontforge working again for 3.7.
At the very least, the call to set sys.argv is needed
Nick Coghlan added the comment:
Given the update in
https://github.com/deadsnakes/travis-ci-python3.7-example#update-2018-07-03,
I've simplified the PR to remove any references to Travis CI, and instead just
mention the code names for the relevant Debian and Ubuntu releases.
I've also kept
Nick Coghlan added the comment:
To avoid confusing the discussions, two PEPs is likely a better option:
1. Designing and implementing a dedicated preload mechanism
2. Adjusting the way pth file handling works, including deprecating and
removing the "pth arbitrary file execution&q
Nick Coghlan added the comment:
I've updated the PR to match my current understanding of the situation with
Debian 8 and Ubuntu 14.04.
--
stage: needs patch -> commit review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Removing 3.6 from the affected versions, since we re-arranged these docs a bit
for 3.7 to make it clearer which functions could be called prior to
initialization, as well as adding more tests for the actual pre-init
functionality.
Since 3.6 isn't going
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +7632
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
At the very least, I think this calls for a documentation change, such that we
make it clear that:
1. The expected calling pattern is to call Py_Main() *instead of*
Py_Initialize(), since Py_Main() calls Py_Initialize().
2. If you do call Py_Initialize
Nick Coghlan added the comment:
Yeah, I've asked Miro to try essentially that in
https://bugzilla.redhat.com/show_bug.cgi?id=1595421#c12
My concern is that Py_Main used to keep a *lot* of state on the local C stack
that we've now moved into the main interpreter config.
So my suspicion
Nick Coghlan added the comment:
Also adding Łukasz to the nosy list, since it was his comment from a few weeks
ago on the Travis CI ticket that prompted my "dist: xenial" suggestion.
--
nosy: +lukasz.langa
___
Python track
Nick Coghlan added the comment:
OK, given the above feedback, the PR I've created isn't right yet, but it at
least shows where any information that we can provide on this point will end up.
--
stage: patch review -> needs patch
___
Python trac
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +7631
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Nick Coghlan :
As noted in https://github.com/travis-ci/travis-ci/issues/9069, Travis CI's
Ubuntu 14.04 environment includes an OpenSSL that's too old to meet Python
3.7's security requirements.
According to
https://github.com/travis-ci/travis-ci/issues/9069#issuecomment
Nick Coghlan added the comment:
Answering Eric's question about the flag variables though:
* pymain_get_global_config copies the global variable flags to their respective
struct entries
* pymain_set_global_config copies the various struct entries to their
respective global variable flags
Change by Nick Coghlan :
--
nosy: +emilyemorehouse
___
Python tracker
<https://bugs.python.org/issue34008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I filed https://bugs.python.org/issue34008 to cover the fact that
"Py_Initialize(); Py_Main();" doesn't work in 3.7.0 whereas it used to sort of
work (by only partially applying the settings read from the CLI and environment
by the Py_Main() cal
New submission from Nick Coghlan :
In the current documentation, Py_Main is listed as a regular C API function:
https://docs.python.org/3/c-api/veryhigh.html#c.Py_Main
We also didn't add Py_Main() to
https://docs.python.org/3/c-api/init.html#before-python-initialization when we
did
Nick Coghlan added the comment:
Victor, could you file a separate issue for Py_Main(). It's a different
problem, since Py_Main() is an entry point for an *application that embeds
Python*. It's not a CPython API in the tradition sense
Nick Coghlan added the comment:
I think we also need to clearly separate two distinct aspects of .pth files:
1. "import ; " lines <--- Kill it
with fire
2. "" lines <--- This is fine and good and
perfectly sensible
It's point 2 that powers things like &quo
Nick Coghlan added the comment:
If C level iterator implementations in the standard library natively handled
Ctrl-C (to cope with naive third party C level iterator consumers), and so did
C level iterator consumers in the standard library (to cope with with naive
third party C level
Nick Coghlan added the comment:
I went ahead and closed my PR, as I'm now happy that keeping this behaviour
isn't going to block anything we want to do for PEP 432.
If we change our minds and decide we want to deprecate the current behaviour
after all, then we can start that deprecation
Nick Coghlan added the comment:
https://github.com/python/cpython/pull/7967 amends the docs and adds the
deprecation notices, but after taking another look at the way Victor's patch
works, I'm thinking we may not need them: the *new* initialization API remains
strict about the required
Change by Nick Coghlan :
--
pull_requests: +7574
___
Python tracker
<https://bugs.python.org/issue33932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Ah, part of the confusion is that I misremembered the command we run implicitly
during startup - it's only `setlocale(LC_CTYPE, "")`, not `setlocale(LC_ALL,
"")`.
However, the default category for `locale.getlocale()` is `LC_CTYPE`, so
Nick Coghlan added the comment:
Similar to closing, we have dedicated context managers for stdout and stderr
redirection now:
https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout
Redirecting stdin could be a good example though, since we've so far chosen
Nick Coghlan added the comment:
The purpose would be two-fold:
1. The presence of the `check_signals()` wrapper provides a way to more
explicitly document that the other itertools iterators *don't* implicitly check
for signals, so if you want to combine them with consumers that also don't
Nick Coghlan added the comment:
Thinking about the generator-iterator case a bit more, "False" would be a bad
default for that. Allowing "NotImplemented" to indicate the ambiguous "Might be
finite, might be infinite" state, and using that as the default f
Nick Coghlan added the comment:
As a potential stepping stone towards possible future changes in the default
behaviour here, what if itertools were to offer an opt-in "check_signals(itr,
*, iterations=100_000)" helper function that was essentially a more efficient
version of:
Nick Coghlan added the comment:
(I've updated the issue title to state the design requirement, rather than one
potential solution to the design requirement)
I like the declarative `__infinite_iterator__` suggestion, as that's:
1. really easy to implement when defining a custom iterator type
Nick Coghlan added the comment:
This statement is no longer correct: "when python starts, it runs using the C
locale, on any platform (Windows, Linux, BSD), any python version (2, 3...),
until locale.setlocale() is used to set another locale."
The Python 3 text model doesn't wor
Nick Coghlan added the comment:
Back on the original hash seed topic:
1. The exact size of the seed ranges from 128 bits (SIPHash) to 32-bits
depending on exactly which hash algorithm you're talking about
(https://www.python.org/dev/peps/pep-0456/#hash-secret)
2. While PEP 456 doesn't
Nick Coghlan added the comment:
New changeset ea737751b10fff752aafed0231e8a02b82ba365d by Nick Coghlan (Zackery
Spytz) in branch 'master':
bpo-33451: Close pyc files before calling PyEval_EvalCode() (GH-7884)
https://github.com/python/cpython/commit/ea737751b10fff752aafed0231e8a02b82ba365d
Nick Coghlan added the comment:
I'm thoroughly open to co-author requests for PEP 432 - the "Let's implement it
as a private API for Python 3.7 and see what we learn from the experience" plan
worked beautifully, but it *also* means the PEP text is now woefully out of
date wi
Nick Coghlan added the comment:
Brett pointed out that may initial reaction above came across as quite blunt
and demanding, so attempting to phrase that more clearly as a user experience
consideration:
It may be tempting to view this as purely a clean-up of the import system
implementation
Nick Coghlan added the comment:
Concrete use case for the original path extension capability: "pew add", which
chains virtual environments together (allowing shared environments with a
common default dependency set, and then additional per-application de
Nick Coghlan added the comment:
Strong -1 without a functional replacement that provides comparable LD_PRELOAD
capabilities (it also needs a full PEP that analyses all of the ways that
setuptools and other packaging utilities use these files, such as for the
implementation of "develop&
Nick Coghlan added the comment:
Using OverflowError wouldn't mean "I'm infinite", it would only mean "I'm
larger than sys.maxsize" (the same way it does for range objects).
However, it may be that that's fine, since the information we really want to
convey is:
Nick Coghlan added the comment:
OverflowError covers cases like greater-than-sys.maxsize range instances, where
the object itself is conceptually finite, but the length can't be represented
as a C integer.
This case is different: it's a category error where the question being asked
doesn't
Nick Coghlan added the comment:
Note: I've filed the "raise TypeError in __length_hint__" suggestion for
infinite iterators separately in https://bugs.python.org/issue33939
--
___
Python tracker
<https://bugs.python.o
New submission from Nick Coghlan :
This is a simpler proposal born out of https://bugs.python.org/issue31815:
adding __length_hint__ implementations to some known-infinite iterators in
itertools that always raise TypeError.
This means that iterator consumers that use the operator.length_hint
Nick Coghlan added the comment:
Aye, I'm fine with deferring the programmatic deprecation for now - it's mainly
the docs I'd like to see changed at the same time as the regression is fixed.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
While I agree the documentation issue means that this should be made to work
again for Python 3.7.1, I'd like for Python 3.7 to at least deprecate calling
Py_Initialize twice without an intervening Py_Finalize.
Otherwise the public multi-phase interpreter
Nick Coghlan added the comment:
New changeset 16eb3bcdb22be4d82dc597b92b7154fcb11c6479 by Nick Coghlan in
branch 'master':
bpo-33499: PYTHONPYCACHEPREFIX What's New entry (GH-7749)
https://github.com/python/cpython/commit/16eb3bcdb22be4d82dc597b92b7154fcb11c6479
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 change
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 is building
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:
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 -> re
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/cpython/commit
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.html
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:
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'm going
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 binary
Change by Nick Coghlan :
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue11874>
___
___
Pyth
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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/1bcb8a636857e3383d65aaf196f93edb949f2e79
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, though, since
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 imported
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:
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:
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 adhere closely
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:
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/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
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/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
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/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
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/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
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
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 release process
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/cpython/commit
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:
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 this based
Change by Nick Coghlan :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31014>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: compile error -> behavior
___
Python tracker
<https://bugs.python
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
Nick Coghlan <ncogh...@gmail.com> 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 <rep...@bugs.python.org>
<https://bugs.python
Nick Coghlan <ncogh...@gmail.com> 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 reader
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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 defin
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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
W
Nick Coghlan <ncogh...@gmail.com> 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.pyth
501 - 600 of 8215 matches
Mail list logo
