Yury Selivanov added the comment:
What are the use cases?
If it's "(Rarely used.)" (as docstring indicates), then, perhaps, a package on
PyPI is a better solution.
--
nosy: +haypo, yselivanov
versions: +Python 3.6 -Python 3.5
___
Changes by Yury Selivanov :
--
nosy: +benjamin.peterson, yselivanov
versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Guido, Victor,
I've just pushed a commit to fix a misspelled method call in queues.py (related
to the previous commit in this issue).
Along with fixing the bug and writing a unittest for it, I discovered an issue
with the current queues design.
Here
Yury Selivanov added the comment:
> Honestly, I've lost track of the queue design. Maybe the push-back on
> cancellation is just wrong? After all, if a coroutine has received an item,
> it's out of the queue, even if it gets cancelled before it can do anything
> with
Yury Selivanov added the comment:
> A better design is to make it so the future that get() is waiting for doesn't
> actually receive the item, it is only used to "wake up" the get() coroutine.
> I would be something like:
>
> 1. get(): in case the queue is emp
Yury Selivanov added the comment:
This is related to Arguments Clinic and Larry's implementation of signature
parsing for built-in functions.
This particular bug is caused by 'codecs.encode' & 'codecs.decode' functions
with the AC signatures defined as follows
Yury Selivanov added the comment:
Guido, I agree, let's not push the updated implementation in 3.5.0.
Gustavo, could you please generate the patch with "hg diff", so that code
review here works? And I think we need a new issue to track the new patch.
--
nosy:
Changes by Yury Selivanov :
--
nosy: -larry
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue23812>
___
___
Py
Yury Selivanov added the comment:
Alex, sure, go ahead. Although I think python-ideas would be a better choice.
--
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Yep, GH works. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue23812>
___
___
Python-bugs-list mailing list
Unsub
Yury Selivanov added the comment:
Larry, Serhiy,
After giving this some thought I think that my initial patch is a wrong
approach here -- inspect module should not be touched to fix this issue.
With this patch applied, signature object for codecs.encode would have a
Parameter with a bogus
Yury Selivanov added the comment:
> Can we do better? How about a new field on the Parameter object,
> "symbolic_default_value", which shows you the expression used to compute the
> value? We could then set default_value to the result of the expression,
> pydoc co
Yury Selivanov added the comment:
I can commit the fix in an hour or so.
--
nosy: +Yury.Selivanov
___
Python tracker
<http://bugs.python.org/issue24835>
___
___
Yury Selivanov added the comment:
Guido, thanks for investigating this.
Larry, it should be fixed now (although I don't have a windows machine at hand
to test it)
--
___
Python tracker
<http://bugs.python.org/is
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
> Yury: be careful when synchonizing github and cpython code. It's common to
have changes only on one side.
Victor, I agree. But let's make sure that it's no more "common" to have two
repos out of sync. I shouldn't syn
Changes by Yury Selivanov :
--
nosy: +ethan.furman
___
Python tracker
<http://bugs.python.org/issue24840>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +benjamin.peterson, ned.deily, yselivanov
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issu
Changes by Yury Selivanov :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue24851>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Looks like we didn't have unittests for Task.get_stack()/Task.print_stack().
Anyways, it's now fixed, I'll make a PR for Larry to get this in 3.5.0rc2.
--
assignee: -> yselivanov
nosy: +larry
priority: normal -> release blocker
Yury Selivanov added the comment:
Can this be enabled only for namedtuples? Otherwise this might be a backwards
incompatible change, for example:
class Foo:
'''spam'''
_fields = None
--
nosy: +yselivanov
___
Yury Selivanov added the comment:
> Named tuples are not a type, they are a protocol. Guido has agreed that
> checking for _fields is an acceptable and preferred way of finding out
> whether something is a namedtuple.
They are, but for protocols we usually use dunder names. "
Yury Selivanov added the comment:
> I was also bitten by this via Enum. Is there any chance this will be fixed in
> Python 3.5?
It will be fixed in 3.5.1.
Thanks for the patch, Ethan!
--
nosy: +yselivanov
resolution: -> fixed
status: open
Changes by Yury Selivanov :
--
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue23572>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Is this still something that we need to address? I think that the current
types.coroutine docs are pretty accurate and don't see where the proposed patch
really improves them.
--
nosy: +yselivanov
___
P
Yury Selivanov added the comment:
LGTM.
FWIW, using 'self.from_exception(..)' is better because this way it's easier to
override the method. Another way would be to write
'type(self).from_exception(..)', but I think using 'self' is good en
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue4356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue24931>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
components: +Interpreter Core
nosy: +yselivanov
stage: -> needs patch
type: -> enhancement
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/i
Yury Selivanov added the comment:
> Here is a new patch, with modifications according to your review Victor.
Could you please generate the patch with 'hg diff', so that code review works
with it.
--
___
Python tracker
<http:/
Yury Selivanov added the comment:
Left some feedback in the code review.
I have a question about the api: so we allow to pass a set of hosts to
create_server, but why do we have only a single port?
--
___
Python tracker
<http://bugs.python.
Yury Selivanov added the comment:
> How am I supposed to handle the method being called with a Mock'ed
> getaddrinfo?
Why would you call it that way? Are regular asyncio users going to mock it in
their production/test code?
If the only case for using mocks there are asynci
Yury Selivanov added the comment:
Thanks!
The only remaining question is is it OK that we can specify more than one host
but only one port? Guido, Victor?
--
___
Python tracker
<http://bugs.python.org/issue23
Yury Selivanov added the comment:
> Yeah, I think this is fine. I think the use case for multiple hosts is very
> different than that for multiple ports, so I see no reason to link the two
> features, and multiple ports hasn't been requested.
OK!
> The patch has a long
Yury Selivanov added the comment:
Good find, David. Thanks!
Please review the attached patch.
--
keywords: +patch
nosy: +benjamin.peterson, larry, ncoghlan, serhiy.storchaka, yselivanov
priority: normal -> release blocker
stage: -> patch review
versions: +Python 3.6
Added file
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24965>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Larry,
I created a PR for you:
https://bitbucket.org/larry/cpython350/pull-requests/10/issue-24975-fix-ast-compilation-for-pep/diff
Brett,
Should we do that in a separate issue targeting 3.6 only?
--
___
Python
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24981>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> I can be convenient to have a single Server object with *all* listening
> sockets. So I like the idea of supporting multiple ports. It's very cheap to
> support it.
I like the idea too, but I'm not sure how to redesign the function
Yury Selivanov added the comment:
> - accept host and port arguments being sequences and then we bind to all
> host:port combinations. Like if len(host) == N and len(port) == M, we bind to
> N*M sockets.
I can't think of a real life example for this. But if you need that, y
Yury Selivanov added the comment:
Yann, I'll commit this as soon as 3.5.0 and 3.4.4 are out.
--
___
Python tracker
<http://bugs.python.org/issue23630>
___
___
Yury Selivanov added the comment:
Thanks Nick and Larry for code reviews and merge!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Is this something that we should ship in 3.5.0rc3?
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24
New submission from Yury Selivanov:
Should we raise something like "'int' object is not an asynchronous iterable",
instead of "'async for' requires an object with __aiter__ method, got int"?
>>> foo().send(None)
Traceback (most recent call la
Yury Selivanov added the comment:
I saw this reddit thread:
https://www.reddit.com/r/Python/comments/3ewnwq/async_function_as_generator_for_async_for/
where people are struggling with understanding how 'async for' works. Which
led me to check what error messages we raise when we pa
Yury Selivanov added the comment:
TBH, I don't like the idea. It would take me some time to digest the code
every time I see this.
> lines = chain.from_iterable(itercm(open(f)) for f in fnames)
This looks like an extremely rare use case.
--
nosy: +ys
Yury Selivanov added the comment:
Larry, Matthias, Steve, Berker - I've mentioned this issue in the whatsnew
(applied Larry's patch with some modifications to address comments from Steve
and Matthias). Please review.
--
___
Python trac
Yury Selivanov added the comment:
It's meant to be private.
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Yury Selivanov added the comment:
> Agreed, but then why isn't it in the tests directory?
I think that the main reason is to make it possible for tests to import some
common functionality from 'asyncio' package, when you run them from the cloned
github asyncio repo.
I
Yury Selivanov added the comment:
> If we have decided that this is a "fixed bug", [..]
I'd call this a bug fix. The old syntax was completely unreadable.
Should I close this issue?
> [..] it should indeed be mentioned in what's new for 3.5 since it is a
>
Yury Selivanov added the comment:
What's new is now updated with description of this issue. Closing it now.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Yury Selivanov added the comment:
> Some modules in the "Improved Modules" section are out of lexicographic
> order: csv, ssl.
Yes, these two weren't properly ordered by *2nd* letter. Fixed.
>>-constructor. All converters defined in config parser (either by su
Yury Selivanov added the comment:
And can we point https://docs.python.org/3/ to 3.5 docs?
--
___
Python tracker
<http://bugs.python.org/issue25082>
___
___
Pytho
Yury Selivanov added the comment:
Larry,
Please rebuild the documentation, we've pushed the last round of edits in
746add37495c.
Also, could you please merge 3.5 into default -- I don't know how to resolve
some conflicts after your 3.5.0 -> 3.5 merge.
> I could add a &
Changes by Yury Selivanov :
--
nosy: +elvis
___
Python tracker
<http://bugs.python.org/issue24965>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> ssl should be between sqlite3 and subprocess.
It makes sense that ssl module description follows the socket module.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tr
Yury Selivanov added the comment:
Thanks, Serhiy!
--
___
Python tracker
<http://bugs.python.org/issue25082>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov:
The dropdown that allowed to switch the Python version for docs disappeared
with py3.5 release.
--
messages: 250700
nosy: eric.araujo, ezio.melotti, georg.brandl, larry, yselivanov
priority: high
severity: normal
status: open
title: documentation
Yury Selivanov added the comment:
The switcher isn't visible on all pages, I suspect we need to bust caches on
cdns/varnish
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
the patch lgtm
--
___
Python tracker
<http://bugs.python.org/issue25114>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> This looks like an important regression and we should fix it before 3.5.1
> goes out.
I agree. Any ETA on 3.5.1?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue25293>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> - it is less confusing, because it has the same name and using the same
> prototype as `ensure_future`
> - it accepts futures and awaitables
I like this idea.
--
___
Python tracker
<http://bug
Yury Selivanov added the comment:
> But honestly I *don't* want to encourage flipping back and forth between
> threads and event loops; I see it as a necessary evil. The name we currently
> have is fine from the POV of someone coding in the threaded world who wants
> to hand
Yury Selivanov added the comment:
> @yury: but where would you have gotten the awaitable in the first place? It's
> easy to see how to get a coroutine -- just define it (with either @coroutine
> or async def) and call it -- and I think that's the only use case that
> mat
Yury Selivanov added the comment:
>> Should I add a note to explain why the loop argument has to be explicitly
passed? (there is a note at the beginning of the `task functions` section
stating "In the functions below, the optional loop argument ...")
> Oh, that's a good
Yury Selivanov added the comment:
> The docs for getargspec currently read, "This function will be removed in
> Python 3.6." Why? We keep all sorts of old APIs for the sake of backward
> compatibility, why is this one different?
getargspec was deprecated since 3.0. Besid
Yury Selivanov added the comment:
Here's an example client implementation with writer.start_tls() (taken from my
debug code):
@asyncio.coroutine
def client(addr):
reader, writer = yield from asyncio.open_connection(
*addr, loop
New submission from Yury Selivanov:
See issue #20438 for more details
--
components: Library (Lib)
messages: 253499
nosy: yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Resurrect inspect.getargspec() in 3.6
type: behavior
versions: Python 3.6
Yury Selivanov added the comment:
> This is the situation I am in: coverage.py uses getargspec in a very simple
> way in its tooling. I support 2.7 and 3.5, so I have to do this:
try:
getargspec = inspect.getfullargspec
except AttributeError:
geta
Yury Selivanov added the comment:
> The thing is, we've adopted a policy that if something exists in python2.7 we
> shouldn't delete it in python3 until after 2.7 is officially out of
> maintenance (at the earliest), in order to facilitate single-source porting
> to pyt
Yury Selivanov added the comment:
Guido, Victor,
Please find attached a first draft of the patch. It's a very early attempt
(i.e. I'm not including unit tests/docstrings), and its primary purpose is to
gather initial feedback.
Some points:
1. As discussed earlier, the primary AP
Yury Selivanov added the comment:
> because in that case the handler isn't getting called from the Task __del__
It's possible to fix -- see the attached future.patch. And perhaps this should
be fixed in Future.__del__ and Task.__del__ -- ignoring BaseException
Yury Selivanov added the comment:
I see your points, but we're talking about BaseExceptions here --
KeyboardInterrupt, SystemExit etc. Those things usually mean that the program
has to crash.
--
___
Python tracker
<http://bugs.py
Yury Selivanov added the comment:
Trapping those exceptions in __del__ isn't good.
Another way to address this would be to at least modify call_exception_handler
to log when an exception handler raises a BaseException error.
--
___
Python tr
Yury Selivanov added the comment:
> No, you are talking about *all* exceptions, since they all descend from
> BaseException. Python's normal __del__ handling just prints the ignored
> exception to stdout, even if it is a BaseException. Why should asyncio be
> different (o
Yury Selivanov added the comment:
Guido, Victor, any thoughts about the (proto-)patch?
--
___
Python tracker
<http://bugs.python.org/issue23749>
___
___
Python-bug
New submission from Yury Selivanov:
Nested try..except statements with yields can loose reference to the current
exception.
The following code:
class MainError(Exception):
pass
class SubError(Exception):
pass
def main():
try:
raise MainError
Changes by Yury Selivanov :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue25612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
This was originally discovered here:
https://github.com/python/asyncio/issues/287
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue25
Changes by Yury Selivanov :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue25612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Another bug:
class MainError(Exception):
pass
class SubError(Exception):
pass
def main():
try:
raise MainError()
except MainError:
yield
coro = main()
coro.send(None)
coro.throw
Yury Selivanov added the comment:
Here's a patch the fixes the first problem (but __context__ bug is still open).
I'm not sure that the patch is correct :( But at least I've added new
unittests (one still failing)
--
keywords: +patch
Added file: http://bugs.pytho
Yury Selivanov added the comment:
Stéphane, sorry for not replying earlier, emails from bugs.python.org sometimes
go to spam.
[TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5),
line='async def foo(): pass'),
TokenInfo(type=1 (NAME), string='def&
Yury Selivanov added the comment:
ASYNC/AWAIT tokens are temporary and will be removed in 3.7
--
___
Python tracker
<http://bugs.python.org/issue25580>
___
___
Yury Selivanov added the comment:
> Are you suggesting that the note should state that these two are temporary?
Yes, that would be great.
> Or is this information available somewhere else, in What's new, for example?
Not directly, I think. It was detailed to some extent in P
Yury Selivanov added the comment:
We had this discussion when we were adding Awaitable, AsyncIterable etc. I
suggested to simply put them in the top-level 'abc' module (where ABCMeta is
defined).
--
nosy: +yselivanov
___
Python trac
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue25643>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> So until 3.4.4 is released this issue still may be considered as not fixed.
Since this issue is fixed in the repo, and will be shipped in the upcoming
3.5.1 and 3.4.4, I'd suggest to close this issue -- there is nothing to be do
Yury Selivanov added the comment:
Can someone work with me on fixing this issue? I think it's important to ship
3.5.1 with this resolved (and 3.4.4 FWIW).
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Good catch! Fixed in https://hg.python.org/cpython/rev/b34c42e46e7b
--
___
Python tracker
<http://bugs.python.org/issue25
Yury Selivanov added the comment:
> Thinking about the __context__ thing some more, I guess it might make sense
> for __context__ to be overwritten by the generator context. The same way it
> gets overwritten when you execute “raise” inside an exception handler.
Not sure I unders
New submission from Yury Selivanov:
When Python is compiled with readline, repeatedly pressing key in repl
breaks the repl prompt.
Below is what I see when I hit 4 times.
yury@ysmac ~/dev/py/cpython $ ./python.exe
Python 3.5.0+ (3.5:4ae62ddf7bc7+, Nov 18 2015, 14:52:57)
[GCC
Yury Selivanov added the comment:
> Is this related to the BSD editline library (libedit), or is the actual Gnu
> Readline library being used? Apparently you can check for "libedit" in
> readline.__doc__ to tell the difference.
Great suggestion. So on my machine, macpo
Yury Selivanov added the comment:
> I guess is the objection of putting concrete ABCs in the abc module is that
> the abc module contains the actual code to implement ABCs and not ABCs
> themselves.
I think it's a rather weak objection. Having some basic (and fundamental!)
Yury Selivanov added the comment:
Attached is a patch that uses different logic for tabulation. Instead of
returning '\t' from the completion callback, it instead calls explicit readline
API: "readline.insert_text('\t'); readline.redisplay()"
Please review.
---
Yury Selivanov added the comment:
Please see my patch for Issue 25660 -- instead of returning '\t' from the
completion function, I use readline API to modify the input buffer directly.
--
___
Python tracker
<http://bugs.python.o
Yury Selivanov added the comment:
Martin, you might be right here. Guido, do you think it's OK that SubError
doesn't have MainError in its __context__?
http://bugs.python.org/issue25612#msg254576
--
___
Python tracker
<http://bu
New submission from Yury Selivanov:
In the below snippet, SubError will propagate with __context__ set to None,
instead of MainError. Maybe this isn't a bug?
class MainError(Exception): pass
class SubError(Exception): pass
def main():
try:
raise Main
Yury Selivanov added the comment:
Anyways, here's a separate issue for the __context__ problem:
http://bugs.python.org/issue25683
--
___
Python tracker
<http://bugs.python.org/is
2401 - 2500 of 3098 matches
Mail list logo
