Terry Reedy wrote:
> On 7/30/2011 12:39 PM, bruno.desthuilli...@gmail.com wrote:
>> On 28 juil, 17:39, Ethan Furman wrote:
>>>
>>> --> bool(0) is bool(0)
>>> True
>
>> This test is not reliable
>
> It is in the sense that it will always work -- because False/True are
> doubletone constants and
On 7/30/2011 12:39 PM, bruno.desthuilli...@gmail.com wrote:
On 28 juil, 17:39, Ethan Furman wrote:
--> bool(0) is bool(0)
True
This test is not reliable
It is in the sense that it will always work -- because False/True are
doubletone constants and so documented.
But expr is expr == Tr
On 28 juil, 17:39, Ethan Furman wrote:
>
> --> bool(0) is bool(0)
> True
>
This test is not reliable - a same id can be reused for terms (I have
already seen such things happening). If you want a reliable test, use:
#> a = bool(0)
#> b = bool(0)
#> a is b
True
Note that this still fails to prov
Hi Terry,
> Ethan's proposal was accepted on python-ideas. In Python 3.3, the classes for
> the singletons None, Ellipsis, and NotImplemented will be callables that
> return the singleton.
Thanks for sharing this news. Its motivating to see this type of
feedback loop because it encourages other
Ethan's proposal was accepted on python-ideas. In Python 3.3, the
classes for the singletons None, Ellipsis, and NotImplemented will be
callables that return the singleton.
It turns out that the reason an exception is now raised is that there
currently is no .__new__ method, so an exception is
Steven D'Aprano wrote:
As for True and False, bool has to be able to return them, because the whole
purpose of exposing bool is so people can call it: if bool(some_value) was
an error, that would defeat the purpose of having bool!
Bool is different, because it doubles as a function for
coercin
On 7/28/2011 5:03 PM, Ethan Furman wrote:
I'm glad you asked! I'm using dictionaries to describe fields and
what their return values should be. There happen to be two special
cases: empty and Null. So a portion of the dictionary looks like:
fielddef = { 'empty':some_func, 'null':some_func }
De
Chris Angelico wrote:
> On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote:
>> I'll use a lambda to get around it, but that's not very elegant. Why
>> shouldn't NoneType be able to return the singleton None?
>
> Why a lambda?
>
> def ThisFunctionWillReturnNone():
> pass
This is a good us
Ian Kelly wrote:
> Why would you ever need to instantiate NoneType?
Well, you probably wouldn't deliberately, but if you have code like this:
types = [type(x) for x in list_of_objects]
# later on...
for t in types:
instance = t()
do_something_with(instance)
it would be nice if it did
Ethan Furman wrote:
> Why is NoneType unable to produce a None instance? I realise that None
> is a singleton, but so are True and False, and bool is able to handle
> returning them:
I've asked this question myself. As I recall the answer, it's just a matter
of personal preference. Some people c
Ethan Furman writes:
> Ben Finney wrote:
> > Ethan Furman writes:
> >> This feels like a violation of 'Special cases aren't special enough
> >> to break the rules.'
> >
> > In the case of ‘bool’, the rule was broken before being introduced.
>
> I think we disagree on what the rule is. I see it
Ben Finney wrote:
Ethan Furman writes:
Why is NoneType unable to produce a None instance? I realise that None
is a singleton
That answers your question. Because None is a singleton, the job of its
type is to make sure there are no other instances.
Which it can do quite easily by returning
Chris Angelico wrote:
On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote:
I'll use a lambda to get around it, but that's not very elegant. Why
shouldn't NoneType be able to return the singleton None?
Why a lambda?
def ThisFunctionWillReturnNone():
pass
Although, since the returning of
Ethan Furman writes:
> Why is NoneType unable to produce a None instance? I realise that None
> is a singleton
That answers your question. Because None is a singleton, the job of its
type is to make sure there are no other instances.
> but so are True and False, and bool is able to handle retur
On Fri, Jul 29, 2011 at 7:03 AM, Ethan Furman wrote:
> I'll use a lambda to get around it, but that's not very elegant. Why
> shouldn't NoneType be able to return the singleton None?
Why a lambda?
def ThisFunctionWillReturnNone():
pass
Although, since the returning of None is crucial to it
Ian Kelly wrote:
On Thu, Jul 28, 2011 at 9:39 AM, Ethan Furman wrote:
Why is NoneType unable to produce a None instance? I realise that None is a
singleton, but so are True and False, and bool is able to handle returning
them:
The bool constructor works (actually just returns one of the exis
On Thu, Jul 28, 2011 at 9:39 AM, Ethan Furman wrote:
> Why is NoneType unable to produce a None instance? I realise that None is a
> singleton, but so are True and False, and bool is able to handle returning
> them:
The bool constructor works (actually just returns one of the existing
singletons
On 07/28/2011 11:39 AM, Ethan Furman wrote:
Traceback (most recent call last):
File "", line 3, in
TypeError: cannot create 'NoneType' instances
Why is NoneType unable to produce a None instance? I realise that None
is a singleton, but so are True and False, and bool is able to handle
returnin
Consider:
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
--> for ins in ({0:'0'}, (1,), set([2, 3]), [4, 5], 6, 'seven',
... 8.0, True, None):
... print(type(ins))
... type(ins)()
...
19 matches
Mail list logo
