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
Jim Fasarakis-Hilliard added the comment:
It was a random decision on my part, Serhiy, since I didn't see any difference.
Why would you go the other way around?
--
___
Python tracker
<http://bugs.python.org/is
Jim Fasarakis-Hilliard added the comment:
Indeed, good point. Changed it to the suggested way.
--
Added file: http://bugs.python.org/file46525/controlflowdiff2.patch
___
Python tracker
<http://bugs.python.org/issue29
Jim Fasarakis-Hilliard added the comment:
> But maybe it is worth to mention that the output corresponds to the order of
> passed keyword arguments
Should I add this note? It looks fine to me as is but I'm not the experience
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +100
___
Python tracker
<http://bugs.python.org/issue29453>
___
___
Python-bugs-list mailing list
Unsub
Jim Fasarakis-Hilliard added the comment:
Added the following short sentence to the PR, which I believe makes the point
clear:
Note that the order in which the keyword arguments are printed is guaranteed to
match the order in which they were provided in the function call
Changes by Jim Fasarakis-Hilliard :
--
components: +Tests -Library (Lib)
___
Python tracker
<http://bugs.python.org/issue28624>
___
___
Python-bugs-list mailin
Changes by Jim Fasarakis-Hilliard :
--
nosy: +Jim Fasarakis-Hilliard
___
Python tracker
<http://bugs.python.org/issue29595>
___
___
Python-bugs-list mailin
Jim Fasarakis-Hilliard added the comment:
Serhiy, since review activity has dropped on b.p.o now that the move to github
was made, would you like to make this into a pull request to get it reviewed
and merged faster?
--
___
Python tracker
<h
Jim Fasarakis-Hilliard added the comment:
Go ahead with making the PR, marco. I'll take a look at it too when you do.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jim Fasarakis-Hilliard:
Reported from [1] and similar to issue11205
Currently the evaluation order for keys and values in a dictionary
comprehension follows that of assignments. The values get evaluated first and
then the keys:
def printer(v):
print(v, end
Jim Fasarakis-Hilliard added the comment:
Yup, `IntFlags` is a typo, that's why the reference to it doesn't show too.
Also, the fourth enum must be `Flag` which must of been omitted when it was
added in `3.6`.
--
nosy: +Jim Fasaraki
New submission from Jim Fasarakis-Hilliard:
Method absolute of Path objects lacked documentation, proposed PR adds relevant
method to docs.
--
assignee: docs@python
components: Documentation
messages: 288767
nosy: Jim Fasarakis-Hilliard, docs@python
priority: normal
severity: normal
Changes by Jim Fasarakis-Hilliard :
--
pull_requests: +321
___
Python tracker
<http://bugs.python.org/issue29688>
___
___
Python-bugs-list mailing list
Unsub
101 - 176 of 176 matches
Mail list logo
