All operations on None should raise a NoneError, which should be a
TypeError for backwards compatibility.
try:
x = a[b][c][d][e][f] + g.foo(h)
except NoneError:
x = None
we can then look into merging the proposals of None-aware operators and
Exception-aware operators such that the Exceptio
On Mon, Mar 02, 2020 at 01:39:39PM -0300, Soni L. wrote:
> we should also look into making "except" default to using NoneError
> instead of BaseException
We would we want to do that?
--
Steven
___
Python-ideas mailing list -- [email protected]
On Tue, Mar 3, 2020 at 3:40 AM Soni L. wrote:
>
> All operations on None should raise a NoneError, which should be a
> TypeError for backwards compatibility.
>
> try:
>x = a[b][c][d][e][f] + g.foo(h)
> except NoneError:
>x = None
>
> we can then look into merging the proposals of None-awar
On 2020-03-02 1:48 p.m., Steven D'Aprano wrote:
On Mon, Mar 02, 2020 at 01:39:39PM -0300, Soni L. wrote:
> we should also look into making "except" default to using NoneError
> instead of BaseException
We would we want to do that?
"explicit is better than implicit" and also for consisten
On Mar 2, 2020, at 08:40, Soni L. wrote:
>
> All operations on None should raise a NoneError,
So every function in every type implemented in C or in Python, whether part of
Python or third-party, that has code like this:
if not isisntance(arg, numbers.Integral):
raise TypeError(f"
On 2020-03-02 2:04 p.m., Andrew Barnert wrote:
On Mar 2, 2020, at 08:40, Soni L. wrote:
>
> All operations on None should raise a NoneError,
So every function in every type implemented in C or in Python, whether part of
Python or third-party, that has code like this:
if not isisntan
For example, In JavaScript, not defined value will return 'undefined'.
This language specification makes language easier to use, but also harder to
debug.
I think to make NoneErorr (or going to be UndefinedError or something) in
languages like JavaScript is nice. Because programmers often don't
This feels a lot like a really verbose way of having nulls-safe operators.
On Mon, Mar 2, 2020, 10:40 AM Soni L. wrote:
> All operations on None should raise a NoneError, which should be a
> TypeError for backwards compatibility.
>
> try:
>x = a[b][c][d][e][f] + g.foo(h)
> except NoneError:
On Mar 2, 2020, at 09:26, Soni L. wrote:
>
>> On 2020-03-02 2:04 p.m., Andrew Barnert wrote:
>> On Mar 2, 2020, at 08:40, Soni L. wrote:
>> > > All operations on None should raise a NoneError,
>>
>> So every function in every type implemented in C or in Python, whether part
>> of Python or th
On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker
wrote:
> That being said, more information is better than less, so maybe an
> unpacking error should show the *value* of what was being unpacked:
>
> >>> a, b = 1, 2, 3
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: t
There was a proposal (by me) some time ago to add some structured
information to some of the Exceptions. See
https://www.python.org/dev/peps/pep-0473/, but it finally got rejected due
to being too broad. I'd be happy to revive (parts of) the proposal if
anyone is interested.
I managed though to cr
On 2020-03-02 4:03 p.m., Andrew Barnert wrote:
On Mar 2, 2020, at 09:26, Soni L. wrote:
On 2020-03-02 2:04 p.m., Andrew Barnert wrote:
On Mar 2, 2020, at 08:40, Soni L. wrote:
> > All operations on None should raise a NoneError,
So every function in every type implemented in C or in Pyth
On Sun, Feb 23, 2020 at 01:46:53PM -0500, Richard Damon wrote:
> I would agree with this. In my mind, fundamentally a 'string' is a
> sequence of characters, not strings,
If people are going to seriously propose this Character type, I think
they need to be more concrete about the proposal and
On Tue, Mar 3, 2020 at 10:13 AM Steven D'Aprano wrote:
>
> On Sun, Feb 23, 2020 at 01:46:53PM -0500, Richard Damon wrote:
>
> > I would agree with this. In my mind, fundamentally a 'string' is a
> > sequence of characters, not strings,
>
> If people are going to seriously propose this Character ty
On Sun, Feb 23, 2020 at 10:17:03PM -, Alex Hall wrote:
> Steven D'Aprano wrote:
> > Conceptually, we should be able to reason that every object that
> > supports indexing should be iterable, without adding a special case
> > exception "...except for str".
>
> Strings already have an excepti
On Mon, Feb 24, 2020 at 01:58:49PM -0800, Bruce Leban wrote:
> Actually quite a bit. I write a lot of code that manipulates words to
> create puzzles. In every one of those I use strings as iterables. For what
> it's worth, in one of these programs, the problem I encountered was that
> strings wer
Not sure I like this idea at all, honestly, but:
Maybe one of the issues we have is that None is used for multiple things in
Python. It’s always some version of “nothing”, but what it specifically
means depends on context.
For instance, it pretty much always means “use default for keyword” when
u
Anyone can define their own singleton easily enough. None is unique because
it's the only built-in general-purpose singleton, and it's too late to
change that.
I have to agree with Andrew here: in a brand new language it might be a
good idea to have a unique exception to be raised for (most) opera
On Mar 2, 2020, at 15:13, Steven D'Aprano wrote:
>
> On Sun, Feb 23, 2020 at 01:46:53PM -0500, Richard Damon wrote:
>
>> I would agree with this. In my mind, fundamentally a 'string' is a
>> sequence of characters, not strings,
>
> If people are going to seriously propose this Character type,
19 matches
Mail list logo
