Ivan Levkivskyi added the comment:
Added few tests to the patch
--
Added file: http://bugs.python.org/file44503/patch-v2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
I am attaching the patch.
Yury, I also added you here, just in case you have time for this.
Btw, while working on this I have found that the second restriction:
"""
Names listed in a global statement must not be ... in a for loop control
Ivan Levkivskyi added the comment:
After some thinking, maybe it could be still kept in Tools but developed on
github as it is done for typing and asyncio?
I have no preference here, core devs should decide.
--
___
Python tracker <
Ivan Levkivskyi added the comment:
Victor,
Guido proposed to publish com2ann script in a separate repo on github.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Ivan Levkivskyi:
Guido,
Here is a patch to remove com2ann (also it looks like Yury added a second entry
for me in MISC/Acks, so that I am removing it).
--
components: Demos and Tools
files: remove-com2ann.diff
keywords: patch
messages: 275274
nosy: gvanrossum
Ivan Levkivskyi added the comment:
Thank you Guido, Yury, Brett, and Serhiy!
It is first time I make such kind of contribution. It was a great experience
and a great opportunity to better understand CPython internals (I already have
several ideas on what to work next :-)
I will soon submit
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26982>
___
Ivan Levkivskyi added the comment:
Yes,
This is the latest patch that I tested and with resolved merge conflicts.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Thank you Yury,
I usually do
./python -m test -R : test___all__ test_dis test_grammar test_opcodes
test_parser test_pydoc test_symtable test_tools test_typing
and then
./python -m test -j3 -u all
I just run tests with -R3:3 it also works
Ivan Levkivskyi added the comment:
Guido,
I resolved merge conflicts in patch v4 (if it will complain, this could be
because of graminit.c or importlib_external.h, just ignore those, they will be
regenerated during build).
Please take a look and sorry for a delay.
--
Added file
Ivan Levkivskyi added the comment:
Oh, I see there are more comments by Serhiy, I will implement them and submit a
new patch.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Yury, thank you for the fix and for good advice!
(I checked everything like 10 times, except for TOS :-)
I run the full test suite and everything seem to be fine now.
Guido, does Yury's patch apply cleanly, or I need to regenerate a new one
Ivan Levkivskyi added the comment:
Yury,
Commenting out was an attempt to debug. It should be there
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
It looks like this part is causing a refleak
def test_do_not_recreate_annotations(self):
class C:
del __annotations__
try: #with self.assertRaises(NameError):
x: int
except NameError
Ivan Levkivskyi added the comment:
Sorry, again attached a wrong diff, here is the correct one.
--
Added file: http://bugs.python.org/file44470/hg-pep-526-v2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Here is the new patch. I hope I didn't miss any comment and fixed everything.
There is still a refleak to fix.
--
Added file: http://bugs.python.org/file44469/hg-pep-526-v2.diff
___
Python tracker <
Ivan Levkivskyi added the comment:
Guido,
I fixed __annotations__ in interactive REPL, will fix other minor things and
submit a new patch tomorrow morning.
There are two important questions in typing.py:
> Why is the second isinstance() needed? Isn't _ClassVar a subclass of
> Typi
Ivan Levkivskyi added the comment:
> I think this is how exec() already works
This is not exactly like this, exec() emits ast.Module while interactive input
emits ast.Interactive (this one skips compiler_body in compile.c), but I think
I have got your point, will
Ivan Levkivskyi added the comment:
I could change STORE_ANNOTATION opcode so that it will recreate __annotations__
if __name__ == '__main__'.
Or do you now think that it should re-create it always? I still think that
always re-creating __annotations__ if they don't exist seems like silencing
Ivan Levkivskyi added the comment:
We discussed this at some point on python/typing. At that time we decided that
class C:
del __annotations__
x: int
Should be an error. Do you think that it should behave in a different way in
interactive REPL and/or at module level
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27989>
___
Ivan Levkivskyi added the comment:
OK, then I think after will be safer. Let us came back to this right after PEP
526.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Yes, nonlocal will be fixed too. This will be a relatively small patch, but I
am a bit afraid there could be merge conflicts (the code affected could overlap
with changes for PEP 526).
Easiest way would be to simply make this a single patch with PEP 526
New submission from Ivan Levkivskyi:
The documentation at https://docs.python.org/3/reference/simple_stmts.html says
that:
"Names listed in a global statement must not be used in the same code block
textually preceding that global statement"
But then later:
"CPython implem
Ivan Levkivskyi added the comment:
Oops, sorry, forgot to add new files when converting from git to hg, here is
the full patch.
--
Added file: http://bugs.python.org/file44416/hg-pep-526.diff
___
Python tracker <rep...@bugs.python.org>
Ivan Levkivskyi added the comment:
Here is the patch for PEP 526 implementation
--
keywords: +patch
nosy: +levkivskyi
Added file: http://bugs.python.org/file44415/hg-pep-526.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Ivan Levkivskyi added the comment:
Michael, thank you for helping with this!
Please take a look at my comments on the patch.
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Guido, thank you for committing! There are also some other omissions in docs,
Type[C], @overload, there is #26141 to track this. I will submit a patch later.
Until 3.6beta1 I would like to focus on PEP 526
Ivan Levkivskyi added the comment:
Thank you Neil, I agree that Sequence is a reversible collection.
I combined you documentation patch with updated _collections_abc and updated
test_functools (it tests MRO) into a single patch.
--
Added file: http://bugs.python.org/file44148
Ivan Levkivskyi added the comment:
I submit a simple solution in line with __subclasshook__ of other ABCs.
I added several tests, it looks like it is doing everything right.
Please review.
--
keywords: +patch
Added file: http://bugs.python.org/file44144/collection.diff
Ivan Levkivskyi added the comment:
On my machine 8 tests are always skipped:
test_devpoll test_kqueue test_msilib test_ossaudiodev
test_startfile test_winreg test_winsound test_zipfile64
All others tests pass OK.
The main part of the work is by Andrew Barnert, I only introduced small
Ivan Levkivskyi added the comment:
Ned, thank you for applying the patch!
I have discovered this same issue accidentally while playing with possible
implementations of PEP 526. It appeared as a failure in
test_sys_settrace in my fork.
--
___
Python
Ivan Levkivskyi added the comment:
Oops, sorry, forgot one import, all tests pass with the corrected patch.
--
Added file: http://bugs.python.org/file44123/abarnert_rebased2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Ivan Levkivskyi added the comment:
I have manually "rebased" the patch taking into account that part of the work
has been done in http://bugs.python.org/issue25987
Serhiy, Martin could you please review the latest patch and check that
everything is OK?
Andrew did a really good
Ivan Levkivskyi added the comment:
Looks good to me.
15 Сер 2016 18:57 "Michael Lee" <rep...@bugs.python.org> пише:
>
> Michael Lee added the comment:
>
> Second revision attached below.
>
> --
> Added file: http://bugs.python.org/file4412
Ivan Levkivskyi added the comment:
It looks like namedtuple suffers the same issue with empty __slots__:
test_collections leaked [0, 0, 2, 0] references, sum=2
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
Thank you for the patch, Michael!
I could add a comment that probably it is better to mention the definition of
AnyStr = TypeVar('AnyStr', str, bytes) at beginning and only then go with
examples.
--
nosy: +levkivskyi
Ivan Levkivskyi added the comment:
You could try changing this line in compile.c (in function 'assemble')
if (entryblock && entryblock->b_instr)
to
if (entryblock && entryblock->b_instr && entryblock->b_instr->i_lineno)
Does this
Ivan Levkivskyi added the comment:
Michael, thank you for the patch. I have only one comment.
Generator is one of the few types in typing.py that behaves contravariantly.
Maybe you could emphasize that it is contravariant in send type in your patch?
--
nosy: +levkivskyi
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27688>
___
Ivan Levkivskyi added the comment:
I have only one optional comment on the second revision.
--
nosy: +gvanrossum
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ivan Levkivskyi added the comment:
> Should I edit the patch to include a sentence or two describing this
> distinction, just remove the word "almost", or do something else?
I think the best way is to remove the "almost" and briefly explain that you
cannot subclass
Ivan Levkivskyi added the comment:
Added two small comments to the review.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27644>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27598>
___
Ivan Levkivskyi added the comment:
I am not sure that this feature will survive the resolution of
https://github.com/python/typing/issues/136
Types in typing are primarily intended for use with static type checkers and
similar tools, their runtime properties are still under some discussions
Ivan Levkivskyi added the comment:
What holds back this issue now?
It looks like Andrew did a great job.
When I was making a patch for #25987 following Andrew's ideas, I was surprised
how many different idioms has been used for __subclasshook__.
I was going to open an issue on this, when I
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27501>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24379>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25830>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26075>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26477>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26696>
___
Ivan Levkivskyi added the comment:
I would like to do this (update the typing docs) at some point before 3.6
beta1. There probably will be some updates to the PEP (it is still
provisional), and maybe to typing.py soon.
--
nosy: +levkivskyi
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25958>
___
Ivan Levkivskyi added the comment:
I see that I forgot to include .. versionadded:: in the documentation.
Will this go into 3.5.2 or in 3.6?
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker &
Ivan Levkivskyi added the comment:
I was not sure whether Andrew is still interested. I made a simple-minded patch
following his proposal. I also added tests and changed docs accordingly. Note
that I also changed the expected MRO for MutableSequence in one of the
functools tests according
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25987>
___
Changes by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25610>
___
Ivan Levkivskyi added the comment:
Thank you, Guido!
I have noticed single quotes in line 38:
type hinted using `Callable[[Arg1Type, Arg2Type], ReturnType]`
I think it would be logical to replace it with double quotes:
``Callable[[Arg1Type, Arg2Type], ReturnType]``
as Zachary did
Ivan Levkivskyi added the comment:
Guido, are you going to commit our patches before 3.5.final? Is there a merge
conflict now? Should I rebase my diff?
If necessary I could make a clean patch combining two patches (my and Daniel's)
on top of what Zachary did
Ivan Levkivskyi added the comment:
Here is a new patch for the first part of classes at the end of docs.
I also did some minor changes (in particular added more info on generics and
removed the section about ellipsis for default arguments, we could return it if
we decide to write something
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24796
___
___
Python-bugs-list
Ivan Levkivskyi added the comment:
Is anyone working on this right now? If not, I could implement the comments by
Guido to the latest patch by Daniel.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24272
Ivan Levkivskyi added the comment:
New version of the patch by Daniel, latest comments by Guido are taken into
account.
--
Added file: http://bugs.python.org/file40108/typing_doc_v3.patch
___
Python tracker rep...@bugs.python.org
http
Ivan Levkivskyi added the comment:
I am sorry but I still don't get how things are organized here, so pinging this
up. What is the next step? Should I wait for another review?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ivan Levkivskyi added the comment:
Yury, thank you for the patch, the error message is much clearer now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24528
Ivan Levkivskyi added the comment:
What holds the patch now? Should I do something or just wait?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5945
___
___
Python-bugs-list
New submission from Ivan Levkivskyi:
The following code:
async def foo():
lst = [await coro(i) for i in range(10)]
return lst
gives
SyntaxError: 'await' outside async function
I understand that this is because the comprehensions are implemented using a
function scope (see also
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19217
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21253
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21827
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24272
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11352
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16379
___
___
Python-bugs-list
Changes by Ivan Levkivskyi levkivs...@gmail.com:
--
nosy: +levkivskyi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19235
___
___
Python-bugs-list
Ivan Levkivskyi added the comment:
It looks like on python-dev
(http://www.mail-archive.com/python-dev@python.org/msg88256.html) there is an
agreement that this behavior should not be changed (at least not in the nearest
future). If there are no more comments/suggestions, then maybe one could
Ivan Levkivskyi added the comment:
Nick, thank you for a review, I have made a new patch with all the previous
comments taken into account.
--
Added file: http://bugs.python.org/file39759/classdoc-v4.patch
___
Python tracker rep...@bugs.python.org
levkivskyi added the comment:
Eric, the rule that classes don't play the nested scopes game is explained at
beginning of the same section, but the explanation is one sided it only
explains that names defined in classes are not visible inside functions.
Nick, thank you for the thorough
Ivan Levkivskyi added the comment:
Eric, I have submitted a new version of the patch. Could you please make a
review? Nick, it will be interesting to hear your opinion too.
I tried to follow such rules:
1. Explanation should be succinct yet clear
2. It should tell as less as possible about
levkivskyi added the comment:
Eric, thank you for the review. I have incorporated proposed changes in second
version of the patch.
Concerning the question whether it is a bug, it also smells like a bug to me,
but Guido said 13 years ago that this should not be changed:
https://mail.python.org
levkivskyi added the comment:
Should I invite someone to review the patch or just wait? How the things are
organized here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
levkivskyi added the comment:
Since no one proposed alternative ideas, I am submitting my proposal as a
patch, with the following wording:
A class definition is an executable statement that may use and define names.
Free variables follow the normal rules for name resolution, while unbound
New submission from levkivskyi:
The matrix multiplication operator @ is going to be introduced in Python 3.5
and I am thinking about the following idea:
The semantics of matrix multiplication is the composition of the corresponding
linear transformations.
A linear transformation
New submission from levkivskyi:
Links to Python library documentation such as:
http://docs.python.org/library/functions.html
http://docs.python.org/library/itertools.html
http://docs.python.org/library/functools.html
etc.
are automatically forwarded to the Python 2 versions, namely to:
https
levkivskyi added the comment:
Is it possible to check whether the Python 3 version exists and redirect to it
and if not (like for http://docs.python.org/library/fpformat.html) then
redirect to Python 2 ?
--
___
Python tracker rep...@bugs.python.org
New submission from levkivskyi:
The documentation on execution model
https://docs.python.org/3/reference/executionmodel.html contains the statement
A class definition is an executable statement that may use and define names.
These references follow the normal rules for name resolution
levkivskyi added the comment:
I would like to add that since the introduction of asyncio module that heavily
uses yield from syntax, binding of yield inside comprehensions/generator
expressions could lead to unexpected results/confusing behavior. See for
example this question on SO:
http
601 - 689 of 689 matches
Mail list logo
