New submission from Yury Selivanov:
The attached patch adds AsyncIterator & AsyncIterable to collections.abc module.
--
assignee: yselivanov
components: Library (Lib)
files: async_abc.patch
keywords: patch
messages: 243148
nosy: asvetlov, gvanrossum, haypo, ncoghlan, yselivanov
prio
Changes by Yury Selivanov :
--
dependencies: +PEP 492: Add AsyncIterator and AsyncIterable to collections.abc
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Signatures and Parameters are already hash able in 3.5. Please close the issue.
--
nosy: +Yury.Selivanov
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Good catch! Please take a look at the attached patch.
--
keywords: +patch
Added file: http://bugs.python.org/file39371/sig_ba_docs.patch
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Do you have any good use case for this?
In one of the first iterations of PEP 362 we had Parameter.index. However, we
later redesigned the object to work as a building block -- immutable, and
explicitly detached from its parent Signature. This way there is
Yury Selivanov added the comment:
Well, the docs example only binds explicit defaults in function signature.
Implicit defaults for *args and **kwargs (`()` and `{}`) aren't usually useful
(in my opinion).
Do you guys have any good use case for such method? I use the Signatur
Yury Selivanov added the comment:
> What do you mean? In Signature or in BoundArguments? I would hope that
Signature keeps it.
I mean during the actual call, as **kwargs aren't ordered.
I think having indexes for parameters would make sense for a language like JS
or C, where ther
Yury Selivanov added the comment:
>> Do you guys have any good use case for such method?
> A use case was given in issue22998.
> My use case is JIT-compiling functions and function calls in Numba. We
> reimplement the function calls ourselves, so need a complete mapping of
> a
Yury Selivanov added the comment:
> As mentioned in the issue, when re-implementing function calls, you have
to flatten the arguments into a simple argument list [..]
Then you probably need indexes for BoundArguments, not Parameters.
> (*) at least for pure Python functions, whe
Yury Selivanov added the comment:
Thank you Guido for the review! Committed to the default branch.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
FWIW it wasn't as easy as I thought it would be :) You were right, docs
example is very basic.
Please take a look at the attached patch.
--
assignee: -> yselivanov
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24191>
___
___
Yury Selivanov added the comment:
OK, I'm closing this one.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Changes by Yury Selivanov :
--
priority: normal -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue23812>
___
___
Python-bugs-list mai
Yury Selivanov added the comment:
Agree. Let's remove them. I'll update the code.
--
___
Python tracker
<http://bugs.python.org/issue24200>
___
___
Yury Selivanov added the comment:
Actually, I like the current repr (minus the object ID, I'll update the code).
The thing about BoundArguments is that '.arguments' is the main property. You
use it to add more stuff to *args & **kwargs, or to add/remove
positional/keyword a
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24200>
___
___
Yury Selivanov added the comment:
That's strange. None of these test touch any files-related stuff. At least I
can't see it.
--
___
Python tracker
<http://bugs.python.o
Yury Selivanov added the comment:
Look's like it's TestNoEOL.__init__ method.
--
___
Python tracker
<http://bugs.python.org/issue24208>
___
___
Python-b
Yury Selivanov added the comment:
I think it should be fixed now. Thanks for finding this!
--
___
Python tracker
<http://bugs.python.org/issue24208>
___
___
Pytho
Yury Selivanov added the comment:
Thanks for the suggestion, Antoine!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Raymond, is there any chance you can review the patch before beta1? Sorry, for
bugging you with this, I just really hope we can have fast OrderedDict in 3.5.
--
___
Python tracker
<http://bugs.python.
Yury Selivanov added the comment:
As for refleak -- I looked at it briefly: simple "a = OrderedDict(); a = None"
code leaks, so it must be somewhere in tp_new/tp_dealloc. And I know what
object is leaking - it's None.
--
___
Python
Yury Selivanov added the comment:
I must have used a better example :)
>>> import sys; from collections import OrderedDict as OD
>>> sys.getrefcount(None)
2053
>>> OD();OD();OD();OD();
OrderedDict()
OrderedDict()
OrderedDict()
OrderedDict()
>
Yury Selivanov added the comment:
Started to look at the patch in more detail. Found one leak. There are more.
Eric, maybe you can hunt them?
--
___
Python tracker
<http://bugs.python.org/issue16
Changes by Yury Selivanov :
--
assignee: -> yselivanov
___
Python tracker
<http://bugs.python.org/issue24227>
___
___
Python-bugs-list mailing list
Unsubscrib
Yury Selivanov added the comment:
Arfrever, Matthias,
Thanks for reporting this issue. It should now be fixed. Please verify that
it works for your usecase.
--
nosy: +gvanrossum, ncoghlan
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Thanks! Closing the issue.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
assignee: -> yselivanov
___
Python tracker
<http://bugs.python.org/issue24205>
___
___
Python-bugs-list mailing list
Unsubscrib
Yury Selivanov added the comment:
Hi David,
Please see the attached patch. It doesn't make Signature.bind() exceptions look
exactly like system messages, but it's now much closer.
--
keywords: +patch
Added file: http://bugs.python.org/file39422/sig
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24205>
___
___
Changes by Yury Selivanov :
--
priority: normal -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue22970>
___
___
Python-bugs-list mai
Yury Selivanov added the comment:
Nick, what do you think of this one?
--
___
Python tracker
<http://bugs.python.org/issue20691>
___
___
Python-bugs-list mailin
Yury Selivanov added the comment:
Nick,
> However, as noted, I doubt the latter is worth it - let's just expose the
> flag to decide whether to resolve wrapper chains or not, and leave the
> inclusion of the already bound value in the reported signature solely as a
> le
Yury Selivanov added the comment:
> Do you think it's OK if I drop them?
Dropping == DeprecationWarning
--
___
Python tracker
<http://bugs.python.org
Yury Selivanov added the comment:
After some experiments, it looks like bind() is already pretty fast. The only
way to increase its performance is to rewrite it in C.
I tried to approaches:
1. Refactor ._bind() to produce a high-level instruction set that can be
cached, and is fast to
Yury Selivanov added the comment:
Closing this one.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Yury Selivanov:
I want to deprecate Signature.from_function and Signature.from_builtin in 3.5.
There is no use for these methods (they aren't generic), and we also now have a
very handy 'from_callable' for easy Signature subclassing.
--
assig
Yury Selivanov added the comment:
Forgot to mention: from_function and from_builtin are not documented.
--
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Patch is attached.
--
keywords: +patch
Added file: http://bugs.python.org/file39439/sig_warns.patch
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
> For the documentation, in addition to noting the deprecation itself, it may
> also be worth noting how to explicitly recreate the type restriction.
Nick, what do you mean by "type restriction"? Also, since the functions aren't
documen
Yury Selivanov added the comment:
Eric, could you please upload your latest patch?
--
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bug
Yury Selivanov added the comment:
OK, committed! Thanks for the review, Nick.
--
___
Python tracker
<http://bugs.python.org/issue24248>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24248>
___
___
Yury Selivanov added the comment:
I documented the deprecation in the whatsnew section anyways.
--
___
Python tracker
<http://bugs.python.org/issue24248>
___
___
Yury Selivanov added the comment:
Nick, please review the patch.
BTW, we will have *a lot* of warnings now when running tests with -Wall. Are we
going to employ "from __future__ import generator_stop" everywhere in 3.5?
--
keywords: +patch
nosy: +yselivanov
priority: normal
Changes by Yury Selivanov :
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue24237>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file39442/gen_stop_warn.patch
___
Python tracker
<http://bugs.python.org/issue24237>
___
___
Python-bug
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39443/gen_stop_warn.patch
___
Python tracker
<http://bugs.python.org/issue24237>
___
___
Python-bug
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file39443/gen_stop_warn.patch
___
Python tracker
<http://bugs.python.org/issue24237>
___
___
Python-bug
Yury Selivanov added the comment:
Had to regenerate the patch. Fixed some typos + now I use PyErr_WriteUnraisable
if PyErr_WarnFormat returns non-zero.
And yeah, PendingDeprecationWarning is a better choice.
--
Added file: http://bugs.python.org/file39444/gen_stop_warn.patch
Yury Selivanov added the comment:
> Are there really all that many warnings triggered for PEP 479?
Actually, with the attached patch the number of warnings is pretty low, we can
definitely fix/silence them where necessary. (I think I had a bug in one of my
first patches that triggered s
New submission from Yury Selivanov:
Please find attached a docs patch for PEP 492 changes.
I'd really appreciate if someone can review it / help me with it. I think it's
important to have at least some documentation shipped with beta-1, so that
people start testing t
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file39448/async_docs_v1.patch
___
Python tracker
<http://bugs.python.org/issue24180>
___
___
Python-bug
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39449/async_docs_v1.patch
___
Python tracker
<http://bugs.python.org/issue24180>
___
___
Python-bug
Yury Selivanov added the comment:
Thanks for the review Nick. I committed the patch with some additional minor
fixes, including your suggestion.
> Asynchronous iterator question: should the typical pattern for those be:
def __aiter__(self):
return self
def __await__(s
Yury Selivanov added the comment:
> Why the switch to WriteUnraisable?
After adding a unittest for the patch it became clear that it was indeed
unnecessary ;) Please see the new patch.
--
Added file: http://bugs.python.org/file39454/gen_stop_warn.pa
Yury Selivanov added the comment:
Nick, I've updated the patch to address all PendingDeprecationWarnings related
to the PEP 479 in the test suite.
--
Added file: http://bugs.python.org/file39457/gen_stop_warn.patch
___
Python tracker
Yury Selivanov added the comment:
Please see the new patch.
So it's time to deprecate getargspec with a warning (was softly deprecated in
3.0).
getfullargspec() and getcallargs() deprecation is documented.
I also want to deprecate formatargspec() and formatargvalues(), but Signature
Yury Selivanov added the comment:
Nick, Berker, please find an updated patch attached (with support for
coroutines). Big +1 on the idea, BTW.
--
Added file: http://bugs.python.org/file39460/issue24056_2.diff
___
Python tracker
<h
Yury Selivanov added the comment:
This issue was resolved in
https://github.com/python/asyncio/commit/3a09a93277afc2cdb43badf92a2c85c2789813f6.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: -Python 3.4
_
Yury Selivanov added the comment:
Merged. Thanks for the bug report and patch, Mike!
--
assignee: -> yselivanov
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Yury Selivanov :
Removed file: http://bugs.python.org/file39460/issue24056_2.diff
___
Python tracker
<http://bugs.python.org/issue24056>
___
___
Python-bug
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39461/issue24056_2.diff
___
Python tracker
<http://bugs.python.org/issue24056>
___
___
Python-bug
Yury Selivanov added the comment:
Hi Berker, thanks for the review. I think all your edits are reasonable, so
I've just committed your patch as is.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Nick, I updated the code to use assertWarnsRegex (thanks for suggestion,
Berker!)
Closing the issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python track
Yury Selivanov added the comment:
Closing this issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Nick, Berker, a kind reminder -- please review the patch if we want to have it
in 3.5.
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20438>
___
___
Yury Selivanov added the comment:
Thanks Berker!
--
___
Python tracker
<http://bugs.python.org/issue20438>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
I'm copying/pasting my latest commit message on this issue here:
"""Add a note about deprecating old inspect APIs to whatsnew.
Also, deprecate formatargspec, formatargvalues, and getargvalues
functions. Since we are deprecating 'ge
New submission from Yury Selivanov:
The PEP has been accepted, let's review the reference implementation and get it
committed.
--
assignee: yselivanov
components: Interpreter Core
files: asyncgen_1.patch
keywords: patch
messages: 274845
nosy: haypo, lukasz.langa, yselivanov
pri
New submission from Yury Selivanov:
This patch is supposed to be committed after issue #28003.
--
assignee: yselivanov
components: Interpreter Core
files: async_comp_1.patch
keywords: patch
messages: 274897
nosy: haypo, lukasz.langa, ned.deily, yselivanov
priority: release blocker
Yury Selivanov added the comment:
> It looks like this part is causing a refleak
There is one DECREF in ceval that you commented out. I think it should
actually be there. But it doesn't solve the problem.
--
nosy: +yselivanov
___
Python
Yury Selivanov added the comment:
Ivan, take a look at my patch - i've fixed the refleak. It was in
STORE_ANNOTATION opcode, you didn't DECREF `ann` consistently in all error
branches. Also, you should never "break" in ceval -- only "goto error" or
"DISPA
Yury Selivanov added the comment:
> Please take a look and sorry for a delay.
Ivan, I'll be the one merging the patch. Will be looking over it soon. I might
fix some nits myself, so if it applies cleanly to the default branch and all
tests pass - then I'll handle the rest.
Pl
Yury Selivanov added the comment:
Ivan, is "hg-pep-526-v5.diff" patch the one I can commit?
--
___
Python tracker
<http://bugs.python.org/issue27985>
___
___
Yury Selivanov added the comment:
Committed. Congrats Ivan, it's a very serious contribution. Thank you.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Yury Selivanov added the comment:
Committed. Thanks Victor for the review!
--
___
Python tracker
<http://bugs.python.org/issue28003>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file44484/async_gen.patch
___
Python tracker
<http://bugs.python.org/issue28003>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Serhiy, Victor and I want this to be merged tomorrow morning PST to land in 3.6
before the freeze. Would you be able to merge this yourself? If not, we'll do
it ourselves in the morning.
--
nosy: +yseli
Yury Selivanov added the comment:
You're welcome.
> 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 :-)
If you need any help/me
Yury Selivanov added the comment:
Thanks, Martin, it should be fixed now.
--
___
Python tracker
<http://bugs.python.org/issue28003>
___
___
Python-bugs-list mailin
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file44504/asyncomp.patch
___
Python tracker
<http://bugs.python.org/issue28008>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Committed. Thank you Victor for the review.
--
___
Python tracker
<http://bugs.python.org/issue28008>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Should be fixed now.
--
___
Python tracker
<http://bugs.python.org/issue28008>
___
___
Python-bugs-list mailing list
Unsub
Yury Selivanov added the comment:
Build bots are green now, closing this.
--
___
Python tracker
<http://bugs.python.org/issue28008>
___
___
Python-bugs-list mailin
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue14757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> Yury: What do you think of the code? How solid is it? (The issue I found was
> due to my own very recent changes to _blocking.)
The code looks fine, I can fix the remaining nits myself. I've left a couple
of comments in review.
> Ned: Is i
Changes by Yury Selivanov :
--
components: asyncio
keywords: easy
nosy: gvanrossum, haypo, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: Document Transport.set_protocol and get_protocol
versions: Python 3.6
Changes by Yury Selivanov :
--
assignee: docs@python
components: Documentation, asyncio
keywords: easy
nosy: docs@python, gvanrossum, haypo, ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document TCP_NODELAY by default
type
Changes by Yury Selivanov :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
stage: -> needs patch
type: -> enhancement
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Committed, should be in 3.6 b1.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
assignee: yselivanov
components: Documentation
nosy: ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 530
type: enhancement
versions: Python 3.6
Changes by Yury Selivanov :
--
assignee: yselivanov
components: Documentation
nosy: ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 525
type: enhancement
versions: Python 3.6
Yury Selivanov added the comment:
> After releasing beta 1 this would require changing bytecode magic number.
Why don't we change the magic number before b1 (if your bytecode change is
already committed)?
--
___
Python tracke
Yury Selivanov added the comment:
Ned, would it be OK to commit this patch after b1?
async/await are scheduled to become real keywords in 3.7. Right now they are
only keywords in 'async def' blocks, meaning that it's OK to have a class with
'async' or 'await
2801 - 2900 of 3098 matches
Mail list logo