Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38413 > unrolled thread

Re: Implicit conversion to boolean in if and while statements

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:16 -0800
    Re: Implicit conversion to boolean in if and while statements Michael Torrie <torriem@gmail.com> - 2013-02-07 23:27 -0700
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:32 -0800
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:32 -0800
    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 02:16 +1100
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 09:48 -0800
        Re: Implicit conversion to boolean in if and while statements Roy Smith <roy@panix.com> - 2013-02-08 12:58 -0500
        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 11:58 -0800
          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 11:05 +1100
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 16:49 -0800
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 12:17 +1100
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:54 -0800
                  Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-10 16:04 +1100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:28 -0800
                      Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-11 23:50 +1100
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:28 -0800
                          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:52 +1100
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:24 -0800
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:24 -0800
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:28 -0800
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:28 -0800
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:54 -0800
              Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-08 18:29 -0700
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 16:01 +1100
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:26 -0800
                  Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-10 15:50 +1100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 18:09 -0800
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 18:09 -0800
                  Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:37 +1100
                    Re: Implicit conversion to boolean in if and while statements Roy Smith <roy@panix.com> - 2013-02-10 09:45 -0500
                    Re: Implicit conversion to boolean in if and while statements Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2013-02-10 18:06 +0100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:18 -0800
                      Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-11 23:40 +1100
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:13 -0800
                          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:35 +1100
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:00 -0800
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:00 -0800
                          Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-11 17:06 -0800
                            Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 16:55 +1100
                              Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 09:48 -0800
                                Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-13 08:24 +1100
                                Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-12 18:43 -0800
                                Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-12 18:43 -0800
                                Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-15 13:12 -0700
                                Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-16 11:12 +1100
                              Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 09:48 -0800
                          Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-11 17:06 -0800
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:13 -0800
                    Re: Implicit conversion to boolean in if and while statements Serhiy Storchaka <storchaka@gmail.com> - 2013-02-15 21:09 +0200
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:26 -0800
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 16:49 -0800
          Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-08 18:06 -0700
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 22:25 -0800
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 22:25 -0800
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 14:16 +1100
          Re: Implicit conversion to boolean in if and while statements Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-09 15:36 -0500
        Re: Implicit conversion to boolean in if and while statements Mark Janssen <dreamingforward@gmail.com> - 2013-02-11 21:12 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#38670

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 the one who complained about the
> way sum() could be applied to a list that contains a non-integer;
> maybe your solution is simply to ignore sum() and work with
> array.array?

Yes i could, however by doing so i would be ignoring the inconsistent elephant in the room. My crusade is to bring consistency and logic to languages, and if i have any free time afterwards, to remove multiplicity. There are two types of people in the world Chris, those that lead and those that follow. 

