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,
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)
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
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
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
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
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 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
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
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:
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
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:
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
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
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
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
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
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 --
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
19 matches
Mail list logo
