Changes by Jim Fasarakis-Hilliard <d.f.hilli...@gmail.com>:
--
pull_requests: +568
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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:
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
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
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: +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
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
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:
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:
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:
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>:
--
pull_requests: +321
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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:
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:
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
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 <
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>:
--
components: +Tests -Library (Lib)
___
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
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:
> 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
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:
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
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:
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
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:
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
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:
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:
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:
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:
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
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
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
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>:
Added file: http://bugs.python.org/file46406/patchlevel_with.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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 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
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
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
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
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:
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
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
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:
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:
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
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:
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:
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>
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>
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:
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:
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
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:
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'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:
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
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
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
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
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
101 - 176 of 176 matches
Mail list logo
