New submission from Jim Fasarakis-Hilliard :
There's currently a slight disagreement between some of the sequences about
what is raised when the value for `repeat` is too large.
Currently, `str` and `bytes` raise an `OverflowError` while `bytearray`,
`tuple`, `list` and `deque` raise
New submission from Jim Fasarakis-Hilliard :
This isn't an issue, `value` (that is, `{}` here) is shared among all keys.
Since you've added a mutable value, when you mutate it this change is seen for
all keys holding the value.
This is documented in dict.fromkeys
https://docs.python.org/3
Jim Fasarakis-Hilliard added the comment:
A simple substitution of 'types' with 'kind' should do it. This aligns with the
terminology [1] used in the glossary.
[1] https://docs.python.org/3/glossary.html#term-parameter
--
nosy: +Jim Fasarakis-Hilliard
Jim Fasarakis-Hilliard added the comment:
For a more comprehensive list, we currently have for `get*` functions in
`inspect`:
`inspect.getdoc`: Returns `None` if the documentation string isn't present,
either directly on the object or through it mro. This *isn't* documented
Jim Fasarakis-Hilliard added the comment:
Another option, `graphlib`[1], does exist on PyPI but is not maintained and
currently read-only by the author. Other flavors[2][3] of the same name also
don't seem to have much adoption so they shouldn't confuse if a name like
`graphlib` was chosen
Jim Fasarakis-Hilliard added the comment:
The downside I see with any graph prefixed names is the fact that it implies a
larger collection of graph operations.
Add that to the fact that people might be more tempted to propose many graph
related algorithms/utilities to a module
Jim Fasarakis-Hilliard added the comment:
It does seem out of place in functools, intensified by it's odd interjection
among the other functools objects.
Considering heapq and bisect exist as standalone modules, the idea that
topological sorting could go in its own module wouldn't
Change by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<https://bugs.python.org/issue38938>
___
___
Python-bugs-list mailin
Change by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<https://bugs.python.org/issue1635741>
___
___
Python-bugs-list mailin
Change by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<https://bugs.python.org/issue5996>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
Thanks for the feedback, Raymond. I'll try to shift my focus on more pressing
issues. (Closing as rejected)
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tra
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +eli.bendersky, scoder
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Another splinter issue from issue13349. Currently, Element reports it's a list
when remove is called on it:
from xml.etree.ElementTree import Element
Element('').remove(Element(''))
ValueError: list.remove(x): x not in list
>From w
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1938
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Changes the error message for array.remove and array.index to say
'array.(x): x not in array' instead of 'array.(x): x not
in list'.
This is a splinter issue of issue13349.
--
components: Library (Lib)
messages: 294689
nosy: Jim Fasarakis
Jim Fasarakis-Hilliard added the comment:
Thanks, I understand why this isn't the best idea now.
> shouldn't we change error messages that contains the repr of not found value?
That is what I was thinking too, apart from removing the repr from other
messages it will also unify report
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
Great! Also, as Mariatta mentioned in a previous message, shouldn't an entry in
PEP-4 be made?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Jim Fasarakis-Hilliard added the comment:
bump
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30178>
___
___
Python-bugs-list
Jim Fasarakis-Hilliard added the comment:
> he said, "I'm not sure if this was placed inside there due to some wild
> edge-case,"
As a new contributor, I'll always lean on the side of me not seeing something
rather than confidently stating that something is definitel
Jim Fasarakis-Hilliard added the comment:
Bump, any update on what to do with this issue?
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1635
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
The assertNotRegexpMatches name was deprecated in 3.2 in favor of
assertNotRegex [1]. This is currently not documented in unittest.rst.
[1]:
https://github.com/python/cpython/commit/ed3a7d2d601ce1e65b0bacf24676440631158ec8
--
components
Jim Fasarakis-Hilliard added the comment:
Additional question, are tests required to check this behavior? (Also, bumping)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1500
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
The test file duplicates some isinstance and issubclass checks due to the
distinction of classes in Python 2.
Proposed PR removes duplicate asserts.
--
components: Tests
messages: 292784
nosy: Jim Fasarakis-Hilliard
priority: normal
New submission from Jim Fasarakis-Hilliard:
Currently the first lines in PyObject_IsSubClass are:
/* We know what type's __subclasscheck__ does. */
if (PyType_CheckExact(cls)) {
/* Quick test for an exact match */
if (derived == cls)
return 1;
return
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
versions: -Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1413
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Similar to #30168 opened earlier. The MimeTypes class's methods and attributes
aren't indented and the resulting documentation is not indented and duplicates
the class name.
Didn't find anything that might indicate this was intentional when trying
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1402
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Currently, `Logger` in `logging.rst` doesn't have an indent after `.. class::
Logger`. This causes the formatting for the specific section to look somewhat
unexpected [1].
I've already created a PR that indents the methods/attributes accordingly
Jim Fasarakis-Hilliard added the comment:
This was added in python/typing just a couple of days ago, so I'm bumping to
maybe get the PR to python/cpython merged too.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
Thanks for the bug report, Alexander. This is related, if not a superseder, of:
https://bugs.python.org/issue29727
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
Jim Fasarakis-Hilliard added the comment:
Dunno, if I wanted to see a nice formatted output of the internals I'd run `pp
vars(obj)`.
That, though, suffers a bit from the fact that `vars` is not the most known of
the builtins.
--
nosy: +Jim Fasarakis-Hilliard
versions: +Python 3.7
Jim Fasarakis-Hilliard added the comment:
Dong-hee, I apologize. I had made a silly mistake in the title of my PR and, as
such, it didn't appear here on bpo.
Thanks for the PR, though! :-)
--
___
Python tracker <rep...@bugs.python.org>
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1299
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
bump to close issue now that PR was merged
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1166
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
I don't think a change is actually needed here (bumping to decide the fate of
this issue)
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
As per #issue25002 and, specifically #msg250151, the TypeError in `asynchat`
should probably not be included, I'll just make a PR for the TypeError in
asyncio/proactor_events
--
___
Python tracker <
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
Gotcha, thanks for the input, David. I'll leave it to you to decide if the
sentence on the trailing comments warrants removal.
--
resolution: -> rejected
stage: -> resolved
status: open -&g
Jim Fasarakis-Hilliard added the comment:
Ah, yes, the Ref. Manual, not the devguide, silly mistake.
It definitely isn't a documentation bug (the documentation doesn't state
something wrong) as much as I think it might be a slight omission. I really
wasn't aware of how strict the tokenizer
Jim Fasarakis-Hilliard added the comment:
Alternatively, stripping all white-space that proceed `\` could be considered
if it seems like a good idea.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jim Fasarakis-Hilliard:
After looking through the code, the tokenizer only allows a new line character
to proceed `\` in explicit line joining [1].
The Devguide section on it [2] actually states many of the limitations of using
`\` but not directly that nothing is allowed
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
components: +Library (Lib)
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1141
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Couldn't trace exactly when it was removed from tokenizer.c but the
corresponding declaration in the header file survived.
I'm not sure how to tag this small clean-up.
--
messages: 291033
nosy: Jim Fasarakis-Hilliard
priority: normal
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +823
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
The name SlotWrapperType was added in #29377 but it added the type based on the
repr of the object instead of it's type as `type(object.__init__)` results in.
I proposed this be named to WrapperDescriptorType to avoid and any unecessary
confusion
Jim Fasarakis-Hilliard added the comment:
I believe the docs defined that, usually using a bold "CPython implementation
detail" sentence.
It seems like it's something that would be considered an implementation detail,
though, according to Raymond's answer here:
http://stackov
Jim Fasarakis-Hilliard added the comment:
Completely agree, Mariatta. I just wanted to clarify my initial position :-)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
I was probably misunderstood, too, in hindsight, it's my fault for not being
more clear :-).
In my first sentence I was merely pointing out the oddity of -string
not being a very popular term until f-string came along.
As for my second sentence
Jim Fasarakis-Hilliard added the comment:
Could use `%.100S` instead of `%.100R` but I'm not sure of the downsides that
might entail.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
Yes, that does look like too much. My rationale for adding quotes around the
value was in order to make it more clear in cases where the repr exceeds 100
characters.
Instead of:
Traceback (most recent call last):
File "&quo
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
components: +Interpreter Core
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +775
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Jim Fasarakis-Hilliard added the comment:
..and another one here
https://github.com/python/cpython/blob/master/Modules/arraymodule.c#L2145:
"__reduce_ex__ argument should an integer" -> ".. should be .."
--
Jim Fasarakis-Hilliard added the comment:
Indeed, quickly glancing over the error messages there's another small typo in
https://github.com/python/cpython/blob/master/Modules/arraymodule.c#L2371:
"array indices must be integer" -> "array indices must be integers&q
Jim Fasarakis-Hilliard added the comment:
It's odd how 'f-string' just caught on when byte, raw and unicode strings never
really did (at least I personally don't see many people using b-string,
r-string and u-string respectively).
Shouldn't an entry for them be made too if 'f-string' would
Jim Fasarakis-Hilliard added the comment:
Isn't the fact that it's read-only a CPython implementation detail? That is,
shouldn't that just read:
"gives a :term:`mapping` object representing the class's namespace"
so as to not enforce anything on any other implementations?
-
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +745
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
Correction: test_index *partially* duplicates the base class method. It too can
be modified to use super like test_imul.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jim Fasarakis-Hilliard:
Seems the CommonTests class defined in list_tests duplicates the testing
performed by seq_tests.CommonTests in the following functions:
test_index, test_count
Additionally, a part of test_imul from list_tests.CommonTests can be moved
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +725
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Jim Fasarakis-Hilliard:
Specifically, in both Lib/async/proactor_events.py and asynchat.py there's a
comma where a % should be thereby not formatting the value correctly:
TypeError('data argument must be byte-ish (%r)', type(data))
TypeError('data argument must
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +724
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
Sure, Serhiy, I'll make a PR in a bit.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
Additional instances of this:
- function indexOf of operator.py.
- function _PySequence_IterSearch of abstract.c
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jim Fasarakis-Hilliard:
Specifically, the list I've currently found in .py files:
- _pyio.py:
ValueError("flush of closed file")
ValueError("flush of closed file")
"of" -> "on" for both.
- configparser.py:
Value
Jim Fasarakis-Hilliard added the comment:
Indeed, nice catch! Submit a PR for it if you want to (if not, someone else
will pick it up soon :-)
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
That's great, make sure you also take a look at the quick start section of the
devguide [1] if you need help in any steps :-)
[1]: https://docs.python.org/devguide/#quick-start
--
___
Python tracker <
Jim Fasarakis-Hilliard added the comment:
Without stating an opinion on the change, I'd suggest first posting to
python-ideas (unless you already did so and I missed it :-) to get an initial
reaction from folks on your idea before coming to b.p.o.
If you have the backing of python-ideas you
Jim Fasarakis-Hilliard added the comment:
Ah I see now, yes, neither are Reversible, Type, NewType, TYPE_CHECKING and
DefaultDict.
Why don't you go ahead an submit a PR for this? :-)
--
___
Python tracker <rep...@bugs.python.org>
Jim Fasarakis-Hilliard added the comment:
I'm guessing you might of missed it, `Text` is documented in the docs for
Python 3.5 https://docs.python.org/3.5/library/typing.html#typing.Text :-)
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jim Fasarakis-Hilliard added the comment:
I'm pretty sure this is by design; the change introduced in [1] tried to keep
things simple by only trimming the output when the lines were identical. More
complicated scenarios are trickier to implement.
It should be interesting to see if the core
Jim Fasarakis-Hilliard added the comment:
Nice catch, that's a typo indeed. If you'd like, submit a PR [see
https://docs.python.org/devguide/#quick-start] to address this.
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.
Jim Fasarakis-Hilliard added the comment:
@Sean Ochoa, do you want to make this into a PR? The only tweak I would suggest
would be to change all error messages to either be:
"object.method(repr(x)): element not in object"
or:
"repr(x) not in object"
also,
Jim Fasarakis-Hilliard added the comment:
I'd be happy to supply a PR for this if the change seems reasonable.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Jim Fasarakis-Hilliard:
Currently, there's a discrepancy in the exception reporting for the `.index`
and `.remove` methods of many objects:
For arrays:
array.remove(val) -> ValueError: array.remove(x): x not in list
array.index(val) -> ValueError: array.i
1 - 100 of 176 matches
Mail list logo
