Change by Nick Coghlan :
--
pull_requests: +8689
___
Python tracker
<https://bugs.python.org/issue34589>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Same problem here. However, checking the test code, it seems that what's
happening is that even though the sending socket has been put into non-blocking
mode, self.cli.sendto in the _testCongestion helper method invoked by the
ThreadableTest base class [1
Nick Coghlan added the comment:
The actual functional error is that the following will currently give different
outputs on Fedora and CentOS 7, whereas in the original PEP 538 implementation
it would always print "C", even if locale coercion would otherwise normally
work on yo
Nick Coghlan added the comment:
For the PYTHONCOERCECLOCALE=warn case, it turns out that my preferred approach
to implementing bpo-34589 also naturally ends up respecting -I and -E for that
(i.e. supplying -I or -E will suppressed the warning).
However, my upcoming PR for that also
Nick Coghlan added the comment:
Reviewing the way things are now, I don't think it's worth rearranging this yet
again for 3.7 - instead, I'll just put it back the way I intended it to be (and
the way the PEP describes) for 3.8.
The issue is that Victor had good reasons for moving
Nick Coghlan added the comment:
Respecting -E and -I isn't a problem per se - the problem is moving the
_Py_CoerceLegacyLocale call to a point that's incredibly late in the startup
process *just* to get it to respect those flags.
I don't actually mind if you reinstate the extra pass through
Nick Coghlan added the comment:
FWIW, this is also why I don't want PEP 432 to expose any wstr fields in the
configuration settings: it means embedding applications have to figure out
which encoding Python is expecting to be used for those fields.
Everything should be much cleaner
Nick Coghlan added the comment:
(The one exception to "nothing gets decoded incorrectly" is that
PYTHONCOERCECLOCALE itself is always interpreted as an ASCII field: the values
that it checks for are actually ASCII byte sequences, not Unicode code points.
The documentation could
Nick Coghlan added the comment:
The entire change affecting the PEP 538 implementation in
https://github.com/python/cpython/commit/9454060e84a669dde63824d9e2fcaf295e34f687#diff-8c018c3ada66d06c8e101e47a313c2c7
needs to be reverted: the locale should be coerced before *ANY* calls are made
Nick Coghlan added the comment:
My guess as to why we're only seeing this for parallel test cases is taht for
sequential tests, the implicit import inside open() is unlikely to happen while
test_pkg is running, whereas for parallel tests, test_pkg will run in a
relatively pristine process
Nick Coghlan added the comment:
Serhiy's analysis sounds right to me - for precompiled bytecode files, we
really want co_filename to reflect the import time filename *not* the compile
time filename.
While zipimport is one way to get the compile time and import time paths to
differ
Nick Coghlan added the comment:
Given that importlib is essentially just doing "listdir", it would be
interesting to know how the following behaves in a tight loop on affected
systems:
# Write a file
f = open(os.path.join(dirname, "testname.py"), &quo
Nick Coghlan added the comment:
This has now been merged.
Thanks for the multiple iterations on the implementation Carl, and thanks for
the original proposal, Omer!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Nick Coghlan added the comment:
Yeah, there were some good reasons I went with the relatively brute force
option of provideding Blender with a new config API call back in bpo-16129 - as
we've seen, actually fixing it properly has been a multi-year multi-person
effort :)
--
nosy
Nick Coghlan added the comment:
New changeset d658deac6060ee92b449a3bf424b460eafd99f3e by Nick Coghlan (Carl
Meyer) in branch 'master':
bpo-21145: Add cached_property decorator in functools (#6982)
https://github.com/python/cpython/commit/d658deac6060ee92b449a3bf424b460eafd99f3e
Nick Coghlan added the comment:
The current error message is also outright incorrect, since simple names *are*
valid expressions - the actual problem being reported is that binary
expressions (veky's case) and strings (my case) *aren't* identifiers
Nick Coghlan added the comment:
I just ran into this, and found the existing error message *incredibly*
confusing. My immediate reaction was "There's no keyword in that line, what are
you complaining about?".
An error message that said "Keyword argument name must be an id
Nick Coghlan added the comment:
Nothing has changed recently in the PEP 538 implementation itself, and both
those builders were green last month:
* https://buildbot.python.org/all/#/builders/60/builds/181
* https://buildbot.python.org/all/#/builders/79/builds/185
The first failing debug
Nick Coghlan added the comment:
My comment wasn't about the 3.7.0 -> 3.7.1 fix, but rather about the fact that
I suspect that 3.7.1 is now going to respect some environment variables in this
case that 3.6.x ignored. I don't know for sure though, since we didn't have a
test c
Nick Coghlan added the comment:
While I'd be inclined to agree with Paul's analysis if CPython were a
greenfield project, I also think if SageMath had already been ported to Python
3.2, we would have considered this change a behavioural regression between 3.2
and 3.3 resulting from
Nick Coghlan added the comment:
Regarding PEP 302 compliance: until Python 3.3, the builtin import system
wasn't present on sys.metapath - it was its own implicit legacy thing. The
change in Python 3.3 was to fix that, and make it work based on a handful of
default sys.metapath entries
Nick Coghlan added the comment:
Agreed, but it's still a definition time bug, as the types are only nulling out
tp_new after creating the singleton instance, and not preventing __new__ from
resolving.
If they *don't* null out tp_new, but instead set tp_new to a common helper
function
Nick Coghlan added the comment:
As others have noted, dynamically reloading CPython extension modules is akin
to dynamically reloading any other C/C++ shared library, so it has enough
opportunities for things to go wrong that we consider allowing the shared state
to persist across
Nick Coghlan added the comment:
Looking at the code in
https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/sysmodule.c#L2360,
I think the underlying problem here is that the code to make these
PyStructSequence subclasses uninstantiable isn't really right
Nick Coghlan added the comment:
As a completely minimal strawman design that's the closest fit to what SafeMath
is already doing: what if there was a "linecache.fallback_source_path"
attribute that linecache searched with importlib whenever a loader returned
None to indicate that
Nick Coghlan added the comment:
This problem isn't unique to Cython extension modules - it exists for pyc-only
distribution of pure Python files as well.
The underlying problem is that we don't currently have a mechanism comparable
to JavaScript source maps, whereby a preprocessed runtime
Nick Coghlan added the comment:
It isn't currently feasible to do anything along these lines, as the CPython
runtime is highly configurable, so it's far from clear what, if anything, could
be shared from run to run, and nor is it clear how the interpreter could check
whether
Nick Coghlan added the comment:
I believe Victor is at the EuroPython sprints as well, so if I'm right about
that, I think the best option would be for the two of you to work out a
resolution for 3.7.1 in person that at least keeps the test suites reasonably
consistent, even
Nick Coghlan added the comment:
Mark & Tim: thanks for the discussion and clarifications above, I learned some
new things myself!
Sanyam: thanks for the patch, and for your patience while we figured out what
we wanted the new wording to actually say :)
(Technically the backport
Nick Coghlan added the comment:
New changeset b4bc5cab82e6855e4ebc33ba0b669ddffad30fb3 by Nick Coghlan (Sanyam
Khurana) in branch 'master':
bpo-29710: Clarify documentation for Bitwise binary operation (GH-1691)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
This seems closely related to the work Victor is already pursuing to resolve
bpo-34170 for Python 3.8 (e.g.
https://github.com/python/cpython/commit/56b29b6d6fa3eb32bb1533ee3f21b1e7135648a0
).
The bpo-34170 changes are more invasive than we'd like
Nick Coghlan added the comment:
Next steps:
- add a test case that runs the same sys.flags checks as in
https://github.com/python/cpython/commit/d7ac06126db86f76ba92cbca4cb702852a321f78,
but as a test_embed embedding test using Py_Initialize rather than Py_Main
- create a shared internal
Nick Coghlan added the comment:
Ned, I think we should consider this a release blocker for 3.7.1
--
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Comparing to Python 3.6, we can see that the code to update the C global flags
from the environment variables used to live directly in
_PyInitializeEx_Private:
https://github.com/python/cpython/blob/9d85856044a2c7d681ea38b5ff99af375b228a0f/Python
Nick Coghlan added the comment:
Ah, wait - I see a relevant difference: the test case for issue31845 uses
Py_Main, *not* Py_Initialize (since it's a command line test, not an embedding
test).
That means it's currently possible for the sequence of operations in
https://github.com/python
Nick Coghlan added the comment:
This feels like a duplicate of https://bugs.python.org/issue31845 (see
https://github.com/python/cpython/commit/d7ac06126db86f76ba92cbca4cb702852a321f78
)
Is this definitely with the 3.7.0 release, or is it potentially with one of the
earlier alphas before
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +7964
___
Python tracker
<https://bugs.python.org/issue34206>
___
___
Python-bugs-list mailin
Nick Coghlan added the comment:
Since we decided the correct resolution here was to restore the Python 3.6
behaviour, I've filed https://bugs.python.org/issue34206 as a separate docs
clarification issue (I'll amend my PR accordingly)
--
resolution: -> fixed
stage: patch rev
Change by Nick Coghlan :
--
dependencies: +Do we support calling Py_Main() after Py_Initialize()?
___
Python tracker
<https://bugs.python.org/issue34206>
___
___
New submission from Nick Coghlan :
In resolving issue 34008, we determined that we *do* support calling Py_Main
after Py_Initialize, but it's not clear from that current documentation that
this implies a Py_Finalize() call, so you don't need to call that again
yourself (and it's actually
Nick Coghlan added the comment:
I think the way modules display this information may actually provide a solid
precedent that addresses the dynamic state problem I'm concerned about: filter
the subclass list to only include subclasses that come from the same module as
the object being
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
401 - 500 of 6264 matches
Mail list logo
