Ram Rachum added the comment:
Oh that sucks. Logan and Antoine worked on this feature for so long. Thanks for
reporting Greg.
--
___
Python tracker
<https://bugs.python.org/issue44
Ram Rachum added the comment:
I disagree but I guess I'm in the minority here, so I'll close this issue.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Ram Rachum added the comment:
I'd include that same message you quoted, minus the list of functions, on each
and every one of the functions that have this argument.
--
___
Python tracker
<https://bugs.python.org/issue46
Ram Rachum added the comment:
Thanks, but people looking at a specific function might not guess that the
documentation for one of its arguments is hiding somewhere on the long page.
This is especially relevant with a confusing argument like `msg`, since it's
tempting to think
New submission from Ram Rachum :
The `msg` argument to the `assertRaises` function isn't documented. The
documentation should say what this argument does.
--
assignee: docs@python
components: Documentation
messages: 408587
nosy: cool-RR, docs@python
priority: normal
severity: normal
New submission from Ram Rachum :
The new __note__ feature for exception could be useful, but the documentation
(and the section in "What's new") aren't good enough:
"__note__: A mutable field which is :const:`None` by default and can be set to
a string. If it is n
Ram Rachum added the comment:
Okay, works for me.
--
___
Python tracker
<https://bugs.python.org/issue28953>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ram Rachum added the comment:
This might work here, but you'd need to be sure there isn't any important code
that looks at the IncompleteRead exception and expects the data to be in its
message.
Also I hope that various tools like IDEs would learn quickly that they need to
display the note
Ram Rachum added the comment:
Interesting feature Irit, thank you
Two things:
1. Is there better documentation for that feature than what was in the CL of
the issue you linked to? Because that documentation was more lawyery than
explanatory.
2. If I understand correctly, the note
Ram Rachum added the comment:
I confirmed now in the 3.10 installer on Windows that accelerators are working.
Thank you!
--
resolution: out of date -> fixed
___
Python tracker
<https://bugs.python.org/issu
Ram Rachum added the comment:
Awesome. You can link to experimental code here. Even if it were not accepted
to Python, it could be useful for me and for other people who might see this
issue.
--
___
Python tracker
<https://bugs.python.
New submission from Ram Rachum :
I love `concurrent.futures`, and I'd like to use it wherever I can. There's a
feature in `multiprocessing.Pool` that I wish would also be available in
`ProcessPoolExecutor`: The `maxtasksperchild` argument.
Documentation: "maxtasksperchild is the n
Ram Rachum added the comment:
People barely know how to use the right form of this feature. Providing them
with a wrong form that's confusingly similar to the right form and fails
silently is an unfortunate choice.
"Or just don't do anything. A `raise exception` inside an except
New submission from Ram Rachum :
I saw this line of code today:
https://github.com/hyperledger/sawtooth-sdk-python/commit/c27b962541c9ae68fd1e6dc691ddee883234f112#diff-eb008203eae2160c5e14c42e5fd2eee164709a93bf5136fa79cc256d4e46eaffR92
I was about to tell this guy that his code is bad since
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +22241
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23348
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the patch now.
--
assignee: docs@python
components: Documentation
messages: 381263
nosy: cool-RR, docs@python
priority: normal
severity: normal
status: open
title: Clarify documentation of TestCase.assertIs
type: enhancement
versions: Python
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +21470
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/22441
___
Python tracker
<https://bugs.python.org/issu
Ram Rachum added the comment:
Sounds good, I'm on it.
--
___
Python tracker
<https://bugs.python.org/issue41773>
___
___
Python-bugs-list mailing list
Unsub
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +21455
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22418
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the patch now.
--
components: Library (Lib)
messages: 377534
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Include options for timespec in docstrings of isoformat
type: enhancement
versions: Python 3.10
Ram Rachum added the comment:
Thanks for your time, and I accept your decision here. I'd appreciate it though
if you wouldn't use the term "made up issue" on something that happened to me a
couple of days ago. Our opposing positions each have their pros and cons, and
it makes s
Ram Rachum added the comment:
Yes, but the docs say that the weights are assumed to be nonnegative. I'm
assuming the check is done on total because it'd be expensive to do it on each
item. A user reading that error message could understand that it's okay for
weights to be negative as long
Ram Rachum added the comment:
Speaking of that check, the error message is 'Total of weights must be greater
than zero', which is a bit misleading. 'All weights must be positive or zero'
would be more accurate. Would you like a PR
Ram Rachum added the comment:
I disagree, especially the bit about slowing down the function, since you're
checking the total, not every element. Like the check for negative numbers that
you do on line 493. But it's your call.
--
___
Python
New submission from Ram Rachum :
I was recently tripped up by a bug caused by passing infinite weights to
random.choices. I toyed around with that function, and it seemed that when it's
given weights that include infinity or NaN, it selects a specific element,
always without being random
Change by Ram Rachum :
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue41773>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ram Rachum added the comment:
Thanks for linking that, YoStealth. Unless I'm missing anything, it looks like
there's agreement that the right answer is 3.10, and my PR fixes a spot which
was omitted in the PR from the previous issues. Agreed
Ram Rachum added the comment:
If you'd like me to patch that too, let me know. Also, I'll need a decision on
whether it should be on a separate PR and if so, to which versions it should be
backported.
--
___
Python tracker
<ht
Change by Ram Rachum :
--
type: -> crash
versions: +Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41475>
___
___
Py
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +20878
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21733
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the patch now.
--
assignee: docs@python
components: Documentation
messages: 374814
nosy: cool-RR, docs@python
priority: normal
severity: normal
status: open
title: Fix mistake in "What's new in Python 3.7"
versions:
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +20848
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21704
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the patch now.
Thread:
https://mail.python.org/archives/list/python-id...@python.org/thread/OHLXVKIBMNSQO6BCFK6LEHSYNXDB6OQJ/
--
components: Library (Lib)
messages: 374683
nosy: cool-RR
priority: normal
severity: normal
status: open
title
Change by Ram Rachum :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39280>
___
___
Pyth
Ram Rachum added the comment:
I'll fix that typo.
--
___
Python tracker
<https://bugs.python.org/issue40636>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +20202
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21031
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the PR now.
--
components: Library (Lib)
messages: 371997
nosy: brandtbucher, cool-RR
priority: normal
severity: normal
status: open
title: Use zip-strict in zoneinfo
type: enhancement
versions: Python 3.10
Change by Ram Rachum :
--
pull_requests: +20140
pull_request: https://github.com/python/cpython/pull/20961
___
Python tracker
<https://bugs.python.org/issue40
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +20060
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20871
___
Python tracker
<https://bugs.python.org/issu
Change by Ram Rachum :
--
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Clarify motivation for `chain.from_iterable`
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +19873
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20653
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
I was working with the csv module, and I vaguely remembered that you should
open files in binary mode. So I did.
Then I saw this error message:
_csv.Error: iterator should return strings, not bytes (did you open the
file in text mode?)
I read the end
New submission from Ram Rachum :
Why see this:
When you can see this:
It could show columns=? if they weren't read yet. Any other info would be good
too.
This applies to all classes in the csv module.
--
components: Library (Lib)
messages: 370768
nosy: cool-RR
priority
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +19797
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20554
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Writing the PR now.
--
assignee: docs@python
components: Documentation
messages: 370459
nosy: brandtbucher, cool-RR, docs@python
priority: normal
severity: normal
status: open
title: Clarify docstring of Path.rename
type: enhancement
versions: Python
Ram Rachum added the comment:
I see it's been 6 years since the last comment here. I think it's important to
revisit these kind of decisions once in a while. Maybe now the time is ripe for
a change? We could do it backward compatibility with a long deprecation
schedule.
Ezio: You said
Ram Rachum added the comment:
Brett: Oh well, I understand. Looking at the devguide, I can't find where this
is written. I'm interested in seeing how it's phrased, because I do think that
tiny, incremental changes are important. I would want to know why, for example,
my change https
Ram Rachum added the comment:
Antoine: Serhiy linked me to this issue when I opened #40753 . Do you think
that this patch by Serhiy could now be merged?
--
nosy: +cool-RR
___
Python tracker
<https://bugs.python.org/issue20
Ram Rachum added the comment:
I understand your argument. I think it relies on your earlier statement: "The
fact the the path is stored as a string is an implementation detail."
This statement reminds me of the term "architecture astronaut". Pathlib builds
a co
Change by Ram Rachum :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue40753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ram Rachum added the comment:
Remi: Your use case is taken care of by `len(path.parts)`.
Serhiy: "If it is not iterable, the length does not make sense." I'm not sure
this is a rule. I do see that the `collections.abc.Sized` class does not
require an `__iter__` method to
Ram Rachum added the comment:
"We usually do not accept such pure cosmetic changes." Is this an axiom or is
the reasoning written down somewhere? I'd think we all like to remove cruft
that's no longer necessary.
--
___
Python track
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +19612
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20349
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
No need to inherit from object. I'm writing the patch now.
--
components: Library (Lib)
messages: 369770
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Remove Python 2 compatibility code from pathlib
type: enhancement
versions
Ram Rachum added the comment:
Just return len(str(path)). I put the use case on the PR on GitHub.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +19611
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20348
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
I'm writing the patch now.
--
components: Library (Lib)
messages: 369767
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement PurePath.__len__
type: enhancement
versions: Python 3.10
Ram Rachum added the comment:
I understand, thank you.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Ram Rachum added the comment:
Hmm, I feel this isn't right, because I still feel like there should be one
place where one can see the full Python syntax specification, lexing and
parsing and all. But I'm underqualified to argue because I don't understand the
details. Is someone more
New submission from Ram Rachum :
I'm a noob on parsing, learning about it, so it's possible I've made a mistake
somewhere.
I know there's this page: https://docs.python.org/3/reference/grammar.html
Which is a full listing of Python's grammar. However, looking at this page:
https
Ram Rachum added the comment:
Here are the tests I made:
https://github.com/cool-RR/cpython/commit/766409748a107f290997b0cfab5aa19d0c2888e5
--
___
Python tracker
<https://bugs.python.org/issue40
Ram Rachum added the comment:
I updated my PR to match.
--
___
Python tracker
<https://bugs.python.org/issue40016>
___
___
Python-bugs-list mailing list
Unsub
Ram Rachum added the comment:
I'm gonna look past the rudeness, and I'll just say that if I was tripped up by
this, after 11 years of working with Python and the re module, then people in a
beginner or intermediate level could be tripped up by this as well.
Here's another, simpler
Ram Rachum added the comment:
Oops, my mistake. Any other idea how to solve this discrepancy?
--
___
Python tracker
<https://bugs.python.org/issue40016>
___
___
Ram Rachum added the comment:
Well, these aren't the textbook case of a constant, since they're enums, and
not defined in the global namespace.
--
___
Python tracker
<https://bugs.python.org/issue40
Ram Rachum added the comment:
As you can see I left the old uppercase enums defined, to avoid breaking
backward compatibility. We could make them trigger a DeprecationWarning.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +18434
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19078
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
Today I was tripped up by an inconsistency in the `re` docstring. I wanted to
use DOTALL as a flag inside my regex, rather than as an argument to the
`compile` function. Here are two lines from the docstring:
(?aiLmsux) Set the A, I, L, M, S, U, or X flag
New submission from Ram Rachum :
Looking at the enum source code, there's a method `_create_pseudo_member_`
that's used in a bunch of places. Its docstring says "Create a composite member
iff value contains only members", which would have been useful if I had any
idea what "c
Ram Rachum added the comment:
I understand. I've closed my PR and I'll let someone else implement this
ticket-- I don't want to be the reason that someone didn't get the information
they wanted in an error report. Thanks anyway for your time
Ram Rachum added the comment:
Ethan, got a verdict?
--
___
Python tracker
<https://bugs.python.org/issue39717>
___
___
Python-bugs-list mailing list
Unsub
Ram Rachum added the comment:
Ethan, did we successfully convince you not to use `from None`?
--
___
Python tracker
<https://bugs.python.org/issue39717>
___
___
Ram Rachum added the comment:
I'm also strongly against using `from None`. When I'm debugging, I'm like a man
who got lost in the desert and is about to die of thirst. Any possible insight
into what happened is like an oasis, even if there are just a few drops of
water there.
Also, some
Ram Rachum added the comment:
> What do you think it is necessary to switch from implicit chaining to
> explicit chaining?
I didn't say it's necessary, but I think it's beneficial. I find that message
between exceptions useful when I'm debugging and I'd like to keep it accurate
in a
Ram Rachum added the comment:
I understand that we have to be really careful in including information that
could have unlimited size. But I think we have lots of information that isn't
that way.
For example, for ClassDef and FunctionDef objects, we could include the name.
For Assign, we
Change by Ram Rachum :
--
components: Library (Lib)
nosy: cool-RR
priority: normal
pull_requests: 17962
severity: normal
status: open
title: Fix exception causes in tarfile module
type: behavior
versions: Python 3.9
___
Python tracker
<ht
New submission from Ram Rachum :
I was playing with the `ast` library today, and it's frustrating to see objects
like these:
[<_ast.Import object at 0x033FB048>,
<_ast.Import object at 0x033FB0F0>,
<_ast.ImportFrom object at 0x033FB160>,
Ram Rachum added the comment:
Hi guys,
Can we please have a decision on whether we want to move forward with this
issue or not? I have a patch in the PR, and I'll be happy to continue working
on it, or close this issue if that's the decision.
Thanks,
Ram
Ram Rachum added the comment:
Hey Victor, adding you here. This ticket is a continuation of the thread on the
Python security mailing list. I see that there isn't a consensus here for
changing from \d to [0-9]. Can you make a decision on whether to go ahead with
this issue or not? Otherwise
Ram Rachum added the comment:
My approach is that any input that's unexpected by the developer but accepted
by the program could cause either a bug or a security problem, and should be
rejected by the program. I don't have a specific example for this case.
If you think I need to come up
Ram Rachum added the comment:
Okay, since it seems like I'm the only one who wants this change, I'll let it
go. Thanks for your input.
--
___
Python tracker
<https://bugs.python.org/issue39
Ram Rachum added the comment:
> To me, this seems like a pretty thin justification for calling this a
> security vulnerability.
I know that lots of exploits were made because of bugs in Python's URL parsing,
and security releases of Python were made because of that. It's po
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +17337
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17931
___
Python tracker
<https://bugs.python.org/issu
Change by Ram Rachum :
--
pull_requests: +17336
pull_request: https://github.com/python/cpython/pull/17931
___
Python tracker
<https://bugs.python.org/issue39
New submission from Ram Rachum :
I've been doing some research into the use of `\d` in regular expressions in
CPython, and any security vulnerabilities that might happen as a result of the
fact that it accepts non-Ascii digits like ٢ and 5.
In most places in the CPython codebase
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +17335
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17928
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
The platform.py module takes non-Ascii digits in regexes in places it
shouldn't. e.g. digits like ٢ and 5 and accepted, when only the Ascii digits
between 0-9 should be accepted.
--
components: Library (Lib)
messages: 359694
nosy: cool-RR
priority
Ram Rachum added the comment:
> But I *did* get that text. I'm asking how you got the *different* text
> which you gave in your initial request.
Oh, right. Looking back, turns out Wing IDE did that for me. Didn't notice,
sorry.
> So in my opinion, and I recognise that you may
Ram Rachum added the comment:
Here is a short IPython session:
In [1]: class Foo:
...: def __init__(self, x):
...: pass
New submission from Ram Rachum :
I recently got this familiar error:
builtins.TypeError: __init__() takes 1 positional argument but 2 were given
It was annoying that I didn't know which `__init__` method was under
discussion. I wish that Python used the `__qualname__` of the function
Change by Ram Rachum :
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue38724>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ram Rachum :
I was working with a Popen object recently in the shell and it was annoying to
see the `` display. It would be nice to get some
kind of minimal detail about the Popen, for example its args and return code,
if finished.
--
components: Library (Lib
Change by Ram Rachum :
--
keywords: +patch
pull_requests: +16264
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16679
___
Python tracker
<https://bugs.python.org/issu
New submission from Ram Rachum :
I'm writing a PR for this right now.
--
components: Library (Lib)
messages: 354279
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Clarify docstrings of pathlib suffix(es)
versions: Python 3.9
Ram Rachum added the comment:
Serhiy: I confirmed what you're saying and corrected the documentation. Could
you please review?
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Ram Rachum :
--
assignee: docs@python
components: Documentation
nosy: cool-RR, docs@python
priority: normal
pull_requests: 15149
severity: normal
status: open
title: Mention ``frame.f_trace`` in :func:`sys.settrace` docs.
type: enhancement
versions: Python 3.9
Change by Ram Rachum :
--
nosy: -cool-RR
___
Python tracker
<https://bugs.python.org/issue22377>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ram Rachum added the comment:
thautwarm, your suggestions look good. I'm not sure why you used
`entire_contents`, do you want to show the entire content there? Because I saw
that the sample you used had truncation. It might be unsafe to show the entire
mmap, because it could be huge. I'd
Ram Rachum added the comment:
There are a few ways we can go with this, depending on how verbose we want to
be and how willing we are to make calls to the data. Here are a few pieces of
information we could expose:
- Length
- Whether it's a file or anonymous memory
- The entire contents
Change by Ram Rachum :
--
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement `mmap.mmap.__repr__`
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue34
1 - 100 of 395 matches
Mail list logo