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:
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:
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 cla
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:
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
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
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.
--
___
P
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.py
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:
(Note: I won't have time to work on this myself until this weekend at the
earliest)
--
___
Python tracker
<https://bugs.python.org/is
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 fo
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:
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 "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:
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:
(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 wa
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 at
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, a
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.py
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
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 offe
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
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
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:
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
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:
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'
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
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/a323cdcb33c8c856e5668acfb2c67a
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 imple
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue35134>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 "#defi
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 th
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/ad1a25f499362eaf9cbfcafa0b8e24
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)?
--
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 enco
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 e
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
possib
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 a
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.
Ho
New submission from Nick Coghlan:
When creating the error handling tests for the new ipaddress module, one of the
things I added was an "assertCleanError" method on the test cases [1].
This is a wrapper around assertRaisesRegex which ensures that either no
exception context is
Nick Coghlan added the comment:
I thought about that originally, but there's only ever one object graph for the
process, and as soon as you break any one edge in that graph you pretty much
invalidate anything based on caching traversal results. (More accurately: it's
almost always g
Nick Coghlan added the comment:
And when I say "originally" I mean "after I saw how ABCs already implemented
this capability" :)
--
___
Python tracker
<http://bug
Nick Coghlan added the comment:
Ah, but that's the other trick: we *don't know* if we need to recalculate our
whole cache when the object graph changes.
1. Some of the cached entries may never be accessed again, so recalculating
them will be a waste
2. The object graph may change ag
Nick Coghlan added the comment:
Trading correctness for speed is almost never a good idea. If people are
worried about speed to that level, they can either bypass the public API and
access the private attribute directly (after profiling their application to
ensure the cache validity checks
Nick Coghlan added the comment:
The reason I switched from suggesting an attribute/property to a module level
function is because we don't really support properties for process global
state. That's why sys has so many getters in it - to make them properties, you
would have to a
Nick Coghlan added the comment:
The latter is probably better (it should just need a slight tweak to
the wording in the docs and docstring)
--
___
Python tracker
<http://bugs.python.org/issue16
Nick Coghlan added the comment:
Supporting extensions was one of the things that got Ethan's version
through review. So -1 on going back on our promise to support those
variants. They have been reviewed and tested just as thoroughly as the rest
of the d
Nick Coghlan added the comment:
Also, we know for a fact that people plan to use the customisation features
- it was making their code work that drove the current extension design.
--
___
Python tracker
<http://bugs.python.org/issue17
Nick Coghlan added the comment:
Eli, remember that TOOWTDI stands for "There's one *obvious* way to do it"
rather than "There's *only* one way to do it". The latter interpretation leads
to insanely complex APIs that attempt to solve everyone's problems, whil
Nick Coghlan added the comment:
Somewhat related, I *know* you've read type.__new__. Compared to that,
enum.EnumMeta.__new__ is still pretty straightforward ;)
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
The current behaviour is also needed to sanely support Python scripts
symlinked from Linux /bin directories.
--
___
Python tracker
<http://bugs.python.org/issue6
Nick Coghlan added the comment:
That's fair - reopening this as a docs bug.
--
assignee: brett.cannon ->
components: +Documentation
resolution: wont fix ->
stage: test needed -> needs patch
status: closed -> open
type: behavior -> enhancement
ve
Nick Coghlan added the comment:
Building without threads is generally going to be for embedded systems without
a GUI anyway, so I think it's fine to just skip the entire IDLE test suite when
real threads aren't available.
--
___
Pyth
Nick Coghlan added the comment:
I like the idea of a separate mixin class like TracebackMixin or
TracebackHelper.
--
___
Python tracker
<http://bugs.python.org/issue18
Nick Coghlan added the comment:
Note that the two patches are the same, I was just curious to see the
difference in handling between them in terms of the review integration.
--
___
Python tracker
<http://bugs.python.org/issue18
New submission from Nick Coghlan:
This patch moves the C level main functions for python, _testembed and
_freeze_importlib to a new Programs directory.
I added README files with my current understanding of the expected contents of
the Python, Objects, Modules and Programs directories and also
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file30409/move_programs.git.diff
___
Python tracker
<http://bugs.python.org/issue18093>
___
___
Python-bug
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file30408/move_programs.diff
___
Python tracker
<http://bugs.python.org/issue18093>
___
___
Python-bug
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg190293
___
Python tracker
<http://bugs.python.org/issue18093>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
+1 for adding this. It's simple to implement, simple to explain and the
alternatives for dealing with the empty iterable case (or even the fact it may
need to be handled at all) are definitely not obvious.
The relationship to next() is straightforward
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue18045>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As stated, I don't agree with the closure of this one. min/max deserve a more
elegant mechanism for dealing with the empty iterable edge case.
--
resolution: rejected ->
status: closed -> open
___
Pyt
Nick Coghlan added the comment:
To me, the Python-specific difference that makes this useful for us but not for
others is *precisely* the fact that the simple idiom:
x = min(seq) if seq else default
is broken for iterators that don't provide __len__ or __bool__, while the even
si
Nick Coghlan added the comment:
Just one final design philosophy comment from me (I know it isn't needed since
Guido already ack'ed the suggestion):
As far as the lessons learned from the historical startswith() case go,
avoiding taking up the positional slots with optional
Nick Coghlan added the comment:
I like the idea of using the strategy pattern to at least decouple the
assertion API from the main testcase API. I also like it better than the mixin
suggested earlier.
We would obviously have to keep the existing methods for backwards
compatibility, but could
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11470>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I don't believe it is reasonable to change the behaviour of partial at this
late stage of the game. It's documented as behaving like staticmethod (albeit
by not implementing the descriptor protocol at all), so that's no longer
something we can c
Nick Coghlan added the comment:
Any associated tests may also want check that wrapping classmethod around a
partialmethod generates a well behaved class method, and ditto for property.
If singledispath, classmethod, partialmethod and class and instance attribute
access all work correctly
Nick Coghlan added the comment:
amk's latest patch looks like a very nice improvement to me.
One suggested wording tweak for the aside about the simplified
history: s/The average Python programmer doesn't need to know the
historical details/The precise historical details aren
Nick Coghlan added the comment:
I think something like "assertThat" could address the problem nicely. Probably
best to propose it as a separate issue, then we can make this one depend on
that one if we decide to go that way.
--
___
Pyth
New submission from Nick Coghlan:
Armin Ronacher pointed out that one downside of the removal of implicit
cross-type comparisons in Python 3 is that it makes it harder to produce a
stable repr for mixed-type containers.
This seems like a valid point to me, so I propose adding a suitable
Nick Coghlan added the comment:
I think PEP 393 gives us a quick way to fast parsing: if the max char is < 128,
just roll straight into normal processing, otherwise do the normalisation and
"all decimal digits are from the same script" steps.
There are almost certainly better w
Nick Coghlan added the comment:
That commit looks just a touch incomplete...
--
resolution: fixed ->
stage: committed/rejected -> commit review
status: closed -> open
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Nicely done - you can also mark the PEP as Final now :)
--
___
Python tracker
<http://bugs.python.org/issue17947>
___
___
Pytho
Nick Coghlan added the comment:
Note that CPython's main function accesses the C API before calling
Py_Initialize(). This is insane, but fixing it is hard (and one of the main
goals of PEP 432).
I suggest using Py_IsInitialized() to exclude those from your debug checks for
Nick Coghlan added the comment:
Indeed, I think the most sensible course here is to require the use of regrtest
to run the GUI tests. Our other resource-dependent tests all fall into that
category already.
If the stdlib unittest provided a resource system, we'd rewrite the regrtest
res
Nick Coghlan added the comment:
Closing this on the assumption the bug is in the extension. Feel free to reopen
if further investigation shows a problem in the interpreter core.
--
nosy: +ncoghlan
resolution: -> invalid
stage: -> committed/rejected
status: open -&g
Nick Coghlan added the comment:
OK, I've satisfied myself that the current behaviour is reasonable, and it's
specifically the subclassing behaviour of the status quo that works for me.
1. You have to specifically access the "x.value" attribute of a default enum
memb
New submission from Nick Coghlan:
Replacing an integer constant with the current incarnation of enum.IntEnum
breaks JSON serialisation:
>>> from enum import Enum
>>> from enum import Enum, IntEnum
>>> class Example(IntEnum):
... x = 1
...
>>&
Nick Coghlan added the comment:
I created issue 18264 after I tried it and found my theoretical concern wasn't
theoretical at all: swapping a true integer for the current incarnation of
enum.IntEnum breaks (at least) JSON serialisation, which means we can't use it
in its curre
Nick Coghlan added the comment:
While I agree with forcing int subclasses to true integers in the JSON module,
that may not be enough - the problem will affect third party serialisers as
well. Whiel the debugging gains won't be as high, we may need to override
__str__() in enum.IntEn
Nick Coghlan added the comment:
CPython's startup sequence and collection of global flags are organically
evolved madness, so I think adding even more complexity to them is a bad
idea. When you're in a hole, the first thing to do is *stop digging*.
I could use help laying the found
Nick Coghlan added the comment:
Can I vote for something like "__builtin__" as the protocol, rather than
something entirely specific to serialisation? As in "return the most
appropriate builtin type with the same value"? Then a converter
("operator.builtin"?) coul
Nick Coghlan added the comment:
Whatever we do needs to be something third party serialisation libraries
can also adopt with minimal compatibility risk for older versions of Python.
Yes, that serialisation will lose the new debugging information. That's
fine - if people want to map f
Nick Coghlan added the comment:
Since this question just came up on python-ideas again, here's a summary of the
current status:
1. The current patch is known to be outdated due to the inclusion of PEP 380 in
Python 3.3 ("yield from itr" eliminates any need for "yield *itr
Nick Coghlan added the comment:
The way we figure out where to find the standard library is crazy, and creating
the infrastructure to start making it less crazy is actually one of the prime
motivations for PEP 432 :)
--
___
Python tracker
<h
Nick Coghlan added the comment:
As Richard said, the __globals__ attributes of the functions are pointing at
the real module dictionary, which may have been cleared when the temporary
module was destroyed.
However, I just checked the docs and they don't actually mention the fact
Nick Coghlan added the comment:
I think we should actually go further, and explicitly defer to
http://docs.python.org/3/library/types#dynamic-type-creation for dynamic type
creation.
Type shouldn't be called with arbitrary bases any more, precisely *because*
doing so breaks __prep
Nick Coghlan added the comment:
Unfortunately, it's not that simple, as calling type(name, bases, namespace) is
*exactly* what a subclass will do as part of creating the type object.
>From inside the type implementation, we can't tell the difference between
>"properly
Nick Coghlan added the comment:
It turns out there's one slight wrinkle in this grand plan: it won't work for
docstrings without some additional tweaking to allow for method calls in the
docstring detection.
>>> def f():
... """example""".
Nick Coghlan added the comment:
I still think the methods are worth adding regardless - I just anticipate a
request to allow method calls on docstrings to follow not long after ;)
--
___
Python tracker
<http://bugs.python.org/issue18
Nick Coghlan added the comment:
I've come around to the idea of having this available as an option in the
default interpreter. A separate binary could then just make it the default
behaviour (leaning on PEP 432 to do so), which is more shebang line friendly
and allows Linux distros to b
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue17545>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
assignee: ncoghlan ->
___
Python tracker
<http://bugs.python.org/issue17545>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Raymond, one of the devs here at the PyCon AU sprints has been looking into
providing an updated patch for this. Do you mind if I reassign the issue to
myself to review their patch (once it is uploaded
Nick Coghlan added the comment:
As part of this, I finally reviewed Jim's proposed alternate implementations
for the helper functions. Katie's patch used my version while I figured out the
differences in behaviour :)
The key difference between them relates to the following
Nick Coghlan added the comment:
I'm actually not sure which of us is correct - Katie and I will be looking into
it further today to compare the existing implementation, my proposal and yours
to see if there's a clear winner in terms of consistent.
It may be that we end up choosing t
Nick Coghlan added the comment:
OK, I had misunderstood the way Jim's code works (it still coerces a "False"
result for __eq__ into NotImplemented if the ordered comparison returns
NotImplemented).
However, I spent some more time tinkering with it today (see
https://bitbuck
Nick Coghlan added the comment:
ValueError works for me.
--
___
Python tracker
<http://bugs.python.org/issue17840>
___
___
Python-bugs-list mailing list
Unsub
2901 - 3000 of 6301 matches
Mail list logo