> Nice how you can complain about Python for not having something, then
> heap scorn on me for not being aware that it's there in the stdlib.
> (Which, by the way, I freely admit to being less than fully familiar
> with. Even less familiar with what's on PyPI.)

Well i would expect anyone who considers himself a python programmer (not to mention "pythonista"!) to at minimum be familiar with the stdlib. That does not mean he must have attained black belt level kung-fu in /every/ stdlib module, but he must at least /know/ all the modules names and all types that Python offers. Is that really too much to ask Chris?

[toc] | [prev] | [next] | [standalone]

#38555

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
> were to declare it in Pike, it would be:
> 
> array(array(string)) nested_list;
> 
> Though the part inside the parens can be omitted, in which case the
> array can contain anything, rather than being restricted to strings.
> In actual fact, Rick, despite your complaints about the syntax, it's
> able to achieve exactly what you were thinking Python should do:
> declare an array/list that contains only numbers.

Well Chris i have wonderful news for you! Python /does/ have "homogenous arrays", and they're called, wait for it......... arrays! Imagine that!

py> import array
py> intSeq = array.array('i')
py> intSeq.append(1)
py> intSeq.append(2)
py> intSeq.append(5000)
py> intSeq.append(5000.333)
TypeError: integer argument expected, got float
py> intSeq.append('5000.333')
TypeError: an integer is required

[toc] | [prev] | [next] | [standalone]

#38488

On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
<rantingrickjohnson@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 = [["q"], ["w","e"], ["r","t","u"], ["i","o","p"]]
>> >>> sum(nested_list,[])
>> ['q', 'w', 'e', 'r', 't', 'u', 'i', 'o', 'p']
>> >>> nested_list
>> [['q'], ['w', 'e'], ['r', 't', 'u'], ['i', 'o', 'p']]
>
> 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"})})
>
> Of course you'd have to declare it first using an /expanded/ Java syntax:
>
>  nested_list = array(array(string))
>
> Folks, i couldn't make this stuff up if i wanted to. Go read for yourself if want a few laughs.

Classic ad hominem.  Try to make your opponent look bad by making fun
of them on a completely unrelated topic, and then hope that nobody
notices that you entirely ignored the substance of their argument.
Sorry, it didn't work.

You didn't even do a good job of it.  Yes, Pike uses two characters
instead of one to wrap array literals.  Big friggin' whoop.  On the
minus side, it's a little more typing.  On the plus side, they stand
out better, and you don't have the [] characters doing double duty
denoting list literals and indexing alike.  Yes, Pike writes **string
as the more readable array(array(string)) -- although if my memory
serves correctly the former is also legal syntax.  Again, nobody
cares.  And by the by, Pike is a descendant of C, not Java.  Its
predecessor LPC predates Java by about 6 years.  If you're going to
start lambasting others' preferred programming languages in an effort
to make yourself look good, you can at least get your facts straight.

[toc] | [prev] | [next] | [standalone]

#38498

On Sat, Feb 9, 2013 at 12:29 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Feb 8, 2013 at 5:49 PM, Rick Johnson
> <rantingrickjohnson@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"}), ({"i","o","p"})})
>>
>> Folks, i couldn't make this stuff up if i wanted to. Go read for yourself if want a few laughs.
>
> You didn't even do a good job of it.  Yes, Pike uses two characters
> instead of one to wrap array literals.  Big friggin' whoop.  On the
> minus side, it's a little more typing.  On the plus side, they stand
> out better, and you don't have the [] characters doing double duty
> denoting list literals and indexing alike.

Oh, is *THAT* what he meant. I had no idea why it was so laughable.

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. In Pike, a mapping is ([]) and a multiset (you
can actually have duplicates, though I don't usually make use of that)
is (<>). But that's a pretty minor design decision, and I wouldn't
laugh at either for the choice. It's like choosing to paint your car
blue or red.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38550

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 literal syntax for EACH and EVERY type? And BTW, if you don't already know, this is how you notate an empty set in Python:

py> set([])
set([])

IMO "Set Types" should only exists as a concequence of "freezing" an array, and should have NO literal syntax avaiable.

[toc] | [prev] | [next] | [standalone]

#38552

On Sun, Feb 10, 2013 at 3:26 PM, Rick Johnson
<rantingrickjohnson@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? {}
>> means an empty dict.
>
> What makes you believe that a language must provide literal syntax for EACH and EVERY type? And BTW, if you don't already know, this is how you notate an empty set in Python:
>
> py> set([])
> set([])

Or omit the argument, to avoid working with a pointless empty list.
But what happens if you first execute:

set = tuple

? This is not a set literal, it's an expression that usually returns a set.

> IMO "Set Types" should only exists as a concequence of "freezing" an array, and should have NO literal syntax avaiable.

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. You can work with integers 1, 2, 3, or floats 1.0, 2.0, 3.0. C
gives you those. In Python, you can work with lists, too, and C
doesn't give you those (you have array *initializer* syntax, but
that's not the same thing). It's perfectly plausible to dereference a
literal:

dow = ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"][day%7]

Of course, it's perfectly plausible to do that with a function, too.
You could define something like this:

def agg(*args): return args
dow = agg("Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat")[day%7]

But the question is, why? Why call a function when the interpreter can
do the work directly at compile stage? There's absolutely no value in
forcing things to be done at run-time.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38636

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 i must admit that you are correct. Of course the problem with literal syntax is symbol congestion. But i have a solution. A solution that can survive the limited number of grouping chars that python employs now. Except, i will define them explicitly

{}: denotes ANY mapping object.
[]: denotes ANY mutable sequence object.
(): denotes ANY immutable sequence object.
<>: Hmm, there must be a good use for this one!

The key to removing complexity is to declare the literal syntax much the way Python "represents" a "set". Observe:

py> set([1,2,3])
set([1,2,3])

Using this syntax we can apply "grouping" chars in proper context when writing literal syntax. The only problem is how do we make this syntax unique enough to avoid confusion and complexity???  Some hypothetical literal syntax, "syntaxes", include:

<set>[1,2,3] # Set literal
<set>(1,2,3) # FrozenSet literal

set=>[1,2,3] # Set literal
set=>(1,2,3) # FrozenSet literal

set::[1,2,3] # Set literal
set::(1,2,3) # FrozenSet literal

set<[1,2,3]> # Set literal
set<(1,2,3)> # FrozenSet literal

<set[1,2,3]> # Set literal
<set(1,2,3)> # FrozenSet literal

set([1,2,3]) # Set literal
set((1,2,3)) # FrozenSet literal


...and to avoid conflicts with the "set" function, we just remove the set function! Only the types list, dict, and tuple(bka:StaticList!) should have a built-in constructor function, the remaining should have a typical OOP style constructor:

mySet = Set([1,2,3])
mySetLiteral = set([1,2,3])

[toc] | [prev] | [next] | [standalone]

#38637

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 i must admit that you are correct. Of course the problem with literal syntax is symbol congestion. But i have a solution. A solution that can survive the limited number of grouping chars that python employs now. Except, i will define them explicitly

{}: denotes ANY mapping object.
[]: denotes ANY mutable sequence object.
(): denotes ANY immutable sequence object.
<>: Hmm, there must be a good use for this one!

The key to removing complexity is to declare the literal syntax much the way Python "represents" a "set". Observe:

py> set([1,2,3])
set([1,2,3])

Using this syntax we can apply "grouping" chars in proper context when writing literal syntax. The only problem is how do we make this syntax unique enough to avoid confusion and complexity???  Some hypothetical literal syntax, "syntaxes", include:

<set>[1,2,3] # Set literal
<set>(1,2,3) # FrozenSet literal

set=>[1,2,3] # Set literal
set=>(1,2,3) # FrozenSet literal

set::[1,2,3] # Set literal
set::(1,2,3) # FrozenSet literal

set<[1,2,3]> # Set literal
set<(1,2,3)> # FrozenSet literal

<set[1,2,3]> # Set literal
<set(1,2,3)> # FrozenSet literal

set([1,2,3]) # Set literal
set((1,2,3)) # FrozenSet literal


...and to avoid conflicts with the "set" function, we just remove the set function! Only the types list, dict, and tuple(bka:StaticList!) should have a built-in constructor function, the remaining should have a typical OOP style constructor:

mySet = Set([1,2,3])
mySetLiteral = set([1,2,3])

[toc] | [prev] | [next] | [standalone]

#38566

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 sets:

def example(arg):
    if arg in {'spam', 'ham', 'eggs', 'cheese'}:
        ...

Unfortunately, set literals create *mutable* sets, not frozensets. That
means that the compiler wastes time and memory creating am over-allocated
mutable set object. If set literals created immutable frozensets, there
would be some nice opportunities for the compiler to optimize this
use-case.

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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#38574

In article <5117868b$0$29998$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Sets are not frozen lists.

Right.  Tuples are frozen lists (ducking and running).

[toc] | [prev] | [next] | [standalone]

#38586

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 
frozensets, such as {{ }} or something. (Although that might clutter 
with a set containing a set.)


Thomas

[toc] | [prev] | [next] | [standalone]

#38665

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. 

I may have spoken too soon on this issue. My reasoning for /not/ having a literal set syntax was due to symbol congestion, however as i described in another post, the problem can be solved by literally "type declaring" the literal.

[toc] | [prev] | [next] | [standalone]

#38671

On Mon, Feb 11, 2013 at 11:18 PM, Rick Johnson
<rantingrickjohnson@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 wording was a bit clumsy on my part.
>
>> > and should have NO literal syntax available.
>
> I may have spoken too soon on this issue. My reasoning for /not/ having a literal set syntax was due to symbol congestion, however as i described in another post, the problem can be solved by literally "type declaring" the literal.

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_ = ({ 1, 2, 3 })
set_ = [< 1, 2, 3 >]
frozenset_ = (< 1, 2, 3 >)

I'm not actually sure where I stand on that argument. Some of those
types are distinctly unusual (when would you use frozendict?), and may
well not need literal notation. But it is nice to have them all.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38677

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_ = ({ 1, 2, 3 })
> set_ = [< 1, 2, 3 >]
> frozenset_ = (< 1, 2, 3 >)

I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once you start nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sort of declaration though, something like i proposed earlier in the thread. The easiest is to use:

  set({1,2,3})

but that looks like a function call! So we'd need a unique syntax. Either a single tag like:

  set{1,2,3}

Or we could use start and end tags like:

  set{1,2,3}set

where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:

  [1,2,3] # list
  {k:v} # dict
  (1,2,3) # tuple

However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?

  (1)

It's NOT a tuple! But it looks like a tuple! What is this:

  1,2

it IS a tuple, but it does not look like a tuple! 

That's an unfortunate side effect of a poorly thought-out tuple syntax. 

[toc] | [prev] | [next] | [standalone]

#38681

On Tue, Feb 12, 2013 at 12:13 AM, Rick Johnson
<rantingrickjohnson@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 you're actually against is the symbols. Okay. I
have a bit of a Scheme (rubs hands together with glee) for you. We can
thtandardithe on jutht one thymbol pair and uthe wordth for the retht.
And to make it clear that thith ith no function call, we'll put the
word *inthide* the parenthetheth.

(set 1 2 3)
(dict 1 2 3 4)   ; implicitly pairs up the arguments
(tuple 1 2)
(list 1 2 3 4)    ; This seems like a real good idea.

ChrisA

[toc] | [prev] | [next] | [standalone]

#38719

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 "}set" are delimiters.
> 
> Interesting. So what you're actually against is the symbols. 

Nothing really. Chars are innocent creatures. They themselves know not of evil. However groups of chars have the capacity to collectively emit evil in the form of density, of which who's demon spawn is "incomprehensibility"!

> Okay. I
> have a bit of a Scheme (rubs hands together with glee) for you. 
> [snip lisping]
> 
> (set 1 2 3)
> (dict 1 2 3 4)   ; implicitly pairs up the arguments
> (tuple 1 2)
> (list 1 2 3 4)    ; This seems like a real good idea.

Well i must admit that this syntax would be beautifully consistent--except for the dict which is far too implicit! I would gravitate to something more like:

(dict 'a':1 'b':2 'name':'fred')

But what happens when we start nesting?

(dict: 
'employees':
    (list 
    'sarah:(dict 
        'age':22,
        'position:'CSR'),
    'john':(dict 
        'age':46,
        'position':'grounds'),
    'albert':(dict 
        'age':85,
        'position':'CEO'),
    ), # end list
'key1':(tuple 1,2,10.1),
'key2':(set 10,20,30),
) # end dict

As opposed to:

{
'employees':[
    'sarah:{
        'age':22,
        'position:'CSR'},
    'john':{
        'age':46,
        'position':'grounds'},
    'albert':{
        'age':85,
        'position':'CEO'},
    ],
'key1':(1,2,10.1),
'key2':set([10,20,30]),
}

But then again, literals are code smell anyway!

  http://en.wikipedia.org/wiki/Code_smell
  
I use literals like anyone else, but i sometimes wonder if i could live without them (probably not string literals though!!!). Many of us can even remember a day (before we learned about recursion) when we would write out gobs and gobs of unnecessary literals that could easily be built with a for loop. I think _most_ literals could just as easily be replicated in code. Consider this alternative approach to building the the dict above:

database = d = {}
d['sarah'] = k = {}
k['age'] = 22
k['position'] = 'CSR'
d['john'] = k = {}
k['age'] = 46
k['position'] = 'grounds'
d['albert'] = k = {}
k['age'] = 85
k['position'] = 'CEO'
d['key1'] = (1,2,10.1)
d['key2'] = [10,20,30]

Not as structured as the literal, but by utilizing indention the message will become clearer. Oh, yeah, better make sure we built that structure correctly!

py> import pprint
py> pprint.pprint(d)
{'albert': {'age': 85, 'position': 'CEO'},
 'john': {'age': 46, 'position': 'grounds'},
 'key1': (1, 2, 10.1),
 'key2': [10, 20, 30],
 'sarah': {'age': 22, 'position': 'CSR'}}

But then the old "for x in LITERAL_SEQ" and the "if this in LITERAL_SEQ" will bite you. Damn literals! Can't live with them, can't live without them.

[toc] | [prev] | [next] | [standalone]

#38720

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 "}set" are delimiters.
> 
> Interesting. So what you're actually against is the symbols. 

Nothing really. Chars are innocent creatures. They themselves know not of evil. However groups of chars have the capacity to collectively emit evil in the form of density, of which who's demon spawn is "incomprehensibility"!

> Okay. I
> have a bit of a Scheme (rubs hands together with glee) for you. 
> [snip lisping]
> 
> (set 1 2 3)
> (dict 1 2 3 4)   ; implicitly pairs up the arguments
> (tuple 1 2)
> (list 1 2 3 4)    ; This seems like a real good idea.

Well i must admit that this syntax would be beautifully consistent--except for the dict which is far too implicit! I would gravitate to something more like:

(dict 'a':1 'b':2 'name':'fred')

But what happens when we start nesting?

(dict: 
'employees':
    (list 
    'sarah:(dict 
        'age':22,
        'position:'CSR'),
    'john':(dict 
        'age':46,
        'position':'grounds'),
    'albert':(dict 
        'age':85,
        'position':'CEO'),
    ), # end list
'key1':(tuple 1,2,10.1),
'key2':(set 10,20,30),
) # end dict

As opposed to:

{
'employees':[
    'sarah:{
        'age':22,
        'position:'CSR'},
    'john':{
        'age':46,
        'position':'grounds'},
    'albert':{
        'age':85,
        'position':'CEO'},
    ],
'key1':(1,2,10.1),
'key2':set([10,20,30]),
}

But then again, literals are code smell anyway!

  http://en.wikipedia.org/wiki/Code_smell
  
I use literals like anyone else, but i sometimes wonder if i could live without them (probably not string literals though!!!). Many of us can even remember a day (before we learned about recursion) when we would write out gobs and gobs of unnecessary literals that could easily be built with a for loop. I think _most_ literals could just as easily be replicated in code. Consider this alternative approach to building the the dict above:

database = d = {}
d['sarah'] = k = {}
k['age'] = 22
k['position'] = 'CSR'
d['john'] = k = {}
k['age'] = 46
k['position'] = 'grounds'
d['albert'] = k = {}
k['age'] = 85
k['position'] = 'CEO'
d['key1'] = (1,2,10.1)
d['key2'] = [10,20,30]

Not as structured as the literal, but by utilizing indention the message will become clearer. Oh, yeah, better make sure we built that structure correctly!

py> import pprint
py> pprint.pprint(d)
{'albert': {'age': 85, 'position': 'CEO'},
 'john': {'age': 46, 'position': 'grounds'},
 'key1': (1, 2, 10.1),
 'key2': [10, 20, 30],
 'sarah': {'age': 22, 'position': 'CSR'}}

But then the old "for x in LITERAL_SEQ" and the "if this in LITERAL_SEQ" will bite you. Damn literals! Can't live with them, can't live without them.

[toc] | [prev] | [next] | [standalone]

#38712

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 ]]
> 
> > tuple_ = ([ 1, 2, 3 ])
> 
> > dict_ = [{ 1, 2, 3 }]
> 
> > frozendict_ = ({ 1, 2, 3 })
> 
> > set_ = [< 1, 2, 3 >]
> 
> > frozenset_ = (< 1, 2, 3 >)
> 
> 
> 
> I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once you start nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sort of declaration though, something like i proposed earlier in the thread. The easiest is to use:
> 
> 
> 
>   set({1,2,3})
> 
> 
> 
> but that looks like a function call! So we'd need a unique syntax. Either a single tag like:
> 
> 
> 
>   set{1,2,3}
> 
> 
> 
> Or we could use start and end tags like:
> 
> 
> 
>   set{1,2,3}set
> 
> 
> 
> where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:
> 
> 
> 
>   [1,2,3] # list
> 
>   {k:v} # dict
> 
>   (1,2,3) # tuple
> 
> 
> 
> However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?
> 
> 
> 
>   (1)
> 
> 
> 
> It's NOT a tuple! But it looks like a tuple! What is this:
> 
> 
> 
>   1,2
> 
> 
> 
> it IS a tuple, but it does not look like a tuple! 
> 
> 
> 
> That's an unfortunate side effect of a poorly thought-out tuple syntax.

