On 10.02.13 13:37, Steven D'Aprano wrote:
Unfortunately, Python has a minor design flaw. One of the most common
use-cases for sets is for membership testing of literal sets:
def example(arg):
if arg in {'spam', 'ham', 'eggs', 'cheese'}:
...
Unfortunately, set literals
On Tue, Feb 12, 2013 at 10:48 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Monday, February 11, 2013 11:55:19 PM UTC-6, Chris Angelico wrote:
On Tue, Feb 12, 2013 at 12:06 PM, 8 Dihedral wrote:
A permanently mutated list is a tuple of constant objects.
I nominate this line as
On Sat, Feb 16, 2013 at 7:12 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
FYI, the general consensus here is that he (8 Dihedral) is a
bot. It posts in non sequiturs and fails to respond meaningfully to
direct queries. A few months ago I posed an obvious Turing test for
it, which it
On Monday, February 11, 2013 11:55:19 PM UTC-6, Chris Angelico wrote:
On Tue, Feb 12, 2013 at 12:06 PM, 8 Dihedral wrote:
A permanently mutated list is a tuple of constant objects.
I nominate this line as bemusing head-scratcher of the week.
Actually the statement is fact IF you can grok
On Wed, Feb 13, 2013 at 4:48 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
Your confusion may stem from interpreting constant as the CS term
CONSTANT[1]; whereby the objects in the tuple are programming CONSTANTS,
that is, unable to change.
Uhh, yeah. Not being Humpty Dumpty, I
Rick Johnson於 2013年2月13日星期三UTC+8上午1時48分07秒寫道：
On Monday, February 11, 2013 11:55:19 PM UTC-6, Chris Angelico wrote:
On Tue, Feb 12, 2013 at 12:06 PM, 8 Dihedral wrote:
A permanently mutated list is a tuple of constant objects.
I nominate this line as bemusing head-scratcher
On Sunday, February 10, 2013 5:37:46 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
IMO Set Types should only exists as a concequence of freezing an
array,
Sets are not frozen lists.
Indeed. That wording was a bit clumsy on my part.
and should have NO literal syntax available.
On Saturday, February 9, 2013 11:04:42 PM UTC-6, Chris Angelico wrote:
On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson wrote:
Well Chris i have wonderful news for you! Python /does/
have homogenous arrays, and they're called, wait for
it. arrays!
That's not a built-in. But you were
On Mon, Feb 11, 2013 at 11:18 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Sunday, February 10, 2013 5:37:46 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
IMO Set Types should only exists as a concequence of freezing an
array,
Sets are not frozen lists.
Indeed. That
On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Saturday, February 9, 2013 11:04:42 PM UTC-6, Chris Angelico wrote:
On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson wrote:
Well Chris i have wonderful news for you! Python /does/
have homogenous arrays, and
On Monday, February 11, 2013 6:40:23 AM UTC-6, Chris Angelico wrote:
[...]
Or doing what you were pointing and laughing at Pike for, and using
two-symbol delimiters. You could even make it majorly logical:
list_ = [[ 1, 2, 3 ]]
tuple_ = ([ 1, 2, 3 ])
dict_ = [{ 1, 2, 3 }]
frozendict_ = ({
On Monday, February 11, 2013 6:50:03 AM UTC-6, Chris Angelico wrote:
On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
Well i would expect anyone who considers himself a
python programmer (not to mention pythonista!) to at
minimum be familiar with the stdlib. [...]
[...]
If there is
On Tue, Feb 12, 2013 at 12:13 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
I am vehemently against using more than one opening seq char and one
closing seq char. ... we could use start and end tags like:
set{1,2,3}set
where set{ and }set are delimiters.
Interesting. So what
On Tue, Feb 12, 2013 at 12:28 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
I am sure there are quite a few Chris. But if you expect to around making
statements like: Python does not have typed arrays, then don't get all
upset when someone corrects you.
Oh, I don't mind being
Rick Johnson於 2013年2月11日星期一UTC+8下午9時13分58秒寫道：
On Monday, February 11, 2013 6:40:23 AM UTC-6, Chris Angelico wrote:
[...]
Or doing what you were pointing and laughing at Pike for, and using
two-symbol delimiters. You could even make it majorly logical:
list_ = [[ 1, 2, 3 ]]
On Monday, February 11, 2013 7:35:23 AM UTC-6, Chris Angelico wrote:
On Tue, Feb 12, 2013 at 12:13 AM, Rick Johnson wrote:
I am vehemently against using more than one opening seq char and one
closing seq char. ... we could use start and end tags like:
set{1,2,3}set
where set{ and
On Monday, February 11, 2013 7:52:24 AM UTC-6, Chris Angelico wrote:
[...]
But my statement wasn't based on my own knowledge of the stdlib, but
rather on this:
On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson wrote:
I'm a bit unnerved by the sum function. Summing a
sequence only makes sense
On Fri, Feb 8, 2013 at 9:48 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
Just because /everything/ in Python is an object does not mean that Python is
100% OOP.
The whole idea of make everything
On Tue, Feb 12, 2013 at 12:06 PM, 8 Dihedral
dihedral88...@googlemail.com wrote:
A permanently mutated list is a tuple of constant objects.
I nominate this line as bemusing head-scratcher of the week.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Rick Johnson wrote:
IMO Set Types should only exists as a concequence of freezing an
array,
Sets are not frozen lists.
and should have NO literal syntax avaiable.
Unfortunately, Python has a minor design flaw. One of the most common
use-cases for sets is for membership testing of literal
In article 5117868b$0$29998$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Sets are not frozen lists.
Right. Tuples are frozen lists (ducking and running).
--
http://mail.python.org/mailman/listinfo/python-list
Am 10.02.2013 12:37 schrieb Steven D'Aprano:
So, in Python 4000, my vote is for set literals { } to create frozensets,
and if you want a mutable set, you have to use the set() type directly.
4000 sounds about long future.
In the meanwhile, a new syntax element could be introduced fpr
On Saturday, February 9, 2013 10:50:25 PM UTC-6, Chris Angelico wrote:
[...]
I don't understand. Wouldn't freezing an array (list) result in a
tuple? And, why should there be no literal syntax for them?
Having a convenient literal notation for every basic type is extremely
handy.
Actually
On Feb 8, 4:29 pm, Rick Johnson rantingrickjohn...@gmail.com wrote:
That's a strange thing to say when you go on to provide an example that tests
the validity of the object each and every time:
Here's a tip: context is important. I was referring to not having to
*explicitly* test if a label
On Friday, February 8, 2013 11:01:00 PM UTC-6, Chris Angelico wrote:
[...]
Another advantage of using two characters: There's no conflict between
set and dict literals. How do you notate an empty set in Python? {}
means an empty dict.
What makes you believe that a language must provide
On Sun, Feb 10, 2013 at 3:26 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, February 8, 2013 11:01:00 PM UTC-6, Chris Angelico wrote:
[...]
Another advantage of using two characters: There's no conflict between
set and dict literals. How do you notate an empty set in Python?
On Friday, February 8, 2013 7:17:26 PM UTC-6, Chris Angelico wrote:
On Sat, Feb 9, 2013 at 11:49 AM, Rick Johnson
nested_list = array(array(string))
Actually, that's not a declaration, that's an assignment; and in Pike,
a 'type' is a thing, same as it is in Python (though not quite). If I
On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
Well Chris i have wonderful news for you! Python /does/ have homogenous
arrays, and they're called, wait for it. arrays! Imagine that!
That's not a built-in. But you were the one who complained about the
On Friday, February 8, 2013 7:06:34 PM UTC-6, Ian wrote:
On Fri, Feb 8, 2013 at 12:58 PM, Rick Johnson
wrote:
I'm a bit unnerved by the sum function. Summing a
sequence only makes sense if the sequence in question
contains /only/ numeric types. For that reason i decided
to create a
On 08/02/2013 06:15, Chris Angelico wrote:
On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
And which Univeristy would you recommend for studying the intricacies of
gobbledygook? ;-)
Dunno, where'd you get your degree in logic?
From the University of
Am 08.02.2013 07:29 schrieb Rick Johnson:
Consider this:
if connect(my:db) as db:
do something
No need to make a call and then test for the validity of the call when you can
do both simultaneously AND intuitively.
Would be great, but can be emulated with
def ifiter(x):
Rick Johnson wrote:
On Monday, July 16, 2012 7:43:47 PM UTC-5, Steven D'Aprano wrote:
Really Rick? Digging out a post from nearly seven months ago? You must
really be bored silly.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Rick Johnson wrote:
GvR has always been reluctant to incorporate full OOP machinery for some
reason.
Python is a fully object oriented language. It is *more* object oriented
than, say, Java.
- everything in Python is an object, there is no distinction between boxed
and unboxed variables;
-
On 2013-02-08 07:22, Steven D'Aprano wrote:
Rick Johnson wrote:
Why even have a damn bool function if you're never going to use it?
bool is for converting arbitrary objects into a canonical True or False
flag. E.g. one use-case is if you wish to record in permanent storage a
flag, and don't
On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
GvR has always been reluctant to incorporate full OOP machinery for some
reason.
Python is a fully object oriented language. It is *more* object oriented
than, say, Java.
Oh really? *chuckles*
-
In article ee71b775-b527-4bb3-a080-12aad962b...@googlegroups.com,
Rick Johnson rantingrickjohn...@gmail.com wrote:
The best way to describe Python is as promiscuous language who secretly
longs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP
lingerie on the weekends.
On Friday, February 8, 2013 11:48:43 AM UTC-6, Rick Johnson wrote:
[...]
So using a /real/ OOP paridigm we would do the following:
## START TRUE OOP PARIDIGM ##
[...snip naive example...]
Actually my example API is littered with artifacts of a python global function
architecture. In
MRAB wrote:
On 2013-02-08 07:22, Steven D'Aprano wrote:
Prior to Python 3, the special method __bool__ was spelled __nonempty__,
which demonstrates Python's philosophy towards duck-typing bools.
Incorrect, it was spelled __nonzero__.
Oops, so it was. Sorry for the brain-fart.
__nonzero__
On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
I'm a bit unnerved by the sum function. Summing a sequence only makes sense
if the sequence in question contains /only/ numeric types. For that reason i
decided to create a special type for holding Numerics. This
On Friday, February 8, 2013 6:05:54 PM UTC-6, Chris Angelico wrote:
The sum builtin works happily on any sequence of objects
that can be added together. It works as an excellent
flatten() method:
nested_list = [[q], [w,e], [r,t,u], [i,o,p]]
sum(nested_list,[])
['q', 'w', 'e', 'r', 't',
On Fri, Feb 8, 2013 at 12:58 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
I'm a bit unnerved by the sum function. Summing a sequence only makes sense
if the sequence in question contains /only/ numeric types. For that reason i
decided to create a special type for holding Numerics.
On Sat, Feb 9, 2013 at 11:49 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, February 8, 2013 6:05:54 PM UTC-6, Chris Angelico wrote:
The sum builtin works happily on any sequence of objects
that can be added together. It works as an excellent
flatten() method:
nested_list =
On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, February 8, 2013 6:05:54 PM UTC-6, Chris Angelico wrote:
The sum builtin works happily on any sequence of objects
that can be added together. It works as an excellent
flatten() method:
nested_list =
Rick Johnson wrote:
On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote:
Rick Johnson wrote:
GvR has always been reluctant to incorporate full OOP machinery for
some reason.
Python is a fully object oriented language. It is *more* object oriented
than, say, Java.
Oh
On Sat, Feb 9, 2013 at 12:29 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
What the hell? Oh yeah, you must be using pike again. No, if it were pike
the list would look like this:
({({q}), ({w,e}), ({r,t,u}),
On Monday, July 16, 2012 7:43:47 PM UTC-5, Steven D'Aprano wrote:
[...]
If I insist on making a single object do duty for both the jar and the
jellybean count, then I need a null jar object, and I probably end up
with something like this:
Jar(number_of_beans=None) = null jar object
On Monday, July 16, 2012 8:45:51 PM UTC-5, rusi wrote:
On Jul 15, 9:50 pm, Rick Johnson rantingrickjohn...@gmail.com wrote:
I think this issue is not so much a bool test vs type
test, but more an ambiguous syntax issue.
If you know some English, its clear that if and while
create bool
On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
And which Univeristy would you recommend for studying the intricacies of
gobbledygook? ;-)
Dunno, where'd you get your degree in logic?
*dives for cover*
ChrisA
--
On Monday, July 16, 2012 11:18:28 PM UTC-5, Devin Jeanpierre wrote:
On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano wrote:
On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
For example, instead of if stack: or if bool(stack):, we could use
if stack.isempty():. This line tells
On Tuesday, July 17, 2012 8:35:09 PM UTC-5, alex23 wrote:
On Jul 17, 6:23 pm, Andrew Berg bahamutzero8...@gmail.com wrote:
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as
On 02/07/2013 11:16 PM, Rick Johnson wrote:
He is so accustomed to guessing that it has become second nature
for him.
I think most of us are guessing as to what you're talking about since
you're responding to a 7 month old thread that I think most people have
long since deleted from their
On Tuesday, July 17, 2012 8:35:09 PM UTC-5, alex23 wrote:
On Jul 17, 6:23 pm, Andrew Berg bahamutzero8...@gmail.com wrote:
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as
On Friday, February 8, 2013 12:27:09 AM UTC-6, Michael Torrie wrote:
On 02/07/2013 11:16 PM, Rick Johnson wrote:
He is so accustomed to guessing that it has become second nature
for him.
I think most of us are guessing as to what you're talking about since
you're responding to a 7 month
Rick Johnson wrote:
Why even have a damn bool function if you're never going to use it?
bool is for converting arbitrary objects into a canonical True or False
flag. E.g. one use-case is if you wish to record in permanent storage a
flag, and don't want arbitrary (possibly expensive) objects to
On Mon, 16 Jul 2012 11:13:33 -0700, Ethan Furman wrote:
Steven D'Aprano wrote:
On Sun, 15 Jul 2012 10:19:16 -0600, Ian Kelly wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly*
On Tue, 17 Jul 2012 00:18:28 -0400, Devin Jeanpierre wrote:
On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
For example, instead of if stack: or if bool(stack):, we could use
if
On Tue, 17 Jul 2012 00:19:48 -0500, Andrew Berg wrote:
To put it in duck-typing terms, why should everything have to quack like
True or False? Sure, I can see why 1 quacks like True or [] quacks like
False, but I don't see why say, a Logger or function should quack like
either.
The default
On 7/15/2012 1:34 AM, Andrew Berg wrote:
This has probably been discussed before, but why is there an implicit
conversion to a boolean in if and while statements?
if not None:
print('hi')
prints 'hi' since bool(None) is False.
If this was discussed in a PEP, I would like a link to it.
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as false-like. Since both loggers
and functions are objects, they are true-like unless the default is
overridden.
I am aware of the
On Tue, Jul 17, 2012 at 6:23 PM, Andrew Berg bahamutzero8...@gmail.com wrote:
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as false-like. Since both loggers
and functions are
On Tue, Jul 17, 2012 at 2:25 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
It already is part of the collection interface: it is spelled __nonzero__
(Python 2) or __bool__ (Python 3), and like all dunder methods, it is
called automatically for you when you use the right
Andrew Berg wrote:
To put it in duck-typing terms, why should everything have to quack like
True or False? Sure, I can see why 1 quacks like True or [] quacks like
False, but I don't see why say, a Logger or function should quack like
either. Should a Thread object be True if it's been started
On 2012-07-17 10:23, Andrew Berg wrote:
I don't want that, but I am suggesting that it would be consistent with
the idea of something or nothing.
Don't confuse names and objects. You can only test the truth value of
objects. If you don't have a name in a namespace, then it means you
don't have
Not really. It doesn't quack like anything.
Actually, there is no it. So we cannot talk about how it quacks. :-D
--
http://mail.python.org/mailman/listinfo/python-list
On 7/17/2012 4:23 AM, Andrew Berg wrote:
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as false-like. Since both loggers
and functions are objects, they are true-like unless the
On Jul 17, 6:23 pm, Andrew Berg bahamutzero8...@gmail.com wrote:
On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
The default behaviour is that every object is something, hence true-like,
unless explicitly coded to be treated as false-like. Since both loggers
and functions are objects, they are
On Mon, Jul 16, 2012 at 2:53 PM, Ranting Rick
rantingrickjohn...@gmail.com wrote:
if obj is in essence doing if bool(obj) behind the scenes. My
question is: Why hide such valuable information from the reader? It's
obvious that if bool(obj) will return a boolean; whereas if obj is
ambiguous.
On Mon, Jul 16, 2012 at 3:03 PM, Ranting Rick
rantingrickjohn...@gmail.com wrote:
But if you are going to argue that if obj is *explicit enough*, then
apply your argument consistently to String+1.75 also. Why must we be
explicit about string conversion BUT not boolean conversion? Can you
On 16/07/2012 04:05, Chris Angelico wrote:
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
And that, the reason given in the sentence above, is the reason that we,
collectively all programmers, should prefer to be explicit, not merely
conveying
On Jul 16, 2:53 pm, Ranting Rick rantingrickjohn...@gmail.com wrote:
if obj is in essence doing if bool(obj) behind the scenes. My
question is: Why hide such valuable information from the reader?
If @decorator is in essence doing function = decorator(function)
behind the scenes, why hide that?
On Jul 16, 3:03 pm, Ranting Rick rantingrickjohn...@gmail.com wrote:
But if you are going to argue that if obj is *explicit enough*, then
apply your argument consistently to String+1.75 also. Why must we be
explicit about string conversion BUT not boolean conversion?
What _other_ than booleans
On Sun, 15 Jul 2012 22:03:52 -0700, Ranting Rick wrote:
But if you are going to argue that if obj is *explicit enough*, then
apply your argument consistently to String+1.75 also. Why must we be
explicit about string conversion BUT not boolean conversion?
The problem with String + 1.75 is not
On Sun, 15 Jul 2012 19:41:34 -0700, Ranting Rick wrote:
Short circuitry is a powerful tool! But why the heck would your
sequences ever be None? Are you using None as a default? And if so, why
not use an empty sequence instead ([], {}, )?
Mostly for explicitness. I want to be able to say that
On 15.07.12 19:50, Rick Johnson wrote:
We must NEVER present if in such confusing manner as ExampleA.
## EXAMPLE C ##
py if bool(money) == True:
... do_something()
--
http://mail.python.org/mailman/listinfo/python-list
In article b2971c4d-0769-4d03-a7b6-c527629a8...@x39g2000yqx.googlegroups.com,
Ranting Rick rantingrickjohn...@gmail.com wrote:
We DON'T want Python to silently convert cost to a string. What we
DO want is to force the author to use the str function thereby making
the conversion explicit.
We do
In article 50038364$0$29995$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 15 Jul 2012 18:21:06 -0700, Ranting Rick wrote:
If HOWEVER we want to truth test an object (as in: if obj) we should
be FORCED to use the bool! Why? Because
Steven D'Aprano wrote:
On Sun, 15 Jul 2012 10:19:16 -0600, Ian Kelly wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't think of any
On 7/15/2012 9:38 PM, Steven D'Aprano wrote:
I would expect None to mean doesn't exist or unknown or
something like that - e.g., a value of 0 means 0 jelly beans in the jar
and None means there isn't a jar.
How you interpret some_variable = None depends on what some_variable
represents. If
Andrew Berg wrote:
On 7/15/2012 9:38 PM, Steven D'Aprano wrote:
I would expect None to mean doesn't exist or unknown or
something like that - e.g., a value of 0 means 0 jelly beans in the jar
and None means there isn't a jar.
How you interpret some_variable = None depends on what
...
Traceback (most recent quip last):
Author: DeAprano, line 7, in post
LogicalFallacyError: Reductio ad absurdum
Deary deary me Rick. Reductio ad adsurdum is not a fallacy. It is a
counter-argument to an argument or claim, by showing that the premise of
the original claim leads to an
This syntax is explicit *enough*. We don't need to be any more
explicit.
But if you are going to argue that if obj is *explicit enough*, then
apply your argument consistently to String+1.75 also. Why must we be
explicit about string conversion BUT not boolean conversion? Can you
reduce this to
On Mon, 16 Jul 2012 13:54:32 -0700, Ethan Furman wrote:
Andrew Berg wrote:
On 7/15/2012 9:38 PM, Steven D'Aprano wrote:
I would expect None to mean doesn't exist or unknown or something
like that - e.g., a value of 0 means 0 jelly beans in the jar and
None means there isn't a jar.
How
On Tue, 17 Jul 2012 01:12:47 +, Steven D'Aprano wrote:
It
looks like Firebird implements the variety of ternary logical called
Keene logic.
Oops, I meant Kleene.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 16 Jul 2012 13:28:14 -0400, Dennis Lee Bieber wrote:
On 16 Jul 2012 02:38:35 GMT, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info declaimed the following in
gmane.comp.python.general:
On Sun, 15 Jul 2012 12:02:37 -0500, Andrew Berg wrote:
Okay, I see the value in this,
On 7/15/2012 3:28 PM, Terry Reedy wrote:
Because everything does (or should).
I can see how truth testing for empty values is convenient, but perhaps
objects should only have a truth value if explicitly given one -
particularly in cases where such a value wouldn't be obvious or the
obvious value
On Jul 15, 9:50 pm, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Sunday, July 15, 2012 11:19:16 AM UTC-5, Ian wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(For the record, I can only think of one trap for the unwary: time
On 7/16/2012 7:43 PM, Steven D'Aprano wrote:
The existence of a jar or no jar is irrelevant to the question of how
many jellybeans there are. They are two different things, and therefore
need two different values. There are many ways to implement this.
I have a better real example, but I
On Tue, Jul 17, 2012 at 11:57 AM, Andrew Berg bahamutzero8...@gmail.com wrote:
I could do:
if has_message:
send('{command} {args} :{message}')
else:
send('{command} {args}')
but then I'd have to make sure has_message stays accurate since message
won't necessarily be. Or
On Mon, 16 Jul 2012 20:22:18 -0500, Andrew Berg wrote:
On 7/15/2012 3:28 PM, Terry Reedy wrote:
Because everything does (or should).
I can see how truth testing for empty values is convenient, but perhaps
objects should only have a truth value if explicitly given one -
particularly in cases
On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
For example, instead of if stack: or if bool(stack):, we could use
if stack.isempty():. This line tells us explicitly that stack is a
On Tue, Jul 17, 2012 at 2:18 PM, Ranting Rick
rantingrickjohn...@gmail.com wrote:
On Jul 16, 11:11 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
I imagine though that the Python dev's answer will basically be #2: it
isn't a container, it just behaves a little bit like a
On Mon, 16 Jul 2012 20:57:43 -0500, Andrew Berg wrote:
I have a better real example, but I opted not to use it before since it
requires some explanation - IRC messages. A client-to-server message has
the basic form of b'COMMAND arguments :message' (e.g. b'PRIVMSG #channel
:hi guys!'). Some
On 7/16/2012 11:11 PM, Steven D'Aprano wrote:
If you are right that SimpleNamespace should be treated as a container,
then it should implement container semantics. Since it doesn't, that is
either:
1) a bug; or
2) a triumph of laziness over correctness
I imagine though that the Python
On 7/16/2012 11:39 PM, Steven D'Aprano wrote:
If you need three (or four, or fifty)
distinguishable states, then obviously boolean context will not solve
your problem. I never said it would.
That is the impression I got from this statement:
How you interpret some_variable = None depends on
On Sun, Jul 15, 2012 at 6:34 PM, Andrew Berg bahamutzero8...@gmail.com wrote:
Converting 0 and 1 to False and True seems reasonable, but I don't see
the point in converting other arbitrary values.
It's for convenience. Unfortunately, not all languages treat all types
the same way. It's very
Andrew Berg, 15.07.2012 10:34:
This has probably been discussed before, but why is there an implicit
conversion to a boolean in if and while statements?
There isn't. This has nothing to do with if or while.
All objects have a truth value in Python, evaluating to True by default
(object),
On Sun, 15 Jul 2012 03:34:46 -0500, Andrew Berg wrote:
This has probably been discussed before,
By the hoary hosts of Hoggoth, has it ever!
but why is there an implicit
conversion to a boolean in if and while statements?
It's nothing to do with if and while. All Python objects are
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't think of any scenario where I would
ever want the semantics
On Sunday, July 15, 2012 11:19:16 AM UTC-5, Ian wrote:
On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(For the record, I can only think of one trap for the unwary: time
objects are false at *exactly* midnight.)
Ugh, that's irritating. I can't
On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
3) Rather than distinguishing true from false, a more useful
dichotomy is between something and nothing. Python includes a number
of ways of spelling nothing of various types, such as:
None, 0, 0.0, '', [], {}, set()
and nearly everything
1 - 100 of 122 matches
Mail list logo
