Stanley added the comment:
I'd be interested in taking a look at this - would these changes clarify things?
Current (https://docs.python.org/3/library/codecs.html#codecs.StreamWriter):
Writes the concatenated list of strings to the stream (possibly by reusing the
write() method)
Change by Stanley :
--
keywords: +patch
pull_requests: +29414
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31245
___
Python tracker
<https://bugs.python.org/issu
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 2.0 -> 3.0
pull_requests: +29585
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31456
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 7.0 -> 8.0
pull_requests: +29586
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31457
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 8.0 -> 9.0
pull_requests: +29589
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31460
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29591
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31462
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29668
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31547
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
Could you expand a bit on why 'list of paths' in pkgutil is understood by
default to be 'list of PosixPath paths'? I would interpret it by default to be
string paths if I saw it somewhere without context
-
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29669
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31548
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29672
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31551
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
While it is ambiguous, when there's a path parameter I would default it to
string unless otherwise specified. Maybe instead a note could be put in the
Pathlib doc noting functions that accept path arguments might not accept Path
ob
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 5.0 -> 6.0
pull_requests: +29685
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31562
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29687
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31565
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
For clarification then, would it be accurate to add a sentence like this in the
documentation?
"Note that isidentifier() still returns True even if the string may not be
normalized."
--
nosy: +slateny
Stanley added the comment:
>From what I can see, the original patch changed
... and the *dict* dictionary is the namespace containing definitions for class
body and is copied to a standard dictionary to become the __dict__ attribute
into this
... and the *dict* dictionary is copied to
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29725
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31602
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
Would a change like this be accurate?
Matches Unicode word characters; this includes most alphanumeric characters as
well as the underscore. In Unicode, alphanumeric characters are defined to be
the general categories L + N (see
https://unicode.org/reports/tr44
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29733
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31610
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
I feel like there might be some backwards compatibility issues if pkgutil wraps
it like that, but similarly I'm not at all familiar with how common the package
is used and whether it'd be fine to make that change, so I'll also differ
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29752
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31629
___
Python tracker
<https://bugs.python.org/i
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 5.0 -> 6.0
pull_requests: +29753
pull_request: https://github.com/python/cpython/pull/31631
___
Python tracker
<https://bugs.python.org/issu
Stanley added the comment:
How would this sound as clarification for the flags argument?
*flags* is a space-separated string containing IMAP flags tokens. Must start
with ``\``.
Perhaps optionally also provide the list of system flags as given in
https://datatracker.ietf.org/doc/html
Stanley added the comment:
Would it be fine to modify FileIO.name like this:
"... given in the constructor. Depending on the type of *name* that was passed
into the constructor, this may not necessarily e a string."
--
nosy: +slateny
Stanley added the comment:
I'm not too sure about documenting the recursive limit here. There's a few
other recursive functions in the os library (such as makedirs()) and if we note
the recursive limit for os.walk then all of them should be noted too, but that
doesn't seem qu
Change by Stanley :
--
nosy: +slateny
nosy_count: 14.0 -> 15.0
pull_requests: +29817
pull_request: https://github.com/python/cpython/pull/31697
___
Python tracker
<https://bugs.python.org/iss
Change by Stanley :
--
nosy: +slateny
nosy_count: 13.0 -> 14.0
pull_requests: +29908
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31810
___
Python tracker
<https://bugs.python.org/
Stanley added the comment:
How does this sound instead? The unequalness is pushed to the front and the
IEEE part back so it's less likely missed:
Math.nan and float('nan') are never equal to any other value, including
themselves, as per IEEE 754. Use math.isnan t
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30104
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32016
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
Vedran's got a good point, as existing documentation for math.nan already says
"... Equivalent to the output of float('nan')."
so it does seem a bit redundant to say both, though I wonder if we should still
be explicit since
>&g
Stanley added the comment:
Then perhaps saying that it's *never* equal is too strong, and instead we just
say it's *not* equal. Not too sure how to phrase the behavior difference
between `==` and `is` though, if that's something that
Stanley added the comment:
Terry, how do you think the example/paragraph should be improved? I notice that
the previous paragraphs talk about continue/break/else, so were you looking for
some new example with all those? And I think the indexing's been fixed by now,
but a clickable li
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30250
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32172
___
Python tracker
<https://bugs.python.org/i
Stanley added the comment:
Mike, are you still working on this issue?
--
nosy: +slateny
___
Python tracker
<https://bugs.python.org/issue32658>
___
___
Pytho
Stanley added the comment:
Feel free, it's all yours
--
___
Python tracker
<https://bugs.python.org/issue32658>
___
___
Python-bugs-list mailing list
Stanley added the comment:
Is there a bpo page or some sort that discusses why the imperative mood is used
over the indicative mood other than convention of PEP 257? I found this
(https://mail.python.org/pipermail/tutor/2012-May/089584.html) question and
answer that seems to make sense, but
Stanley added the comment:
Hmm, I'm not quite following - when you say that the subproccess-ed command
should also inherit the redirection, which subprocess command are you referring
to, and nested or unnested? I gave it a ran and everything seems to run how I'd
expected it, so
Stanley added the comment:
Samriddhi, are you still working on this?
--
nosy: +slateny
___
Python tracker
<https://bugs.python.org/issue46168>
___
___
Python-bug
Change by Stanley :
--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30403
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32351
___
Python tracker
<https://bugs.python.org/i
Kyle Stanley added the comment:
> This is already backported to 3.6. I am not sure about what gets backported
> to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which
> made me think we are discouraged to backport to 3.5). I can work on a manu
New submission from Kyle Stanley :
Last month, several tests were moved into test_importlib
(https://bugs.python.org/issue19696): "test_pkg_import.py",
"test_threaded_import.py", and "threaded_import_hangers.py".
Those tests were created quite a while ago thoug
Kyle Stanley added the comment:
I'm not entirely certain as to which parts should be modernized, and which ones
can remain the same. A large part of my uncertainty is that there are no header
comments for "test_pkg_import.py" to explain the test coverage, so I don'
Change by Kyle Stanley :
--
nosy: +eric.snow, ncoghlan
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kyle Stanley :
--
stage: -> needs patch
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list
Kyle Stanley added the comment:
Ah okay, I wasn't sure what exactly would be involved with the "modernization"
process, so those points were just rough ideas more than anything. I haven't
started working on anything yet since I figured it'd be worthwhile to wait
Kyle Stanley added the comment:
> This might be a decent way to prevent the AttributeErrors, but still allows
> for differentiation of actual None values
Another alternative solution might be to use hasattr() before getattr(), if it
is not desirable for test_pkg_import.py to
Kyle Stanley added the comment:
> A key question here is why are you trying to avoid the AttributeError case so
> much?
> but there's a reason that we don't have attribute existence tests before
> every single attribute access throughout the test suite
Hmm, good
Kyle Stanley added the comment:
> I would just read through the other tests files under test_importlib to see
> how other tests were done.
Okay, I'll start with that and report back with any ideas for potential changes
to test_pkg_imp
Kyle Stanley added the comment:
Reopening the issue for adding the documentation clarification, that comparing
the values view of two dictionaries will always return false (as was suggested
in the ML discussion
https://mail.python.org/archives/list/python-...@python.org/message
Change by Kyle Stanley :
--
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue37585>
___
___
Python-bugs-list mailing list
Un
New submission from Kyle Stanley :
In the documentation for the NotImplemented constant
(https://docs.python.org/3/library/constants.html#NotImplemented), the only use
case mentioned is for binary special methods, (such as object.__eq__(other)).
However, based on a conversation in a recent
Kyle Stanley added the comment:
> python-dev likely isn't the right place. That is a forum for more mature
> ideas.
Agreed, that idea should be posted to python-list if they're having issues
posting to python-ideas. Python-dev certainly wouldn't be
Change by Kyle Stanley :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue37812>
___
___
Python-bugs-list mailing list
Unsubscrib
Kyle Stanley added the comment:
> May I suggest directing your efforts towards fixing known bugs or
> implementing requested features. It isn't our goal to create more work for
> one another
There frequently is value in improving code readability, as it can improve
maintain
Kyle Stanley added the comment:
> Skipping this call for non-main thread in proactor implementation makes sense.
How do we identify whether or not set_wakeup_fd() is being called from a
non-main thread?
--
nosy: +aeros167
___
Python trac
Kyle Stanley added the comment:
> How do we identify whether or not set_wakeup_fd() is being called from a
> non-main thread?
Never mind, I think I found the answer to my own question and tested a patch
locally, I'll open a PR.
--
___
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15163
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15477
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
keywords: +needs review -patch
___
Python tracker
<https://bugs.python.org/issue34679>
___
___
Python-bugs-list mailing list
Unsub
Kyle Stanley added the comment:
> Kyle, thanks for the fix.
> I have basically the same change in my PR but with test and news note.
No problem, that works for me. I was mostly just trying to help with resolving
some of the release blockers for
Change by Kyle Stanley :
--
nosy: +mark.dickinson, meador.inge
___
Python tracker
<https://bugs.python.org/issue23933>
___
___
Python-bugs-list mailing list
Unsub
Kyle Stanley added the comment:
Thanks for the feedback Vedran and Raymond.
> It is not the purpose of the docs to list use cases. Mostly we say what
> something does or how it is defined. As Vedran says, how people use it is
> their own business.
The underlying issue here se
Kyle Stanley added the comment:
> Would it be viable to rephrase the existing section in a manner that explains
> the functional purpose of NotImplemented without revolving around its use
> case in binary special methods?
To expand further upon this, here's an initial idea for
Kyle Stanley added the comment:
Thanks for the explanation.
> Of course, you might argue that _once Python has NotImplemented_, it can be
> used elsewhere - but as I said, I don't think it should be encouraged.
Hmm, okay. My understanding of Raymond's explanation was mo
Kyle Stanley added the comment:
Ronald, is it feasible that the changes made in
https://github.com/python/cpython/pull/14748/files to THREAD_STACK_SIZE in
Python/thread_pthread.h could be causing intermittent failures for the Azure
macOS PR tests?
In a recent PR (https://github.com/python
Kyle Stanley added the comment:
> As you say, we currently have only one usage of NotImplemented outside its
> intended purpose. Maybe we should wait to see whether it becomes at least a
> little bit more popular, before thinking about blessing it.
> I know at least 3 in CPyt
Kyle Stanley added the comment:
It looks like the Azure macOS tests timed out again in the recently opened
PR-15688. Specifically, for test_multiprocessing_spawn and test_functools (both
of which also timed out in PR-15651, which Victor mentioned earlier):
0:26:41 load avg: 2.89 [418/419/1
Kyle Stanley added the comment:
> Any plan to reapply my change, or fix it?
I can try to help with this. I'm not the most familiar with the internals of
asyncio, but I think it would provide a good learning experience.
--
nosy: +
Change by Kyle Stanley :
--
pull_requests: +15390
pull_request: https://github.com/python/cpython/pull/15735
___
Python tracker
<https://bugs.python.org/issue34
Kyle Stanley added the comment:
I've opened PR-15735 which applies the same functionality as Victor's PR-13786,
but adds the public getter and setter methods (for both AbstractEventLoop and
BaseEventLoop) as requested by Andrew.
Since this is still causing intermittent CI fai
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15757
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16147
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
Created GH-16147 for replacing the *from_what* argument with *whence* in the IO
tutorial.
I would like to consider following up on this with another PR that adds the IO
constants `SEEK_SET`, `SEEK_CUR`, and `SEEK_END` to the tutorial. Those
constants would
Kyle Stanley added the comment:
> Thanks you Kyle!
No problem, thanks for merging it Antoine!
What do you think of the followup PR to make use of the SEEK_* constants listed
in the documentation? I think it would be useful to at least mention them in
the tutorial, or even make use of t
Kyle Stanley added the comment:
> FWIW, I've confirmed again that the exact same script on the same machine
> seems fine under Python 3.x. Given the imminent demise of Python 2, perhaps
> this issue is just destined to be an unsolved historical oddity.
Since it doesn't s
Kyle Stanley added the comment:
Upon digging through Modules/_xxsubinterpretersmodule.c, I noticed that on line
2059, `PyInterpreterState_Delete(interp);` is commented out
(https://github.com/python/cpython/blob/bf169915ecdd42329726104278eb723a7dda2736/Modules/_xxsubinterpretersmodule.c
Kyle Stanley added the comment:
Note that I'm not particularly experienced with the c-api, I'm just trying to
take a stab at understanding why the buildbot failure is occuring.
--
___
Python tracker
<https://bugs.python.o
Kyle Stanley added the comment:
Clarification: In the above comment when I was referring to the commit made by
Eric Snow, I meant to link to
https://github.com/python/cpython/commit/7f8bfc9b9a8381ddb768421b5dd5cbd970266190.
--
___
Python tracker
Kyle Stanley added the comment:
Upon further reading of the documentation and some experimentation, it would
definitely not make sense to call `PyInterpreterState_Delete` here (since we're
only closing the sub-interpreter in the current thread), so that's not the
issue. I still ha
Kyle Stanley added the comment:
Clarification:
"If I'm not mistaken doesn't mean that the `return -1` within ..."
Should instead be:
"If I'm not mistaken doesn't this mean that the `return -1` within ..."
(I am really looking forward to moving issue
Kyle Stanley added the comment:
I believe I found a potential fix, see
https://bugs.python.org/issue37224?@ok_message=msg%20352516%20created%0Aissue%2037224%20message_count%2C%20messages%20edited%20ok&@template=item#msg352514.
Should I attach the PR to that issue or this
Kyle Stanley added the comment:
Upon further consideration, I don't think this will address the issue. If the
RuntimeError was not being raised, this failure would be consistent rather than
intermittent.
I think I have have gotten a bit mixed up, even if the return value of
PyErr_F
Kyle Stanley added the comment:
> Thanks, Kyle!
No problem, and thanks for all of the help from Andrew, Yury, and Victor!
> IMHO it will make asyncio more reliable, especially for tests on the CI.
Awesome, that was my primary intention. (:
> If it becomes an issue in Python 3.9
Kyle Stanley added the comment:
> I'm one of the first to advocate to replace ugly macros with clean static
> inline functions. Macros are evil and can be too easily misused.
As someone who has only more recently started learning the C-API (and C in
general), I'm certa
Kyle Stanley added the comment:
Is there a currently reliable way of accessing the GIL functions within the
sub-interpreters, without causing deadlock issues? I was trying to follow the
advice in the documentation
(https://docs.python.org/3/c-api/init.html?highlight=global%20interpreter
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15879
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16293
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
For an updated explanation of the PR, see https://bugs.python.org/msg352835 or
the comments in the PR itself.
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> You can find my email in Git, and I'm on Zulip and Discourse; and I'd be
> happy to start or follow a thread in a forum you think appropriate. Or if
> you'd rather drop it entirely, that's fine too.
I think opening a thread in
Kyle Stanley added the comment:
> Is there an "aesthetic code cleanup" patch that's ever turned out well? ;-)
>From what I can tell, any remotely extensive aesthetic code patch I've seen
>has been highly controversial. I think they can have value in some cases
Change by Kyle Stanley :
--
nosy: +aeros167
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kyle Stanley added the comment:
> We have to document that Process objects use a third kind of stream object
> that doesn't match either the old or new APIs, and how this one works
>From my perspective, this point would have the largest user learning cost due
>to the strea
New submission from Kyle Stanley :
Currently, for the recently added coroutine `loop.shutdown_default_executor()`,
the executor shutdown can wait indefinitely for the threads to join. Under
normal circumstances, waiting on the threads is appropriate, but there should
be a timeout duration in
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +15941
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16360
___
Python tracker
<https://bugs.python.org/issu
Kyle Stanley added the comment:
> Andrew, do you want me to submit a PR or you can do it?
Since this has been elevated to a release blocker, I wouldn't mind helping to
revert this ASAP. I can open a PR to fix it today.
--
___
Python
Kyle Stanley added the comment:
> You'll need to be careful to only revert the new functions & the
> asyncio.Stream class.
So far the trickiest part has proven to be the tests (specifically
test_streams.py) and keeping the deprecation warning for passing explicit loop
argu
Kyle Stanley added the comment:
Currently focusing on the Lib/asyncio/* and Lib/test/* changes. Working on doc
changes next, but that should be significantly easier.
In addition to
https://github.com/python/cpython/commit/23b4b697e5b6cc897696f9c0288c187d2d24bff2
(main commit from Andrew
Change by Kyle Stanley :
--
keywords: +patch
pull_requests: +16024
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16445
___
Python tracker
<https://bugs.python.org/issu
Change by Kyle Stanley :
--
pull_requests: +16035
pull_request: https://github.com/python/cpython/pull/16455
___
Python tracker
<https://bugs.python.org/issue38
Kyle Stanley added the comment:
This should no longer be a release blocker for 3.8 with the reversion of the
new asyncio streaming API in GH-16455.
--
nosy: +aeros167
___
Python tracker
<https://bugs.python.org/issue38
Change by Kyle Stanley :
--
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Pyth
Kyle Stanley added the comment:
> I've reverted the code. Andrew, would really appreciate if you could quickly
> do a post commit review.
Oops, I'll reopen it.
--
___
Python tracker
<https://bugs.py
Change by Kyle Stanley :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Kyle Stanley :
--
stage: resolved -> commit review
___
Python tracker
<https://bugs.python.org/issue38242>
___
___
Python-bugs-list mailing list
Un
1 - 100 of 456 matches
Mail list logo