Yury Selivanov added the comment:
Is this still an issue?
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14367
___
___
Python
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20763
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20763
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20765
___
___
Python-bugs-list
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +larry, ncoghlan, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20786
Yury Selivanov added the comment:
Larry, I think the problem is that
property.__delete__.__text_signature__
'(instance, /)'
but should be something like '($self, instance, /)'.
What do you think?
--
___
Python tracker rep
Changes by Yury Selivanov yselivanov...@gmail.com:
--
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20786
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20791
___
___
Python-bugs
Yury Selivanov added the comment:
Larry, Nick, what do you think?
I'd like this to be fixed in 3.4.0...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20786
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20807
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20810
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
assignee: - yselivanov
nosy: +larry, ncoghlan, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20817
Changes by Yury Selivanov yselivanov...@gmail.com:
--
assignee: - yselivanov
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20816
Yury Selivanov added the comment:
Why are you trying to get signature of 'datetime.datetime.today.__call__'?
__call__ in this case is a generic python object -- method-wrapper. It is used
to make a classmethod. And the signature that getargspec is returning for it is
correct.
--
nosy
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20828
___
___
Python-bugs-list
Changes by Yury Selivanov yselivanov...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20786
New submission from Yury Selivanov:
http://hg.python.org/cpython/rev/c9861ec8754c
changeset: 89461:c9861ec8754c
user:Yury Selivanov yseliva...@sprymix.com
date:Sun Mar 02 12:25:27 2014 -0500
summary:
Issue #20786: Fix signatures for dict.__delitem__ and property.__delete__
Yury Selivanov added the comment:
Mike, this is now fixed. I've created an issue for tracking of getting this fix
in 3.4.0: #20829.
Thanks for finding this bug!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20786
Yury Selivanov added the comment:
OK, I see.
I'd recommend you to take a look how inspect.signature is implemented in 3.3 or
3.4 (and maybe backport it to python 2 and use the new API).
To quickly fix your code, I'd suggest the following modifications:
_WrapperDescriptor = type(type.__call__
Yury Selivanov added the comment:
Can we instead re-engineer asyncio logging to have logger calls in a separate
thread?
I.e. `logger` is a proxy object, that puts logging calls in a queue, and there
would be another thread to block on the queue and do the actual logging. This
way it won't
Yury Selivanov added the comment:
If you really need network logging you should be able to configure a handler
that puts things in a queue whose other end is serviced by an asyncio task.
There should be no need to mess with the type of the logger object.
It's something that is easy
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20855
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13936
___
___
Python-bugs
Yury Selivanov added the comment:
Larry, so do you think we can have this one cherry-picked?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20829
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20894
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +vinay.sajip, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20918
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18931
___
___
Python-bugs
Yury Selivanov added the comment:
Why there is no 'review' link for the new patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18931
Yury Selivanov added the comment:
Still no review link. Somehow you managed to upload the first patch correctly.
Does the new one apply cleanly on the default branch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18931
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: -yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20739
___
___
Python-bugs
Yury Selivanov added the comment:
If nobody has any objections on this, I'm going to commit this in 3.5 soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20334
Yury Selivanov added the comment:
Guido, good idea. Committed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20668
___
___
Python-bugs-list
Yury Selivanov added the comment:
Fixed for 3.4.1 and 3.5.
Thank you Jeremiah!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20816
Yury Selivanov added the comment:
Fixed for 3.4.1 and 3.5.
Thanks for the contribution!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20817
Yury Selivanov added the comment:
So... should we expose two keyword only parameters for
Signature.from_callable() and signature():
- 'follow_wrapped=True' to follow __wrapped__ chains;
- 'keep_bound_arg=False' to skip/include first bound arg
New submission from Yury Selivanov:
There is a small detail in the current Signature class implementation, in
regards to how partial signatures are treated. Consider the following example:
def foo(a, b): pass
foo_partial = functools.partial(foo, 'spam')
Now, the signature
Yury Selivanov added the comment:
@Nick:
Oops: already bound positional-*only* arguments should be hidden.
Hm, good catch. I'm not sure we currently do this. I'll check if this needs to
be fixed (in 3.4.1 too).
I'm +0 on new types to clean that up if necessary, but would prefer it if
we
Yury Selivanov added the comment:
@Nick:
Agreed on positional-only stuff.
If arguments bound by position disappear from the signature, and those
bound by keyword are mapped to keyword-only parameters with a default, we
should get a valid and accurate signature.
But what about my example
Yury Selivanov added the comment:
@Nick: oh, it took me some time to realize that your suggestion to transform
positional-or-keyword to keyword-only parameters is correct. If we do this, we
no longer need '_partial_kwarg' hack. I'll work on the patch. Thank you
Yury Selivanov added the comment:
@Nick:
Ouch... I'm halfway through the implementation, and it seems like your idea
isn't going to work.
Example (from unittest):
def foo(a=1, b=2, c=3): pass
_foo = partial(foo, a=10, c=13)
Now, the signature for _foo, with your logic applied
Yury Selivanov added the comment:
@R. David:
Yes, thank you, David. Too bad I haven't seen your last messages before I
started working on the patch...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21117
Yury Selivanov added the comment:
First, I think this is a bug in partial, so I think we need to decide what,
if anything, to do about that first, before we decide if signature needs to
compensate for it or not.
Agree. Although, it looks like it's not something that partial is doing
Yury Selivanov added the comment:
Although, it looks like it's not something that partial is doing, it seems
like this call logic is implemented somewhere way deeper.
Forget about what I said.
Yes, it's a bug in partial. Fixing it, will require having the code from
Signature.bind reflected
Yury Selivanov added the comment:
Oh, wait, it *does* have a usable signature. It's just that all the
*subsequent* positional-or-keyword parameters also have to be marked as
keyword-only.
Interesting idea. I'll incorporate this logic into the patch
Yury Selivanov added the comment:
Please review the attached patch.
Here's the new partial signature semantics:
foo(a, b, /, c, d, *args, e)
partial(foo, 10) - (b, /, c, d, *args, e)
partial(foo, 10, c=11) - (b, /, *, c=11, d, e)
partial(foo, 10, 20, 30) - (d, *args, e)
partial
Yury Selivanov added the comment:
Any comments on the patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21117
___
___
Python-bugs-list
Changes by Yury Selivanov yselivanov...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21117
Changes by Yury Selivanov yselivanov...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20334
Yury Selivanov added the comment:
Hm... Can we also commit this to 3.3?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21209
___
___
Python-bugs
Yury Selivanov added the comment:
3.3 is in security-fix only mode.
Yeah, but this is a core language bug. I believe some people may be stuck on
3.3 with broken 'yield from' for whatever reason, which will cause hard to find
bugs in 3.3 compatible libraries (like asyncio/tulip). I think we
Yury Selivanov added the comment:
Guido: please take a look at the patch corowrapper_01.patch.
--
Added file: http://bugs.python.org/file34832/corowrapper_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21209
Changes by Yury Selivanov yselivanov...@gmail.com:
--
resolution: fixed -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21209
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21217
___
___
Python-bugs
Yury Selivanov added the comment:
Please see the corowrapper_02.patch. I've removed the version check, now it's
much simpler.
--
Added file: http://bugs.python.org/file34850/corowrapper_02.patch
___
Python tracker rep...@bugs.python.org
http
Yury Selivanov added the comment:
I don't like this idea. inspect module is about introspection, and not about
interpreting its results. I'd keep this function in pydoc and document it if
there is noticeable demand for it.
--
___
Python tracker rep
Yury Selivanov added the comment:
[...] CoroWrapper.send() signature is different from a real generator's
send() method, but I think that send() to a coroutine is an internal detail
anyway [...]
Yeah, and since it's used in debug mode only, I think we should be safe.
When you commit, can
Changes by Yury Selivanov yselivanov...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21209
Yury Selivanov added the comment:
Guido, I'm feeling a bit uncomfortable with the patch I pushed. I think we
should adjust the solution, to avoid having arguments to 'gen.send' packed in
two nested tuples. Please take a look at the new patch (corowrapper_03.patch).
It adds some amount
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21235
___
___
Python-bugs
Yury Selivanov added the comment:
How about we deprecate with a warning getfullargspec(); deprecate getargspec()
in docs only (in 3.6 we'll fully deprecate all function parameters API except
Signature)?
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
I should check, but I think that Python create a tuple for you if you don't
pass directly a tuple, so it's not very different.
That's what I thought, but still, better to have the code clearly expressing
what it does, than relying on obscure implementation
Yury Selivanov added the comment:
I'd +1 for:
1. Deprecating getfullargsspec in docs;
2. Deprecating getargspec in docs and code (since it's an ancient and outdated
API)
Brett?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Yury Selivanov added the comment:
Apart from one nit, the patch is looking good.
Also, could you please sign the contributor agreement, as described here:
https://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement
--
___
Python
Changes by Yury Selivanov yselivanov...@gmail.com:
--
assignee: - yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1764286
___
___
Python
Yury Selivanov added the comment:
Claudiu: I'll take a look at your patch, thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21217
Yury Selivanov added the comment:
David:
The precedent has already been set by the 'cleandoc' function, I think. This
one seems to go right along with that one.
What do you think if we keep the function in pydoc module, but document it and
make it public? I agree
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +vinay.sajip, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21245
Yury Selivanov added the comment:
Nick, good catch. OK, let's just deprecate it in the docs for 3.5, so people
(hopefully) will not write new code with it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20438
Yury Selivanov added the comment:
I had plans to copy some documentation from python docs to asyncio docstrings.
I'll try to do this sometime this week. Thanks for reminding us about the issue!
--
assignee: - yselivanov
nosy: +gvanrossum, haypo, yselivanov
Yury Selivanov added the comment:
My bad. But I think docstrings should NOT be just copies of the separate
docs.
I agree. I didn't want to blindly copy them, but rather use existing
documentation as guidance baseline.
--
___
Python tracker rep
Yury Selivanov added the comment:
OK, since it's two-and-a-half votes against one, let's do this. I'll do the
final review of the patch and commit it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12916
Yury Selivanov added the comment:
The current patch proposes to add inspect.splitdoc(obj), instead of
pydoc.splitdoc(doc). The former takes an object, extracts documentation out of
it, and returns a tuple. The latter, just splits the passed doc string.
If you want this function in inspect
Yury Selivanov added the comment:
In the inspect module, I think all the functions take a object and not a
string, it's the reason why I included the code of pydoc.getdoc() into
inspect.splitdoc().
I understand. But you also do inspect.getdoc or inspect.getcomments, which I
don't really
Yury Selivanov added the comment:
Are you agree with that, or there is a good way for this kind of
improvement?
Having a unittest to check if a deprecated functionality is removed in the
future versions was Brett's idea, and I like it. So I think it's good to do the
same here. Your way
Yury Selivanov added the comment:
I'd keep the name (splitdoc), and let it receive a string. But let's hear
what Eric David think about it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12916
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21288
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +christian.heimes, gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21288
Yury Selivanov added the comment:
On 2014-04-17, 5:02 PM, Christian Heimes wrote:
Christian Heimes added the comment:
A callable wouldn't work for the OpenSSL back end of PBKDF2. The function
takes a digest pointer. I have to think about a solution...
Sorry for the brevity, I still don't
Yury Selivanov added the comment:
Armin, FWIW, I don't think it's possible to push this API change in 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21288
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +ncoghlan, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21294
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +haypo, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21302
___
___
Python
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21314
___
___
Python-bugs
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
___
___
Python-bugs
Yury Selivanov added the comment:
In Python2.7, the cls parameter shows up in pydoc:
frombuf(cls, buf) from __builtin__.type
Construct a TarInfo object from a 512 byte string buffer.
In 3.5, it doesn't:
frombuf(buf, encoding, errors) from builtins.type
Construct
Yury Selivanov added the comment:
Yeah, I'm closing this issue.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21399
Yury Selivanov added the comment:
Thanks, I'll take a look at the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1218234
___
___
Python
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
___
___
Python-bugs
Yury Selivanov added the comment:
FWIW, this can also be resolved by fixing Queue.full to do self.qsize() =
self._maxsize instead of self.qsize() == self._maxsize.
I generally don't like implicit casts as they break duck typing.
--
___
Python
Yury Selivanov added the comment:
This behaviour is indeed a bug. However, I think that the solution you propose
is wrong.
If we ignore invalid contents of __signature__ we are masking a bug or
incorrect behaviour. In this case, you should have checked the requested
attribute name
Yury Selivanov added the comment:
That's the intended and documented behaviour, see
https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.arguments.
You can easily implement the functionality you need by iterating through
Signature.parameters and copying defaults
Yury Selivanov added the comment:
Since 3.4, help() uses signature.
Closing this one.
--
nosy: +yselivanov
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17424
Changes by Yury Selivanov yselivanov...@gmail.com:
--
assignee: - yselivanov
keywords: +needs review
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21801
Yury Selivanov added the comment:
Ryan,
Can you explain the use case for it? What's the problem you're trying to solve?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21684
Yury Selivanov added the comment:
Fixed in 3.4 and 3.5.
Thanks for the bug report!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21801
Yury Selivanov added the comment:
@Guido, @Yury: What do you think of log_destroyed_pending_task.patch? Does it
sound correct?
Premature task garbage collection is indeed hard to debug. But at least, with
your patch, one gets an exception and has a chance to track the bug down. So
I'm +1
Yury Selivanov added the comment:
But I can't think of any use case when it would be undesirable to include the
extra parameters
One use case is that you are actually loosing information what arguments
Signature.bind() was called with, when defaults are included. In some cases
Yury Selivanov added the comment:
Thanks, Antony, this is a good catch. Your suggestion seems like a good idea.
I'll look into this more closely soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20334
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22203
___
___
Python-bugs
Yury Selivanov added the comment:
Antonie, I'm attaching a patch (issue20334-2.01.patch) to this issue which
should fix the problem. Please review.
--
Added file: http://bugs.python.org/file36607/issue20334-2.01.patch
___
Python tracker rep
Yury Selivanov added the comment:
Antony, I've tweaked the patch a bit and it's now in default branch. Thank you!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20334
401 - 500 of 3072 matches
Mail list logo
