Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +823
___
Python tracker
<http://bugs.python.org/issue29377>
___
___
Python-bugs-list mailing list
Unsub
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
priori
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1141
___
Python tracker
<http://bugs.python.org/issue29963>
___
___
Python-bugs-list mailing list
Unsub
Changes by Jim Fasarakis-Hilliard :
--
components: +Library (Lib)
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue29966>
___
___
Python-
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:
Alternatively, stripping all white-space that proceed `\` could be considered
if it seems like a good idea.
--
___
Python tracker
<http://bugs.python.org/issue29
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 t
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: ope
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue13290>
___
___
Python-bugs-list mailin
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 :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue28681>
___
___
Python-bugs-list mailin
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
<http://bugs.python.org/i
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1166
___
Python tracker
<http://bugs.python.org/issue29905>
___
___
Python-bugs-list mailing list
Unsub
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue29944>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Jim Fasarakis-Hilliard added the comment:
bump to close issue now that PR was merged
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue29
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30076>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1299
___
Python tracker
<http://bugs.python.org/issue29950>
___
___
Python-bugs-list mailing list
Unsub
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
<http://bugs.python.org/is
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: +Pytho
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
<http://bugs.python.org/issue30
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
<http://bugs.python.org/is
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 a
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1402
___
Python tracker
<http://bugs.python.org/issue30168>
___
___
Python-bugs-list mailing list
Unsub
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 intentio
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1413
___
Python tracker
<http://bugs.python.org/issue30178>
___
___
Python-bugs-list mailing list
Unsub
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30196>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
versions: -Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue30196>
___
___
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;
r
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 :
--
pull_requests: +1500
___
Python tracker
<http://bugs.python.org/issue30234>
___
___
Python-bugs-list mailing list
Unsub
Changes by Jim Fasarakis-Hilliard :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue12857>
___
___
Python-bugs-list mailin
Jim Fasarakis-Hilliard added the comment:
Additional question, are tests required to check this behavior? (Also, bumping)
--
___
Python tracker
<http://bugs.python.org/issue30
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 :
--
pull_requests: +1635
___
Python tracker
<http://bugs.python.org/issue30335>
___
___
Python-bugs-list mailing list
Unsub
Jim Fasarakis-Hilliard added the comment:
Bump, any update on what to do with this issue?
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue9
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 defin
Jim Fasarakis-Hilliard added the comment:
bump
--
___
Python tracker
<http://bugs.python.org/issue30178>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jim Fasarakis-Hilliard :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29950>
___
___
Python-bugs-
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
<http://bugs.python.org/i
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30416>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue26219>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue26280>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30486>
___
___
Python-bugs-list mailin
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
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
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +1938
___
Python tracker
<http://bugs.python.org/issue30506>
___
___
Python-bugs-list mailing list
Unsub
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):
Changes by Jim Fasarakis-Hilliard :
--
nosy: +eli.bendersky, scoder
___
Python tracker
<http://bugs.python.org/issue30507>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue26098>
___
___
Python-bugs-list mailin
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
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30570>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue30600>
___
___
Python-bugs-list mailin
Jim Fasarakis-Hilliard added the comment:
See issue<9232> that changed the docs on function definitions. These changes
aren't reflected in the 3.5 documentation though, you'll find them in the 3.6
docs.
The linked grammar is probably missing an opening parentheses from what
New submission from Jim Fasarakis-Hilliard:
Specifically, the entry reads:
"The dict type has been reimplemented to use a faster, more compact
representation similar to the PyPy dict implementation."
Through, the text describing the new implementation doesn't mention anythin
New submission from Jim Fasarakis-Hilliard:
Attached patch removes small typo ('has') from text:
extends the descriptor protocol has to include the new optional
--
assignee: docs@python
components: Documentation
files: whatsnew_typo.patch
keywords: patch
messages: 283401
Jim Fasarakis-Hilliard added the comment:
The ``typing`` module doesn't exist in Python 2.7.
All code samples provided in the docs *work* since no type-checking is
performed by Python. That is, no enforcing of the types provided is made,
that's for 3rd party packages
Jim Fasarakis-Hilliard added the comment:
Unless of course you mean pip installing typing for Py2 and then using ``#
type`` comments to provide the types.
Even in that case, I don't really think the documentation for Python 3.5 should
be mentioning types in 2.7, that'd get
Jim Fasarakis-Hilliard added the comment:
Seems right to me, this is also stated clearly in the reference manual:
> When an instance method object is called, the underlying function (__func__)
> is called, inserting the class instance (__self__) in front of the argument
> list. For
Jim Fasarakis-Hilliard added the comment:
I see. I'd agree that `instance object` is probably better here. Let's see what
others think.
--
___
Python tracker
<http://bugs.python.o
Jim Fasarakis-Hilliard added the comment:
I've added a little patch that takes care of this. I didn't add "method's
instance object" in the second substitution because it seems evident by the
previous sentences.
--
keywords: +patch
Added file: http://
Jim Fasarakis-Hilliard added the comment:
Agreed, attached amended patch
--
Added file: http://bugs.python.org/file45957/method_obj35_2.patch
___
Python tracker
<http://bugs.python.org/issue29
New submission from Jim Fasarakis-Hilliard:
The following statement is in the Language Reference for Custom classes:
> __bases__ is a tuple (possibly empty or a singleton) containing the base
> classes
AFAIK, ``object.__bases__`` is the only object for which ``__bases__`` is empty
Jim Fasarakis-Hilliard added the comment:
The ``-j`` arguments isn't present for coverage from what I know.
What you can do is build coverage's C extension. That results in a pretty
significant change in overall execution time.
For information about coverage.py you should also l
Jim Fasarakis-Hilliard added the comment:
I suggest this issue be closed as it isn't really an omission, I don't think we
should expect the devguide to document *all* of coverage's options. That's what
its dedicated docs are for.
--
__
New submission from Jim Fasarakis-Hilliard:
In short:
>>> f"\{10}"
yields:
"\\{10"
This is reproducible only when `\` precedes the opening bracket, that is:
>>> f"\ {10}"
results in: "\\ 10"
------
components: Inte
Jim Fasarakis-Hilliard added the comment:
Attached patche for Python 3.3 (change `defparameter` to use `+`).
--
keywords: +patch
Added file: http://bugs.python.org/file46076/3.3_func_def.patch
___
Python tracker
<http://bugs.python.org/issue28
Jim Fasarakis-Hilliard added the comment:
Further patch for `3.4` and `3.5`:
Change `|` to `(` and fix `defparameter` to use `+`
--
Added file: http://bugs.python.org/file46077/3.4_3.5_func_def.patch
___
Python tracker
<http://bugs.python.
Jim Fasarakis-Hilliard added the comment:
Further patch for 3.6 and 3.7 to address `defparameter` change here too.
--
Added file: http://bugs.python.org/file46078/3.6_3.7_func_def.patch
___
Python tracker
<http://bugs.python.org/issue28
Jim Fasarakis-Hilliard added the comment:
I see, the original "complaint" about this behavior on stack overflow was made
due to the discrepancy between the f-string the the format "equivalent":
'\{}'.format(10)'.
--
__
Jim Fasarakis-Hilliard added the comment:
Yes, should've attached in my previous message. See
http://stackoverflow.com/questions/41330097/why-does-the-symbol-remain-when-f-10-is-evaluated-in-python-3-6
--
___
Python tracker
<http://bugs.py
New submission from Jim Fasarakis-Hilliard:
Specifically, bytes (always, from what I could find) had this error message:
>>> b'' + ''
TypeError: can't concat bytes to str
while str, after a change in issue26057, was made to:
>>> '&#x
Jim Fasarakis-Hilliard added the comment:
Should that message be the one predominantly used for sequences, i.e:
TypeError: can only concatenate class1 (not "class2") to class1
or should another one be used like "Unsupported operand type(s) for op:
'class1' an
Jim Fasarakis-Hilliard added the comment:
Yes, I agree with that it seems redundant after the change. I'm attaching
another small patch based on the committed one to trim that off.
--
Added file: http://bugs.python.org/file46117/fixbasesdoc2.
Changes by Jim Fasarakis-Hilliard :
--
components: +Interpreter Core -Distutils
title: `pow` with three int arguments works like it had two arguments -> pow
with three int arguments works like it had two arguments
___
Python tracker
&l
Jim Fasarakis-Hilliard added the comment:
This issue (and your other issue29223) would probably be a better for the
python-ideas mailing list rather than the bug tracker.
See the FAQ in the Developer Guide for Python
https://docs.python.org/devguide/faq.html#suggesting-changes
Both issues
Jim Fasarakis-Hilliard added the comment:
If you use an encoding declaration the encoding must be recognized by Python.
This is clearly stated in the documentation:
https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations
--
nosy: +Jim Fasarakis-Hilliard
title
Changes by Jim Fasarakis-Hilliard :
--
assignee: docs@python
components: Documentation
files: fix_issue.patch
keywords: patch
nosy: Jim Fasarakis-Hilliard, docs@python
priority: normal
severity: normal
status: open
title: Fix wrong issue number in what's new entry
versions: Pytho
Jim Fasarakis-Hilliard added the comment:
As I currently see this:
- The error message for str can be changed to the one used for other sequences
'can only concatenate str (not "type") to str'
- The error message for arrays can be changed to use concatenate instead o
Changes by Jim Fasarakis-Hilliard :
--
type: crash -> behavior
versions: -Python 2.7, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issu
New submission from Jim Fasarakis-Hilliard:
There's a hidden Python 2 print call in the script that only gets reached after
you move the Doc/ folder outside the main CPython directory and run `make
html`.
Additionally, an obsolete way of assuring a file gets closed is used (changed
t
Jim Fasarakis-Hilliard added the comment:
I'm not exactly sure what you mean but, since this isn't a bug per se and is
more of a subjective opinion on how the REPL should handle the indentation
level, you should probably ask *first* on python-ideas to get input from other
members.
Jim Fasarakis-Hilliard added the comment:
Thanks for the standard explanation, Brett. I was just following the devguide
too strictly and assumed python-ideas is the first place one should go :-).
As for the idea, it seems others wish/wished it too (first paragraph:
https://docs.python.org/3
Jim Fasarakis-Hilliard added the comment:
I'm breaking these to separate files to make it easier to apply. I also noticed
that other files in `Doc/tools/extensions/` use old constructs so I'm not sure
about the *with*.
I'm guessing that either it should be changed in other file
Changes by Jim Fasarakis-Hilliard :
Added file: http://bugs.python.org/file46406/patchlevel_with.patch
___
Python tracker
<http://bugs.python.org/issue29349>
___
___
Pytho
Jim Fasarakis-Hilliard added the comment:
>From what I understand, "or'ed" here stands for combining the options using
>`|`
>(https://docs.python.org/3/reference/expressions.html#binary-bitwise-operations).
You can see an example of that in the source for `doctest.py
New submission from Jim Fasarakis-Hilliard:
After moving a certain chunk of the 'interpreter.rst' contents to
'appendix.rst' in issue16827 the reference to #! in the section '2.2.3. Source
Code Encoding' is currently confusing for new readers.
Attached patches
Changes by Jim Fasarakis-Hilliard :
--
title: Tutorial documentation contains undefined reference -> Tutorial
documentation contains undefined reference to #!
Added file: http://bugs.python.org/file46439/interpreter_tut2.7.patch
___
Python trac
Jim Fasarakis-Hilliard added the comment:
I think it is fine as it is but, agree that it could be clearer. I'm simply not
experienced enough to know if this change is warranted.
The docs generally do a great job in being concise (balancing brevity and
completeness). A core-dev would be
Jim Fasarakis-Hilliard added the comment:
Hi, Raymond. Is Mariatta responsible for reviewing Documentation submissions?
If so, should I nosy Mariatta in any future documentation issues?
--
___
Python tracker
<http://bugs.python.org/issue29
Jim Fasarakis-Hilliard added the comment:
Indeed, this does create an issue.
The last sentence in the documentation actually specifies where the encoding
comment can be but doesn't strictly specify it can be on the second line if and
only if preceded by `#!`.
I'm thinking the las
Jim Fasarakis-Hilliard added the comment:
What change do you have in mind for introducing these?
As for my personal opinion, dunno about this. I understand your concerns but
dropping more terminology to a new learner early on wouldn't be the best idea
in my view.
>From what I
Jim Fasarakis-Hilliard added the comment:
Typo, is *now* becoming :-)
--
___
Python tracker
<http://bugs.python.org/issue29390>
___
___
Python-bugs-list mailin
Jim Fasarakis-Hilliard added the comment:
Added a comment too. Other than that and the comment by Marco it looks fine to
me too.
--
___
Python tracker
<http://bugs.python.org/issue29
New submission from Jim Fasarakis-Hilliard:
The current line is confusing hinting that the for statement is actually an
object, it also makes a reference to iterators which the tutorial doesn't
disambiguate until the chapter on Classes.
I've added a small patch that, in my opinion
Changes by Jim Fasarakis-Hilliard :
--
keywords: +patch
Added file: http://bugs.python.org/file46482/issue29414.patch
___
Python tracker
<http://bugs.python.org/issue29
Jim Fasarakis-Hilliard added the comment:
Agreed. The issue I see with the additional suggestions by you and Marco (p.s
the English was perfect!) is the introduction of other functions and/or objects
that haven't been introduced yet.
If you want to draw parallels with tuples, you'
New submission from Jim Fasarakis-Hilliard:
Removes `keys = sorted(keywords.keys())` from function example and removes the
text that describes why this was necessary. As per PEP 468, this note is
obsolete for 3.6+
Also changes the ordering of the function call to match the previous output
Jim Fasarakis-Hilliard added the comment:
Isn't it a language requirement that `**kwargs` be ordered in 3.6, David?
PEP 468 states that `**kwargs` is to be an ordered *mapping* and, if I'm not
mistaken, that was done in order to not depend on the fact that dicts became
ordered. I
601 - 700 of 742 matches
Mail list logo
