On Sat, Feb 16, 2013 at 7:12 AM, Ian Kelly 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 failed.
>
> http://thr
On Tue, Feb 12, 2013 at 10:48 AM, Rick Johnson
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 "bemusing head-scra
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 literal
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 he
On Wed, Feb 13, 2013 at 4:48 AM, Rick Johnson
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 interpret "constants" to mea
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 ca
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".
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Feb 8, 2013 at 9:48 AM, Rick Johnson
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 an object" is possibly
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 make
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
> >
> >
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_ = [
On Tue, Feb 12, 2013 at 12:28 AM, Rick Johnson
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 corrected on those sorts of poin
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 "}set" are delimiters.
Interesting. So what you're actually agai
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 t
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 }]
> frozendic
On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
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 they're called, wai
On Mon, Feb 11, 2013 at 11:18 PM, Rick Johnson
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 wording was a
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
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 a
On Feb 8, 4:29 pm, Rick Johnson 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 *is defined* in order to be
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.
Act
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
frozens
In article <5117868b$0$29998$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> Sets are not frozen lists.
Right. Tuples are frozen lists (ducking and running).
--
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 lit
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 crea
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! Imagine that!
That's not a built-in. But you were the one who complained about the
way sum() could be applie
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).
On Sun, Feb 10, 2013 at 3:26 PM, Rick Johnson
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? {}
>> means an empty di
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 lit
On Sat, Feb 9, 2013 at 12:29 PM, Ian Kelly wrote:
> On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
> 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"}), ({"i","o","p"})})
>>
>> Folks, i
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, sa
On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
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 = [["q"], ["w","e
On Sat, Feb 9, 2013 at 11:49 AM, Rick Johnson
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 = [["q"], ["w","
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 special type for holding Numerics. This will probably
> result
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,[])
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
> if the sequence in question contains /only/ numeric types. For that reason i
> decided to create a special type for holding Numerics. This will probably
> result i
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.
__non
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
architect
In article ,
Rick Johnson 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.
+1 QOTD :-)
--
http://mail.python.org/mailman/listinfo/python-list
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
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 w
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;
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
Am 08.02.2013 07:29 schrieb Rick Johnson:
Consider this:
if connect("my:db") as db:
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):
if x: yield
On 08/02/2013 06:15, Chris Angelico wrote:
On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
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 Wallamaloo whilst in charge of the
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 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
On Tuesday, July 17, 2012 8:35:09 PM UTC-5, alex23 wrote:
> On Jul 17, 6:23 pm, 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
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 e-
On Tuesday, July 17, 2012 8:35:09 PM UTC-5, alex23 wrote:
> On Jul 17, 6:23 pm, 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. Si
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():".
On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
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
--
http://mail.python.org/mailman/listinfo/python-list
On Monday, July 16, 2012 8:45:51 PM UTC-5, rusi wrote:
> On Jul 15, 9:50 pm, Rick Johnson 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 contexts.
Wr
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 ja
On Jul 17, 6:23 pm, 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 t
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 default
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 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 hav
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 an
On Tue, Jul 17, 2012 at 2:25 AM, Steven D'Aprano
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 syntax:
You're still ignoring what I ac
On Tue, Jul 17, 2012 at 6:23 PM, 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-lik
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 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. T
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 defaul
On Tue, 17 Jul 2012 00:18:28 -0400, 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 lin
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 *ex
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 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
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 Tue, Jul 17, 2012 at 2:18 PM, Ranting Rick
wrote:
> On Jul 16, 11:11 pm, Steven D'Aprano +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 container, except
>> when it d
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 us explicitly that stack is a
>> container.
>
> isempty is no
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 c
On Tue, Jul 17, 2012 at 11:57 AM, Andrew Berg 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 maybe I could leave
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 op
On Jul 15, 9:50 pm, Rick Johnson 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
> > wrote:
> > > (For the record, I can only think of one trap for the unwary: time
> > > objects are false at *exactly* midnight.)
>
> > Ugh, that
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 Mon, 16 Jul 2012 13:28:14 -0400, Dennis Lee Bieber wrote:
> On 16 Jul 2012 02:38:35 GMT, Steven D'Aprano
> 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, but I don't understand why
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: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
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
...
Traceback (most recent quip last):
Author: "", line 7, in
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 absurd conc
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 some_va
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
> re
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 sce
In article <50038364$0$29995$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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 explicit is better than implic
In article ,
Ranting Rick 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 want Python to silently convert "cost" to a string in the
proper context.
cost= 3.75
pri
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
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
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
On Jul 16, 3:03 pm, 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?
What _other_ than booleans can you expect a cond
On Jul 16, 2:53 pm, Ranting Rick 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?
If classes are just s
On 16/07/2012 04:05, Chris Angelico wrote:
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano
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 meaning by implication about everything w
On Mon, Jul 16, 2012 at 3:03 PM, 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? Can you
> reduce this to the absurd?
On Mon, Jul 16, 2012 at 2:53 PM, Ranting Rick
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.
Proves nothing. At
On Jul 15, 11:20 pm, Steven D'Aprano wrote:
> (It's not like explicit and implicit are distinct -- everything depends
> on something implicit, if only the meaning of the words you use to
> describe it.)
>
> It certainly doesn't mean that the semantics of Python the language must
> be written out
On Jul 15, 11:03 pm, Steven D'Aprano wrote:
> On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> It boggles my mind that people who are perfectly happy to program to an
> interface or protocol when it comes to (say) iterables, numbers or even
> big complex classes with dozens of method
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
> container.
isempty is not a container method.
py> container = []
py> container.isempty()
On Jul 15, 9:58 pm, Steven D'Aprano 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 explicit is better than implicit
>
> And this is why Rick always writes code
On Mon, Jul 16, 2012 at 12:58 PM, Steven D'Aprano
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 meaning by implication about everything we, collectively all
> programmers, write
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 explicit is better than implicit
And this is why Rick always writes code like:
integer_value_three = int(1) + int(2)
assert
1 - 100 of 123 matches
Mail list logo
