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 wo
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 reso
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/5fe7c98a54d127759cfce323fab831
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
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/cpyt
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 hand
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/cpyt
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 interp
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 impo
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 n
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
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
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 goi
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 su
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
___
P
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/90
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
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(
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
di
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 tradi
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
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 d
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 th
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`
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 no
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
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 ite
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'
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 do
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/ea737751b10fff752aafed0231e8a0
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 o
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
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 aske
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.pyt
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
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 interp
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/16eb3bcdb22be4d82dc597b92
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
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
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 -&g
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:
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:
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&
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
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/1bcb8a636857e3383d65aaf196f93e
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:
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:
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 adhe
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/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
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:
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
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
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 thi
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 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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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 McElwaine added the comment:
Thankyou for clearing that up!
On 18 May 2018 at 13:05, Berker Peksag wrote:
>
> Berker Peksag added the comment:
>
> Thanks for the report. I agree with Eryk. os.get_terminal_size() is a
> low-level function. shutil.get_terminal_size() sh
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:
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:
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:
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
501 - 600 of 6508 matches
Mail list logo