Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
New changeset ed57e13df60ce28ba89bd49c9c5a15b1d9bf79c7 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-11191: skip unsupported test_distutils case for AIX with xlc (GH-8709)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
New changeset e2926b72488596f59e43c27f3b7cedf0c5b9e88e by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34373: fix test_mktime and test_pthread_getcpuclickid tests on AIX (GH-8726)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
New changeset 259c159fc1faab0dd631d20374842dc0d6a9f145 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34897: avoid distutils test error when CXX is not set (GH-9706)
https://github.com/python/cpython/commit/259c159fc1faab0dd631d20374842dc0d6a9f145
Nick Coghlan added the comment:
New changeset 2062a20641febad5eb9c18d74e1cfb4d7a6e53ed by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34711: Return HTTPStatus.NOT_FOUND if path.endswith('/') and not a
directory (GH-9687)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
New changeset 22462da70c1ae015a60a7b821547bc6d2b5bc265 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-27643 - skip test_ctypes test case with XLC compiler. (GH-5164)
https://github.com/python/cpython/commit/22462da70c1ae015a60a7b821547bc6d2b5bc265
Nick Coghlan added the comment:
New changeset 5661459f5f508ea4bd24c13cbc861543f283147e by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-11192: Skip unsupported cases in test_socket on AIX (GH-8954)
https://github.com/python/cpython/commit/5661459f5f508ea4bd24c13cbc861543f283147e
Nick Coghlan added the comment:
Note that the above distinction is also the rationale for introducing the new
subtype: so that it's easy to tell the difference between "that module was not
found at all" (ModuleNotFoundError) and "the module was found, but attempting
t
Nick Coghlan added the comment:
The two errors mean different things: ModuleNotFoundError means literally that
the module could not be found at all (i.e. no import hook offered to try to
load it)
A plain ImportError then means that the module was located, but attempting to
actually load
Nick Coghlan added the comment:
Aye, the relevant change here would be the fact that -b and -bb now modify
sys.warnoptions, rather than the warnings module being aware of those command
line options specifically: https://docs.python.org/3/whatsnew/3.7.html#warnings
As a result, unittest.main
Nick Coghlan added the comment:
I still think the current Python 3.7 behaviour makes the CPython runtime a
badly behaved C library, since we may end up changing the active libc locale
even when it isn't the main application, and a change hasn't been explicitly
requested by the embedding app
Nick Coghlan added the comment:
If I've understood https://bugs.python.org/issue35290 and its resolution in
https://github.com/python/cpython/commit/f6e323ce322cf54b1a9e9252b13f93ebc28b5c24
correctly, that's a concrete example of why I consider the early coercion
approach that avoids any
Nick Coghlan added the comment:
Ah, interesting. https://bugs.python.org/issue30672 covered the fact that this
test was already weird on FreeBSD, but the current status is that it was
expecting BSD variants to act somewhat like Mac OS X, not like Linux.
I'm wondering if we may need to make
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue17490>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
I didn't know what was possible when I wrote PEP 432 either - instead, I wrote
down an initial concept for what I *wanted*, and then started exploring the
code to find out the barriers to achieving that.
We know enough now to know that original design concept
Nick Coghlan added the comment:
I think the rules for C includes are that `"path/header.h"` looks next to the
current file first, whereas `` looks only in include directories.
However, given your technique of mostly hiding the new directory name from API
consumers, what do
Nick Coghlan added the comment:
(Retitled the issue to better reflect the underlying feature request)
As Steven describes, there are enough problems with changing range.__repr__
that if that's the proposal, then the only possible answer is "No", and closing
the issue.
However
Nick Coghlan added the comment:
I think the idea makes sense, but find the proposed name potentially confusing
for two reasons:
1. It isn't only about configuration, it's about interpreter initialisation
state in general
2. We use "context" for several other purposes already (mo
Nick Coghlan added the comment:
I like where you're going with this, but would be willing to write an update to
PEP 432 to sketch out in advance what you now think the end state is going to
look like?
Merging the general structure of the draft PEP 432 implementation to make it
possible
Nick Coghlan added the comment:
I agree with Steven and Raymond on this one: changing __repr__ on ranges in a
way that breaks round-tripping through eval would be problematic, especially as
I'd expect that to be an issue in doctests as well.
However, I also like the idea of having easier
Nick Coghlan added the comment:
The discussion with Victor on https://bugs.python.org/issue34914 highlighted
the fact that it's OK to use 8-bit string comparisons to check for "-E", "-I",
and a "-X coerce_legacy_c_locale=0" due to the fact that all encod
Nick Coghlan added the comment:
Noticed this was still open when reviewing Elvis's zipimport patch for issue
34022.
Given the Python implementation has been merged, should we close this as
resolved, and open new issues for any further changes (performance or
otherwise)?
--
nosy
Nick Coghlan added the comment:
New changeset ad1a25f499362eaf9cbfcafa0b8e2454eb43dcf1 by Nick Coghlan (Mario
Corchero) in branch 'master':
bpo-32512: Add -m option to profile for profiling modules (#5132)
https://github.com/python/cpython/commit/ad1a25f499362eaf9cbfcafa0b8e2454eb43dcf1
Nick Coghlan added the comment:
On actually looking at the initial changes in the PR:
* declarations that aren't part of the stable ABI in any version (i.e. "#ifndef
PY_LIMITED_API", "#if !defined(PY_LIMITED_API)") should move to the new
directory
* declarations that ar
Nick Coghlan added the comment:
> To be honest, I'm not sure that I understand how "Py_LIMITED_API+0 >=
> 0x0305" works and should be used.
It's described here: https://docs.python.org/3/c-api/stable.html
If a stable ABI consumer just declares "#define PY_LIMI
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue35134>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I've merged the version that displays up to 4 builtin subclasses in a flat list
when help() is called on a type. Thanks for the patch Sanyam, and for the
comments and suggestions everyone else.
While I'm closing out this feature request as implemented
Nick Coghlan added the comment:
New changeset a323cdcb33c8c856e5668acfb2c67ab5198672c4 by Nick Coghlan (Sanyam
Khurana) in branch 'master':
bpo-8525: help() on a type now shows builtin subclasses (GH-5066)
https://github.com/python/cpython/commit/a323cdcb33c8c856e5668acfb2c67ab5198672c4
Nick Coghlan added the comment:
Your explanation is why this is a docs enhancement proposal rather than a
bug report: as far as we're aware, all encodings that get used as locale
encodings have the property that encoding "-X utf8" with the locale
encoding gives the same answer a
Nick Coghlan added the comment:
Directly addressing the topic of the bug:
Py_SetProgramName() should be a relative or absolute path that can be used to
set sys.executable and other values appropriately. This is used in
Programs/_testembed.c for example.
I didn't know it didn't work
New submission from Nick Coghlan :
While working on the docs updates for bpo-34589 (clarifying that
"PYTHONCOERCECLOCALE=0" and "PYTHONCOERCELOCALE=warn" need both the environment
variable name and the value to be encoded as ASCII in order to have any
effect), I reali
Nick Coghlan added the comment:
Aye, that option sounds like it would work to me (as long as throwing an
exception is counted as finishing execution, so the failed module gets
moved to the end before getting cleaned up)
--
___
Python tracker
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +9033
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Putting back to normal, as the difference between the C locale and the POSIX
locale is that you never get the latter by default - you have to explicitly
request it.
The underlying fix for this is in the PR for bpo-34589.
--
dependencies
Nick Coghlan added the comment:
Especially since the dynamic flexibility of ExitStack comes at a genuine
runtime cost when unwinding the resource stack.
I also (very!) belatedly noticed that I never answered Julian's request for
clarification about the potential grammar ambiguity, so going
Nick Coghlan added the comment:
We added the method names to help provide a nudge that the issue is likely to
be a missing method implementation in the subclassing case, so I'd like to keep
them if we can find a way to make the messages accurate again.
What if we updated the offending
Nick Coghlan added the comment:
Correct - it won't change anything from 3.7.0, and even the original
discrepancies relative to PEP 538 only affect applications that:
1. Are embedding a CPython runtime
2. *Aren't* already ensuring that they're running in a locale other than the C
locale
3
Nick Coghlan added the comment:
Yep, exactly - things are much improved already, thanks primarily to your work,
and it seems likely they'll be even further improved by the time 3.8.0 comes
around :)
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
Note that we've left a similar operand precedence handling issue languishing
for a long time over compatibility concerns: https://bugs.python.org/issue11477
In that case, NumPy is actually benefiting from the discrepancy with the
documentation though
Nick Coghlan added the comment:
python-dev thread with more discussion of the patch:
https://mail.python.org/pipermail/python-dev/2018-September/155188.html
Note that my comment above was based on a misunderstanding of what the patch
does - the module level code still gets executed
Nick Coghlan added the comment:
(Also, the patch is currently still written on the assumption that it won't be
backported to 3.7.1. I haven't checked if it would apply cleanly to 3.7.x, but
I suspect not, given the magnitude of the startup changes targeting 3.8.0 since
3.7.0 was released
Nick Coghlan added the comment:
https://github.com/python/cpython/pull/9257 should be complete now, although I
may have gone overboard on the documentation updates (as it seems to be
unclear, at least to Victor, why PYTHONCOERCECLOCALE exists in the first place
Nick Coghlan added the comment:
The "ill-defined" in Python 3.6 relates to the fact that we never actually
defined or tested which environment variables were read by Py_Main and which
ones were read by Py_Initialize, since the majority of our tests only covered
Py_Main (by launch
Nick Coghlan added the comment:
Something else this would need is a different name that better distinguishes it
from the existing frozen modules, which freeze the bytecode rather than the
resulting module state. (That existing approach avoids the stat overhead, but
still incurs the module
Nick Coghlan added the comment:
(The other reason this change should be reverted is because it added a new
feature to Python 3.7.1, even though in the earlier discussion we had agreed to
leave the as-shipped implementation in 3.7.0 alone for the rest of the Python
3.7.x releases, and only
Nick Coghlan added the comment:
test_c_locale_coercion *did* test the -E and -I options, by running everything
in isolated mode. This was only broken by Victor's changes to the test suite
(which broke locale coercion in isolated mode, and hence broke the tests).
As for why
Nick Coghlan added the comment:
(Note: I won't have time to work on this myself until this weekend at the
earliest)
--
___
Python tracker
<https://bugs.python.org/issue34
Nick Coghlan added the comment:
The only reason this got through my original review was because PEP 540 was
implemented when I was going through a personal situation that lead to me
quitting my job cold without a new one to go to, so my review of Victors
changes to the PEP 538
Nick Coghlan added the comment:
3.7.1 should not ship until PEP 538 is once more implemented as documented,
without Victor's personal editorialising and feature additions to a maintenance
release.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
Victor, no - you've completely broken PEP 538 now.
Please just give up, and implement the PEP as written, and stop trying to use
your copious amounts of available development time to railroad me.
--
___
Python
Nick Coghlan added the comment:
I'd strongly prefer to just go back to the PEP 538 design. It's much simpler to
implement, we don't actually want anyone turning off locale coercion except for
debugging purposes (unlike UTF-8 mode), and the only argument against doing
this the way PEP 538
Nick Coghlan added the comment:
Alternate PR is up at https://github.com/python/cpython/pull/9257
There's one setting that remains in CoreConfig: "warn_on_c_locale", which
_Py_UnixMain also uses to decide whether or not to actually emit the passed in
locale coercion warning.
Th
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
Change by Nick :
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34549>
___
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 added the comment:
Ah, yes! Was searching for one of those helpful "Permalink to this ___"
options. Didn't even see the link at the top.
Thank you!
--
___
Python tracker
<https://bugs.python.o
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
New submission from Nick :
I find myself reaching for a list of the assert methods in the unittest library
often. There are several methods but no clear way to link a URL via a header if
you intend to bookmark or send it out.
I have been using the method above the section in the meantime
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
New submission from Nick Drozd :
In certain very, very specific circumstances, Pylint can cause the interpreter
to abort with a stack overflow error.
I've seen this issue on 3.5, 3.6, and 3.8 (I assume it affects 3.7 as well) and
on both Mac and Ubuntu.
It requires:
* 1.7 <= Pyl
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
401 - 500 of 8215 matches
Mail list logo
