On Sat, Dec 31, 2016 at 12:33 AM, Nick Coghlan wrote:
> On 31 December 2016 at 05:53, Ethan Furman wrote:
>> On 12/30/2016 07:10 AM, Chris Angelico wrote:
>>> What module would be appropriate, though?
>>
>> Well, DynamicClassAttribute is kept in the types
On 31 December 2016 at 05:53, Ethan Furman wrote:
> On 12/30/2016 07:10 AM, Chris Angelico wrote:
>
> Actually, that makes a lot of sense. And since "property" isn't magic
>> syntax, you could take it sooner:
>>
>> from somewhere import property
>>
>> and toy with it that
On 12/30/2016 07:10 AM, Chris Angelico wrote:
Actually, that makes a lot of sense. And since "property" isn't magic
syntax, you could take it sooner:
from somewhere import property
and toy with it that way.
What module would be appropriate, though?
Well, DynamicClassAttribute is kept in
On Sat, Dec 31, 2016 at 1:55 AM, Nick Coghlan wrote:
> Rather than changing the descriptor protocol in general, I'd personally be
> more amenable to the idea of *property* catching AttributeError from the
> functions it calls and turning it into RuntimeError (after a suitable
On 26 December 2016 at 21:23, Zahari Dim wrote:
> > There are a lot of entirely valid properties that look something like
> this:
> >
> >
> > @property
> > def attr(self):
> > try:
> > return data_store[lookup_key]
> > except KeyError:
> >
On Tue, Dec 27, 2016 at 9:11 PM, Zahari wrote:
> This looks like a good idea. Note that there is also getattr(X(), 'y',
> 'default') that would have to behave like this.
>
Forgot about that. Feel free to enhance the hasattr replacement. I
still think the parameterization of
> So here's a two-part proposal that would solve Zaheri's problem:
>
> 1) Enhance AttributeError to include arguments for the parts in
> quotes, for i18n independence.
> 2) Provide, in the docs, a hasattr replacement that checks the exception's
> args.
>
> The new hasattr would look like
> There are a lot of entirely valid properties that look something like this:
>
>
> @property
> def attr(self):
> try:
> return data_store[lookup_key]
> except KeyError:
> raise AttributeError("attr")
But wouldn't something like this be implemented
On 26 December 2016 at 04:24, Zahari Dim wrote:
> Hi,
>
> The other day I came across a particularly ugly bug. A simplified case
> goes like:
>
> class X:
> @property
> def y(self):
> return self.nonexisting
>
> hasattr(X(),'y')
>
> This returns False because
On Mon, Dec 26, 2016 at 8:03 AM, Nick Timkovich wrote:
> Are you saying that hasattr returning False was hiding a bug or is a bug?
> The former could be annoying to track down, though hasattr(X, 'y') == True.
> For the latter, having hasattr return False if an
Are you saying that hasattr returning False was hiding a bug or is a bug?
The former could be annoying to track down, though hasattr(X, 'y') == True.
For the latter, having hasattr return False if an AttributeError is raised
would allow the property decorator to retain identical functionality if
Hi,
The other day I came across a particularly ugly bug. A simplified case
goes like:
class X:
@property
def y(self):
return self.nonexisting
hasattr(X(),'y')
This returns False because hasattr calls the property which in turn
raises an AttributeError which is used to determine
12 matches
Mail list logo