Thank you Ethan and Chris for the tips. I may be able to adapt that
decorator for my use cases -- I hadn't thought of using something like
that. Ethan, I'll drop a note over at Python Ideas too with some details
about this.
Thanks for your help,
Jason
On Tue, May 2, 2017 at 9:47 PM, Chris Angel
On Wed, May 3, 2017 at 3:05 PM, Ethan Furman wrote:
>> I was going to hardcode AttributeError, which would have made it more
>> obvious and simpler, but then a single-purpose decorator (and if you
>> do that, why not just wrap your code in try/except manually?).
>> Obviously for production it need
On 05/02/2017 09:57 PM, Chris Angelico wrote:
On Wed, May 3, 2017 at 2:39 PM, Ethan Furman wrote:
On 05/02/2017 07:47 PM, Chris Angelico wrote:
On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:
Until then Chris' decorator is probably the easiest work around -- but
you
should only catch
On Wed, May 3, 2017 at 2:39 PM, Ethan Furman wrote:
> On 05/02/2017 07:47 PM, Chris Angelico wrote:
>>
>> On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:
>
>
>>> Until then Chris' decorator is probably the easiest work around -- but
>>> you
>>> should only catch AttributeError, not everything
On 05/02/2017 07:47 PM, Chris Angelico wrote:
On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:
Until then Chris' decorator is probably the easiest work around -- but you
should only catch AttributeError, not everything.
It does. (Or rather, it catches only those exception(s) listed as
pa
On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:
> Until then Chris' decorator is probably the easiest work around -- but you
> should only catch AttributeError, not everything.
It does. (Or rather, it catches only those exception(s) listed as
parameters.) Any other exceptions pass through un
On 05/02/2017 05:59 PM, Jason Maldonis wrote:
@Steve they asked me to move it here because it was more fitting. I hope that's
okay?
Yes, it's okay. ;)
After some testing, it looks like I'm okay with how things work if the
problem-object isn't a descriptor (although I do
still things it's
On Wed, May 3, 2017 at 10:59 AM, Jason Maldonis wrote:
> Here's an example where the underlying error is completely hidden:
>
> class A(object):
> def _some_complex_code_hidden_from_the_user(self):
> # Run a bunch of complex stuff that raises an attribute error
> internally
> #
@Steve they asked me to move it here because it was more fitting. I hope
that's okay?
After some testing, it looks like I'm okay with how things work if the
problem-object isn't a descriptor (although I do still things it's a bit
odd that an error gets squashed, but it's no big deal).
However, I
On Wed, 3 May 2017 10:11 am, Ethan Furman wrote:
> On 05/02/2017 11:16 AM, Jason Maldonis wrote:
>
>> Here is the simplest example showing what I mean (there are many more
>> complicating variations this, and unfortunately I'm running into some of
>> them):
[...]
I believe this is the wrong li
On 05/02/2017 11:16 AM, Jason Maldonis wrote:
Here is the simplest example showing what I mean (there are many more
complicating variations this, and unfortunately I'm running into some of
them):
class A(object):
def __getattr__(self, attr):
raise AttributeError("raised from A.__g
Moving this conversation from python-dev to here because I shouldn't have
sent it to python-dev.
My original message:
I'm working on a large class architecture and I find myself often
overloading __getattr__. I am continuously running into the issue where I
want __getattr__ to have access to the
12 matches
Mail list logo
