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
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:
A PR has been submitted, Ryan. See https://github.com/python/cpython/pull/490
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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>:
--
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:
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>:
--
pull_requests: +1166
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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>:
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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:
Thanks for linking the dependency, Serhiy :-)
Is there anybody currently working on the other issue? Also, shouldn't both
issues now get retagged to Python 3.7?
--
___
Python tracker <
Jim Fasarakis-Hilliard added the comment:
Okay, I'll take a look at it over the next days and try and submit a PR after
fixing any issues that might be present.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Jim Fasarakis-Hilliard added the comment:
That makes sense to me, I'll wait around until the dependency is resolved.
--
___
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:
Shouldn't this issue get closed now that the PR was merged?
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
Could you submit a PR for this?
I haven't seen any objections to this change, a PR will expose this to more
people and a clear decision on whether this change is warranted can be finally
made (I hope).
--
nosy: +Jim Fasarakis-Hilliard
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:
Stefan, do you have time to make a PR for this?
--
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>:
--
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: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
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
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
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
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: +1413
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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/
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
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
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1635
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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/
Jim Fasarakis-Hilliard added the comment:
bump
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30178>
___
___
Python-bugs-list
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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, 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
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>:
--
nosy: +eli.bendersky, scoder
___
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
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
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1938
___
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>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
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
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
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
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +1500
___
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
Change by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<https://bugs.python.org/issue5996>
___
___
Python-bugs-list mailin
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
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
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:
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:
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
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
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
101 - 176 of 176 matches
Mail list logo