2017-07-08 Jan Kaliszewski dixit:
> return wrapper
Should be:
return property(wrapper)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf
2017-06-25 Greg Ewing dixit:
> > (2) There's a *specific* problem with property where a bug in your
> > getter or setter that raises AttributeError will be masked,
> > appearing as if the property itself doesn't exist.
[...]
> Case 2 needs to be addressed within the method concerned on a
> case-
On 29 June 2017 at 05:14, Nathaniel Smith wrote:
> What about modules that want to raise ImportError to indicate that they
> aren't available on the current system, perhaps because some of their
> dependencies are missing? For example, 'import ssl' should raise an
> ImportError if 'ssl.py' is pres
On 28.06.2017 21:14, Nathaniel Smith wrote:
With PEP 479 there was a different and better way to generate a
StopIteration if you wanted one (just 'return'). Here I'm afraid
existing projects might actually be relying on the implicit exception
leakage in significant numbers :-/
My concern as w
On 28.06.2017 15:26, Nick Coghlan wrote:
1. In 3.3+ you can just catch ImportError, check "exc.name", and
re-raise if it's not for the module you care about
I see, didn't know that one. I gave it a try and it's not 100% the
behavior I have expected, but one could workaround if the valid packag
On Jun 28, 2017 6:26 AM, "Nick Coghlan" wrote:
On 28 June 2017 at 21:48, Sven R. Kunze wrote:
> As it was snipped away, let me ask again:
>
> I don't see how this helps differentiating shallow and nested exceptions
> such as:
>
> try:
> with exception_guard(ImportError):
> import mys
On Wed, Jun 28, 2017 at 12:25:12PM +1000, Nick Coghlan wrote:
[...]
> So while I prefer "contextlib.convert_exception" as the name (rather
> than the "exception_guard" Steven used in his recipe), I'd definitely
> be open to a bugs.python.org RFE and a PR against contextlib to add
> such a construc
On 28 June 2017 at 21:48, Sven R. Kunze wrote:
> As it was snipped away, let me ask again:
>
> I don't see how this helps differentiating shallow and nested exceptions
> such as:
>
> try:
> with exception_guard(ImportError):
> import myspeciallib
> except RuntimeError: # catches shallo
On 28.06.2017 08:00, Nick Coghlan wrote:
Right, and I'd like us to keep in mind the KeyError -> AttributeError
(and vice-versa) use case as well. Similar to ExitStack, it would be
appropriate to make some additions to the "recipes" section in the
docs that covered things like "Keep AttributeError
On 28 June 2017 at 13:16, Chris Angelico wrote:
> On Wed, Jun 28, 2017 at 12:25 PM, Nick Coghlan wrote:
>> While generator functions now do that implicitly for StopIteration,
>> and "raise X from Y" lets people write suitable exception handlers
>> themselves, we don't offer an easy way to do it w
On Wed, Jun 28, 2017 at 12:25 PM, Nick Coghlan wrote:
> While generator functions now do that implicitly for StopIteration,
> and "raise X from Y" lets people write suitable exception handlers
> themselves, we don't offer an easy way to do it with a context manager
> (with statement as stack bound
On 28 June 2017 at 06:03, Chris Angelico wrote:
> On Wed, Jun 28, 2017 at 5:49 AM, Sven R. Kunze wrote:
>> I would agree with you here but this "refactoring principle in Python"
>> doesn't work for control flow.
>>
>> Just look at "return", "break", "continue" etc. Exceptions are another way
>> o
On Wed, Jun 28, 2017 at 5:49 AM, Sven R. Kunze wrote:
> On 27.06.2017 13:41, Nick Coghlan wrote:
>>
>> The shallow exception notion breaks a fairly fundamental refactoring
>> principle in Python: you should be able to replace an arbitrary
>> expression with a subfunction or subgenerator that produ
On 27.06.2017 13:41, Nick Coghlan wrote:
The shallow exception notion breaks a fairly fundamental refactoring
principle in Python: you should be able to replace an arbitrary
expression with a subfunction or subgenerator that produces the same
result without any of the surrounding code being able
On 27 June 2017 at 02:29, Sven R. Kunze wrote:
> On 24.06.2017 01:37, MRAB wrote:
>>
>> I think a "shallow exception" would be one that's part of a defined API,
>> as distinct from one that is an artifact of the implementation, a leak in
>> the abstraction.
>
> I like the "shallow exception" idea
On 24.06.2017 01:37, MRAB wrote:
I think a "shallow exception" would be one that's part of a defined
API, as distinct from one that is an artifact of the implementation, a
leak in the abstraction.
I like the "shallow exception" idea most. It's simple and it covers most
if not all issues. You
On 24/06/2017 11:03, Steven D'Aprano wrote:
On Sat, Jun 24, 2017 at 01:02:55PM +1200, Greg Ewing wrote:
In any case, this doesn't address the issue raised by the OP,
which in this example is that if the implementation of
bah.__getitem__ calls something else that raises an IndexError,
there's
On Sat, Jun 24, 2017 at 11:45:25PM +1000, Nick Coghlan wrote:
> While I used to think that, I'm no longer sure it's true, as it seems
> to me that a `contextlib.convert_exception` context manager could help
> with both of them.
Here is a recipe for such a context manager which is also useable as
On 24 June 2017 at 22:31, Greg Ewing wrote:
> Steven D'Aprano wrote:
>> I think we're over-generalizing this problem. There's two actual issues
>> here, and we shouldn't conflate them as the same problem:
>>
>> (1) People write buggy code based on invalid assumptions of what can and
>> can't raise
Steven D'Aprano wrote:
class X:
def __getitem__(self, n):
if n < 0:
n += len(self)
if not 0 <= n < len(self):
raise IndexError
...
class Y:
def __getitem__(self, n):
self._validate(n)
...
def _validate(self, n):
if n < 0
On Sat, Jun 24, 2017 at 01:02:55PM +1200, Greg Ewing wrote:
> In any case, this doesn't address the issue raised by the OP,
> which in this example is that if the implementation of
> bah.__getitem__ calls something else that raises an IndexError,
> there's no easy way to distinguish that from one
Cameron Simpson wrote:
A shallow catch would effectively need to mean "the exceptions uppermost
traceback frame referers to one of the program lines in the try/except
suite". Which would work well for lists and other builtin types. And
might be insufficient for a duck-type with python-coded d
Cameron Simpson wrote:
try:
foo(bah[5])
except IndexError as e:
... infer that there is no bah[5] ...
One can easily want, instead, some kind of "shallow except", which would
catch exceptions only if they were directly raised from the surface
code;
The problem I see with
Cameron Simpson wrote:
Alas, no. It is existing syntax in Standard ML, not in Python.
But Python doesn't need it, because try-except-else covers
the same thing.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mai
On 23Jun2017 20:30, Stephan Houben wrote:
2017-06-23 17:09 GMT+02:00 Andy Dirnberger :
It's not really a proposal. It's existing syntax.
Wow! I have been using Python since 1.5.2 and I never knew this.
This is not Guido's famous time machine in action, by any chance?
Guess there's some code t
On 23Jun2017 15:59, Paul Moore wrote:
On 23 June 2017 at 15:20, Sven R. Kunze wrote:
On 23.06.2017 03:02, Cameron Simpson wrote:
How about something like this?
try:
val = bah[5]
except IndexError:
# handle your expected exception here
else:
foo(val)
That is the
On 2017-06-23 23:56, Cameron Simpson wrote:
On 24Jun2017 05:02, Steven D'Aprano wrote:
[snip]
I think the concept of a "shallow exception" is ill-defined, and to the
degree that it is defined, it is *dangerous*: a bug magnet waiting to
strike.
What do you mean by "directly raised from the su
On 23Jun2017 11:48, Nick Coghlan wrote:
On 23 June 2017 at 09:29, Cameron Simpson wrote:
This is so common that I actually keep around a special hack:
def prop(func):
''' The builtin @property decorator lets internal AttributeErrors
escape.
While that can support properties t
On 24Jun2017 05:02, Steven D'Aprano wrote:
On Fri, Jun 23, 2017 at 09:29:23AM +1000, Cameron Simpson wrote:
On 23Jun2017 06:55, Steven D'Aprano wrote:
>On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
>>We usually teach our newbies to catch exceptions as narrowly as
>>possible, i
On Fri, Jun 23, 2017 at 09:29:23AM +1000, Cameron Simpson wrote:
> On 23Jun2017 06:55, Steven D'Aprano wrote:
> >On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
> >>We usually teach our newbies to catch exceptions as narrowly as
> >>possible, i.e. MyModel.DoesNotExist instead of a p
2017-06-23 17:09 GMT+02:00 Andy Dirnberger :
> It's not really a proposal. It's existing syntax.
Wow! I have been using Python since 1.5.2 and I never knew this.
This is not Guido's famous time machine in action, by any chance?
Guess there's some code to refactor using this construct now...
St
Hi Stephan,
On Fri, Jun 23, 2017 at 6:23 AM, Stephan Houben
wrote:
> Hi Andy,
>
> What you propose is essentially the "try .. catch .. in" construct as
> described for Standard ML in:
>
It's not really a proposal. It's existing syntax. I was suggesting a way
to implement the example that would
On 23 June 2017 at 15:20, Sven R. Kunze wrote:
> On 23.06.2017 03:02, Cameron Simpson wrote:
>
>
> How about something like this?
>
>try:
>val = bah[5]
>except IndexError:
># handle your expected exception here
>else:
>foo(val)
>
>
> That is the kind of refactor
On 23.06.2017 03:02, Cameron Simpson wrote:
How about something like this?
try:
val = bah[5]
except IndexError:
# handle your expected exception here
else:
foo(val)
That is the kind of refactor to which I alluded in the paragraph
above. Doing that a lot tends
Hi Andy,
What you propose is essentially the "try .. catch .. in" construct as
described for Standard ML in:
https://pdfs.semanticscholar.org/b24a/60f84b296482769bb6752feeb3d93ba6aee8.pdf
Something similar for Clojure is at:
https://github.com/rufoa/try-let
So clearly this is something more peo
On 2017-06-23 00:29, Cameron Simpson wrote:
On 23Jun2017 06:55, Steven D'Aprano wrote:
On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
We usually teach our newbies to catch exceptions as narrowly as
possible, i.e. MyModel.DoesNotExist instead of a plain Exception. This
works out
On 22Jun2017 19:47, Andy Dirnberger wrote:
On Jun 22, 2017, at 7:29 PM, Cameron Simpson wrote:
try:
foo(bah[5])
except IndexError as e:
... infer that there is no bah[5] ...
Of course, it is possible that bah[5] existed and that foo() raised an
IndexError of its own. One might
On 23 June 2017 at 09:29, Cameron Simpson wrote:
> This is so common that I actually keep around a special hack:
>
>def prop(func):
> ''' The builtin @property decorator lets internal AttributeErrors
> escape.
> While that can support properties that appear to exist
> conditional
> On Jun 22, 2017, at 7:29 PM, Cameron Simpson wrote:
>
>> On 23Jun2017 06:55, Steven D'Aprano wrote:
>>> On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
>>> We usually teach our newbies to catch exceptions as narrowly as
>>> possible, i.e. MyModel.DoesNotExist instead of a plai
On 23Jun2017 06:55, Steven D'Aprano wrote:
On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
We usually teach our newbies to catch exceptions as narrowly as
possible, i.e. MyModel.DoesNotExist instead of a plain Exception. This
works out quite well for now but the number of example
On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
> Hi folks,
>
> just one note I'd like to dump here.
>
> We usually teach our newbies to catch exceptions as narrowly as
> possible, i.e. MyModel.DoesNotExist instead of a plain Exception. This
> works out quite well for now but the
41 matches
Mail list logo
