Andrey Fedorov added the comment:
Here's the full extension of the example from documentation that doesn't
seem to handle classes and functions consistently:
import mock
patches = {
'requests_get': 'requests.get',
'mymodule_Class1': 'mymodule.Class1'
}
root_mock
Andrey Fedorov added the comment:
To clarify, this is how I would expect these two functions to work together
"out of the box"
patches = { 'requests_get': 'requests.get', ... }
root_mock = mock.Mock()
for name, path in patches.items():
m = mock.patch(path, auto
Andrey Fedorov added the comment:
There's some vagueness on how this is implemented, but I would prefer
manager.attach_mock to also work with whatever the return value of patch()
is.
On Fri, Nov 11, 2016 at 12:08 PM, Syed Suhail Ahmed <rep...@bugs.python.org>
wrote:
>
> Syed Suhail
Changes by Andrey Fedorov <and...@humblebundle.com>:
--
title: mock.attach_mock should work with return value of patch() ->
mock.attach_mock should work with any return value of patch()
___
Python tracker <rep...@bugs.pytho
New submission from Andrey Fedorov:
The attach_mock in the following code sample fails silently:
>>> from mock import patch, Mock
>>> p = patch('requests.get', autospec=True)
>>> manager = Mock()
>>> manager.attach_mock(p.start(), 're
Hi all,
So from what I understand, Jython translates Python code into JVM byte code.
Does anyone know why this was chosen instead of translating Python bytecode
to JVM bytecode directly? It seems that it would be a lot easier to get
Jython up-to-speed if there could be some shared components
On Wed, Mar 10, 2010 at 12:24 AM, Rami Chowdhury rami.chowdh...@gmail.com
wrote:
Could you tell us *why* you need to down-cast x? Explicit type-casting is
usually unnecessary in Python...
Sure! It's related to the longer question I unwisely asked during PyCon [1]
(when no one had time to read
So I have `x', a instance of class `Foo'. I also have class `Bar', a class
extending `Foo' with a couple of methods. I'd like to down cast x as
efficiently as possible. Is it OK to just set `x.__class__ = Bar' and expect
things to work OK in all major versions of CPython?
--
I implemented a Sieve of
Eratostheneshttp://en.wikipedia.org/wiki/Sieve_of_Eratosthenesprimes
algorithm using generators:
http://gist.github.com/309109
This code which chains together 500 generators works fine (~1/20th of a
second) on my laptop. The code which chaines 501 generators (s/498/499/
Ack, just ran it from shell, realized my editor was just choking on a
maximum recursion depth exceeded RuntimeError. Didn't realize generators
used the call stack...
- Andrey
On Fri, Feb 19, 2010 at 2:47 PM, Andrey Fedorov anfedo...@gmail.com wrote:
I implemented a Sieve of
Eratostheneshttp
It seems intuitive to me that the magic methods for overriding the +, -, ,
==, , etc. operators should have no sideffects on their operands. Also,
that == should be commutative and transitive, that and should be
transitive, and anti-commutative.
Is this intuition written up in a PEP, or assumed
18, 2010 at 8:19 AM, Andrey Fedorov anfedo...@gmail.comwrote:
It seems intuitive to me that the magic methods for overriding the +, -,
, ==, , etc. operators should have no sideffects on their operands. Also,
that == should be commutative and transitive, that and should be
transitive
Two questions:
1 - is it documented that o.__dict__[attr] is a reliable way to bypass
property methods?
2 - can one bypass a property method if the class has __slots__?
Reason: I have a couple of different flavors of request objects which I need
to make lazily conform to a standard interface. As
Is there a standard function that will check whether certain *args, and
**kwargs satisfy a argspec of a function (s.t. it does not throw a
TypeError). Say:
def foo(a,b=1):
pass
check(foo, 1,2) # True
check(foo, 1) # True
check(foo) # False
check(foo, 1, a=2) # False
Cheers,
Andrey
--
Will do, thanks. Doing it to make a @curry decorator, which only executes a
function once enough arguments have been passed in.
- Andrey
On Thu, Oct 29, 2009 at 6:53 PM, Chris Rebert c...@rebertia.com wrote:
On Thu, Oct 29, 2009 at 11:43 AM, Andrey Fedorov anfedo...@gmail.com
wrote
As far as I can tell, a generator's .next() is equivalent to .send(None). Is
this true?
If so, aren't they unified in a method with a single argument which defaults
to None?
- Andrey
--
http://mail.python.org/mailman/listinfo/python-list
Hi all,
I've written a function [1] called apply_some which takes a set of
keywords arguments, filters only those a function is expecting, and
calls the function with only those arguments. This is meant to
suppress TypeErrors - a way to abstract the logic which checks what
arguments a passed-in
When a web request is made, my Django views are called with argument
`user_id' present if someone is logged in, and set to None if the request is
anonymous. The response varies based on this argument - someone pulling a
team's information will get their relationship to the team if they are
logged
18 matches
Mail list logo