I am thinking a mutated list temporarily is useful when a list is to be used 
to be iterated through all of its elements efficiently.

A permanently mutated list is a tuple of constant objects.

As for the set type, I prefer to use the operations of the list,
dictionaries in Python to act for the designed purposes. 

 

[toc] | [prev] | [next] | [standalone]

#38731

On Tue, Feb 12, 2013 at 12:06 PM, 88888 Dihedral
<dihedral88888@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

[toc] | [prev] | [next] | [standalone]

#38774

On Monday, February 11, 2013 11:55:19 PM UTC-6, Chris Angelico wrote:
> On Tue, Feb 12, 2013 at 12:06 PM, 88888 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 it through the eyes of clarity.

"A permanently mutated list..."

A list that has been mutated permanently, that is, it cannot be changed back into a list. psst: i have a sneaking suspicion that he his referring to tuples, let's see.

"...is a tuple..."

Ha! Well in Python the immutable sequence type /is/ a tuple after all.

"...of constant objects..."

The tuple contains objects, and it's objects will maintain a constant ordering (relatively in tuple structure) until until the tuple's death. 

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. But in reality, although a tuple (bka:StaticList) cannot expand to add more objects, or shrink to eject existing objects, the objects themselves CAN change their own internal state WITHOUT disrupting the immutable harmony of the tuple. 

Observe:
    
py> class Foo(object):
	pass
py> foo = Foo()
py> t = (1,'1', foo)
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)
py> t[-1].bar = "abc"
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)

Or by expanding a list

py> t = (1,2,3)
py> t = t+([],)
py> t
(1, 2, 3, [])
py> t[-1].append('circus')
py> t
(1, 2, 3, ['circus'])

[1] Which is an unfortunate side-effect of polysemy and compounded exponentially by naive (and sometimes a purely malevolent intent when) transformation of words into esoteric problem domains.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web