Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Ben Finney
Is this you? Claim Profile »
2 weeks ago
in Python Exception Handling Techniques - Doug Hellmann on Doug Hellmann
For the “second exception raised while still cleaning up from first exception” case, it's worth noting that PEP 3134 introduced “chained exceptions” via ‘raise barexception from fooexception’.
1 reply
dhellmann
I wasn't aware of that PEP, is it only in 3.x or has it been backported to 2.6 or 2.7?
3 months ago
in Instead of setting instance attributes within __init__ on t+1
One problem is it's more verbose, and rather unusual. The reader isn't going to expect what you're doing, which is always a negative when deciding whether to be clever in code :-)
Another problem is you've defined only a read-only property: the decorator wraps the getter, but the property has no setter (or deleter or docstring).
Another problem is you've defined only a read-only property: the decorator wraps the getter, but the property has no setter (or deleter or docstring).
1 reply
saluk
I have the opposite opinion - __init__ should not be doing anything OTHER than setting the default attributes. When I type a = Object(), I want a to be valid. Putting too much stuff inside of __init__ can make it harder to see why something is actually failing. Sometimes though, I do delegate out to other functions from __init__ which do more work if necessary.
The above just looks like a mess!
The above just looks like a mess!
9 months ago
in I just wrote another mock object framework. on t+1
Doesn't seem too useful; when the code under test attempts to call expected methods on an instance it'll fail with 'AttributeError'. A mock object should pretend it's the object being mocked, surely?
- 2 points
- Jump to »
Matt Wilson
Hi Ben,
I probably should have included a few example uses. Pretend I want to mock an object that has an attribute named ivr_sends which is a list of strings. I'd do this:
mm = BazMock(ivr_sends=['abc', 'def'])
Now my test code can access mm.ivr_sends just fine.
And now pretend you need to mock attributes on attributes:
mm = BazMock(x=BazMock(y=[BazMock(a=1, b=2), BazMock(a=3, b=4)]))
And now I can access mm.x.y[0].a.
For methods, you'd need to graft on definitions like this:
def fake_foo(x):
return "99"
mm.foo = fake_foo
I've been told that there are better mock objects out there, that do stuff like inspect a module or a class and create mocks automatically.
I'm dragging my feet about learning them. Let me know if you find one you like.
I probably should have included a few example uses. Pretend I want to mock an object that has an attribute named ivr_sends which is a list of strings. I'd do this:
mm = BazMock(ivr_sends=['abc', 'def'])
Now my test code can access mm.ivr_sends just fine.
And now pretend you need to mock attributes on attributes:
mm = BazMock(x=BazMock(y=[BazMock(a=1, b=2), BazMock(a=3, b=4)]))
And now I can access mm.x.y[0].a.
For methods, you'd need to graft on definitions like this:
def fake_foo(x):
return "99"
mm.foo = fake_foo
I've been told that there are better mock objects out there, that do stuff like inspect a module or a class and create mocks automatically.
I'm dragging my feet about learning them. Let me know if you find one you like.
9 months ago
in Why Google won’t do evil on The Technology Liberation Front
> There’s no denying that Google has the capacity to do some pretty heinous things with all the sensitive data stored on its servers.
Okay, so we agree that all Google now needs is motivation to do evil; or, phrased differently, lack of motivation to behave virtuously.
> But the relevant question isn’t whether Google could do evil, but whether it realistically will.
Since the information they gather is theirs forever — the users certainly have no practical control over it once it's granted to Google — that “will” becomes “will, ever, at any point in the future”.
> What incentive is there for Google to do anything but keep private data as secure as humanly possible?
Here you make the fallacy of assuming that Google's *current* model is sufficient guarantee that they will *forever* have incentive to be virtuous with the data we give them every day over time.
The correct question is: How likely is it that Google's model, leadership, or shareholder pressures, forever into the future, will always be sufficient to constrain Google to act virtuously with the data gathered on all parties that interact with them over their entire history?
Okay, so we agree that all Google now needs is motivation to do evil; or, phrased differently, lack of motivation to behave virtuously.
> But the relevant question isn’t whether Google could do evil, but whether it realistically will.
Since the information they gather is theirs forever — the users certainly have no practical control over it once it's granted to Google — that “will” becomes “will, ever, at any point in the future”.
> What incentive is there for Google to do anything but keep private data as secure as humanly possible?
Here you make the fallacy of assuming that Google's *current* model is sufficient guarantee that they will *forever* have incentive to be virtuous with the data we give them every day over time.
The correct question is: How likely is it that Google's model, leadership, or shareholder pressures, forever into the future, will always be sufficient to constrain Google to act virtuously with the data gathered on all parties that interact with them over their entire history?
1 reply
Ryan Radia
Google doesn't keep its users' data forever. It anonymizes search logs after 9 months, and if you have a Gmail account, when you hit "Delete" that data will be completely wiped off Google's servers and its backups within a matter of months.
And it's not even necessary for Google to care about behaving "virtuously." To do anything but safeguard privacy would be suicidal, even if Google's business model were to change down the line. Google can't change it privacy policies to the detriment of its users without their explicit permission.
There are privacy risks to using Google's services, as there are with using any company's services where that company will have possession of personal info. With respect to Google, I think these risks are fairly trivial, but different people have different levels of risk aversion. Fortunately, nobody has to use Google--you don't even have to give Google your IP address to use it search engine (A topic I will be discussing in greater detail soon).
And it's not even necessary for Google to care about behaving "virtuously." To do anything but safeguard privacy would be suicidal, even if Google's business model were to change down the line. Google can't change it privacy policies to the detriment of its users without their explicit permission.
There are privacy risks to using Google's services, as there are with using any company's services where that company will have possession of personal info. With respect to Google, I think these risks are fairly trivial, but different people have different levels of risk aversion. Fortunately, nobody has to use Google--you don't even have to give Google your IP address to use it search engine (A topic I will be discussing in greater detail soon).
1 year ago
in Pep Turds on jessenoller.com comments
Vim is definitely turd-friendly. You've likely seen them: they look like "vim: foo bar=baz :".
I usually include the following Emacs-and-Vim turd in my reStructuredText documents:
..
Local Variables:
mode: rst
coding: utf-8
End:
vim: filetype-rst :
I usually include the following Emacs-and-Vim turd in my reStructuredText documents:
..
Local Variables:
mode: rst
coding: utf-8
End:
vim: filetype-rst :
2 replies
Ben Finney
Bah. Two problems with that turd: it should read "filetype=rst", and indentation was not preserved by the comment mechanism.
jnoller
Huh, I didn't know you could embed vim turds into documents.
In seriousness, I sort of dislike embedding editor-specific "nuggets of joy" into documents - I can see why you might do it, but still.
In seriousness, I sort of dislike embedding editor-specific "nuggets of joy" into documents - I can see why you might do it, but still.
