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 experienced
on
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 might have
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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'll need
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, makes
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
keywords: +patch
Added file: http://bugs.python.org/file46482/issue29414.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
to use
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. (See https
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 files too or, since
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
Added file: http://bugs.python.org/file46406/patchlevel_with.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 reword the sentence to remove
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
title: Tutorial documentation contains undefined reference -> Tutorial
documentation contains undefined reference to #!
Added file: http://bugs.python.org/file46439/interpreter_tut
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 best
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 am aw
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Jim Fasarakis-Hilliard added the comment:
Typo, is *now* becoming :-)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29390>
___
__
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 <rep...@bugs.python.org>
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 last sentence
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`
ht
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:
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
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 <
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
components: +Tests -Library (Lib)
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +100
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 Fasarakis-Hilliard
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 <d.f.hilli...@gmail.com>:
--
pull_requests: +321
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 anything
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
nosy: Jim
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 I can
tel
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 confusing
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 to supply
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 <d.f.hilli...@gmail.com>:
--
type: crash -> behavior
versions: -Python 2.7, Python 3.3, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
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
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 of
a
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' and 'clas
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:
>>> '' + b''
TypeError: must be st
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
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
_
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 <rep...@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 <rep...@bugs.python.org>
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:
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 <rep...@bugs.python.org>
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 <rep...@bugs.python.org>
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.patch
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://bugs.python.org
Jim Fasarakis-Hilliard added the comment:
Agreed, attached amended patch
--
Added file: http://bugs.python.org/file45957/method_obj35_2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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
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 look
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.
--
___
Python
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 <
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:
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:
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
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:
..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
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: +775
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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
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
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
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
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:
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:
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?
-
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:
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
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +745
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +724
___
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: +823
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +725
___
Python tracker <rep...@bugs.python.org>
<http://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
New submission from Jim Fasarakis-Hilliard:
After discussion on [1] this PR removes nturl2path from test_sundry and ammends
its docstring to include a note on how it is an implementation detail and
tested elsewhere.
--
messages: 289760
nosy: Jim Fasarakis-Hilliard
priority: normal
Jim Fasarakis-Hilliard added the comment:
Whoops:
[1]:
https://mail.python.org/mailman/private/core-mentorship/2017-March/003832.html
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +568
___
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:
Just bumped into this.
Is the removal for this module waiting for the end of Python 2.7 support as PEP
4 states for modules in Py2 and Py3?
The first message calls for a removal in 3.6 so, I'm either missing some
additional conversations
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:
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.
Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +550
___
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
1 - 100 of 176 matches
Mail list logo
