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

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

Most probably a stupid question, but I still want to ask

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

Contents

  Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 18:51 -0400
    Re: Most probably a stupid question, but I still want to ask Chris Angelico <rosuav@gmail.com> - 2016-04-11 08:58 +1000
    Re: Most probably a stupid question, but I still want to ask Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 09:04 +1000
    Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 16:30 -0700
      Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:17 -0400
        Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:32 -0700
        Re: Most probably a stupid question, but I still want to ask Terry Reedy <tjreedy@udel.edu> - 2016-04-10 21:45 -0400
          Re: Most probably a stupid question, but I still want to ask Marko Rauhamaa <marko@pacujo.net> - 2016-04-11 08:41 +0300
    one-element tuples [Was: Most probably a stupid question, but I still want to ask] Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:13 -0400
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:19 -0700
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:18 -0700
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:20 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:22 -0400
        Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Stephen Hansen <me+python@ixokai.io> - 2016-04-10 17:28 -0700
        Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:31 +1000
          Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 20:48 -0400
            Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:56 +1000
              Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:10 +0000
                Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 10:11 -0400
                  Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:26 +0000
            Re: one-element tuples Ned Batchelder <ned@nedbatchelder.com> - 2016-04-10 18:00 -0700
            Re: one-element tuples Stephen Hansen <me+python@ixokai.io> - 2016-04-10 18:07 -0700
            Re: one-element tuples "Martin A. Brown" <martin@linux-ip.net> - 2016-04-10 18:08 -0700
              Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 23:19 -0400
                Re: one-element tuples Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-04-11 09:57 +0300
                Re: one-element tuples Larry Hudson <orgnut@yahoo.com> - 2016-04-11 23:01 -0700
            Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 11:36 +1000
              Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 22:57 -0400
                Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 14:10 +1000
                  Re: one-element tuples Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 00:43 -0400
                    Re: one-element tuples Stephen Hansen <me+python@ixokai.io> - 2016-04-10 21:54 -0700
                    Re: one-element tuples Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 15:40 +1000
                  Re: one-element tuples Rustom Mody <rustompmody@gmail.com> - 2016-04-10 22:07 -0700
            Re: one-element tuples BartC <bc@freeuk.com> - 2016-04-11 12:15 +0100
              Re: one-element tuples Marko Rauhamaa <marko@pacujo.net> - 2016-04-11 15:12 +0300
                Re: one-element tuples Grant Edwards <invalid@invalid.invalid> - 2016-04-11 14:12 +0000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:30 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] MRAB <python@mrabarnett.plus.com> - 2016-04-11 01:33 +0100
        Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Dan Sommers <dan@tombstonezero.net> - 2016-04-11 02:22 +0000
          Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 12:34 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:38 +1000
      Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:45 +1000
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Chris Angelico <rosuav@gmail.com> - 2016-04-11 10:50 +1000
      Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 10:57 +1000
      Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 11:04 +1000
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Stephen Hansen <me@ixokai.io> - 2016-04-10 18:03 -0700
      Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask]) Tim Chase <python.list@tim.thechases.com> - 2016-04-10 19:52 -0500
      Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 11:41 +1000
        Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 12:32 +1000
          Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-10 22:51 -0400
            Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 14:08 +1000
              Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-11 01:27 -0400
                Re: Parens do create a tuple Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-11 18:01 +1000
                  Re: Parens do create a tuple Random832 <random832@fastmail.com> - 2016-04-11 09:42 -0400
          Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 13:02 +1000
          Re: Parens do create a tuple Ben Finney <ben+python@benfinney.id.au> - 2016-04-11 14:08 +1000
      Re: Parens do create a tuple Chris Angelico <rosuav@gmail.com> - 2016-04-11 11:51 +1000
        Re: Parens do create a tuple Steven D'Aprano <steve@pearwood.info> - 2016-04-11 12:57 +1000
      Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask] Tim Chase <python.list@tim.thechases.com> - 2016-04-10 19:46 -0500
    Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve@pearwood.info> - 2016-04-11 11:50 +1000
      Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-10 22:48 -0400
        Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve@pearwood.info> - 2016-04-11 13:54 +1000
          Re: Most probably a stupid question, but I still want to ask Fillmore <fillmore_remove@hotmail.com> - 2016-04-11 00:03 -0400
            Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 21:46 -0700
              Re: Most probably a stupid question, but I still want to ask Rustom Mody <rustompmody@gmail.com> - 2016-04-10 22:18 -0700
                Re: Most probably a stupid question, but I still want to ask Stephen Hansen <me+python@ixokai.io> - 2016-04-10 22:42 -0700
                  Re: Most probably a stupid question, but I still want to ask Rustom Mody <rustompmody@gmail.com> - 2016-04-10 23:57 -0700
            Re: Most probably a stupid question, but I still want to ask Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-11 17:50 +1000

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

#106819 — Re: one-element tuples

On Sunday, April 10, 2016 at 8:48:49 PM UTC-4, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that "discontinuation point" is? I'm
> > not seeing it.
> 
> Here you go:
> 
>  >>> a = '"string1"'
>  >>> b = '"string1","string2"'
>  >>> c = '"string1","string2","string3"'
>  >>> ea = eval(a)
>  >>> eb = eval(b)
>  >>> ec = eval(c)
>  >>> type(ea)
> <class 'str'>   <--- HERE !!!!
>  >>> type(eb)
> <class 'tuple'>
>  >>> type(ec)
> <class 'tuple'>
> 
> I can tell you that it exists because it bit me in the butt today...
> 
> and mind you, I am not saying that this is wrong. I'm just saying that it surprised me.

Perhaps the extra complication of eval is confusing things.  This:

    >>> a = '"string1"'
    >>> ea = eval(a)
    >>> type(ea)
    <class 'str'>

is the same as:

    >>> type("string1")
    <class 'str'>

Does that surprise you?  "string1" sure looks like a plain-old string to
me, I'm not sure why you would think it would be a tuple.

Your three expressions are:

    ea = "string1"
    eb = "string1","string2"
    ec = "string1","string2","string3"

ea is a string, eb is a two-element tuple (both elements are strings), 
and ec is a three-element tuple (all elements are strings).

As others have said, commas make tuples.  Your first expression has no
commas (and no parens!) so it is not a tuple.

--Ned.

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

#106823 — Re: one-element tuples

On Sun, Apr 10, 2016, at 05:48 PM, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that “discontinuation point” is? I'm
> > not seeing it.
> 
> Here you go:
> 
>  >>> a = '"string1"'

Here, "a" is a string that contains a double quoted string. So if you
evaluate it, you get a string.

>  >>> b = '"string1","string2"'

Here, "b" is a string that contains two double quoted strings separated
by a comma. So if you evaluate it, you get a tuple of two strings.

>  >>> c = '"string1","string2","string3"'

This is as above, but with three items.

With that in mind:
>  >>> ea = eval(a)
>  >>> eb = eval(b)
>  >>> ec = eval(c)
>  >>> type(ea)
> <class 'str'> 
>  >>> type(eb)
> <class 'tuple'>
>  >>> type(ec)
> <class 'tuple'>

This should all be expected. The commas, when you evaluate them, are in
B&C making tuples. There's only a single string in A, so you get a
string. If you wanted a one item tuple, you would have written:

>>> a = '"string1",'

Note the trailing comma.

> I can tell you that it exists because it bit me in the butt today...
> 
> and mind you, I am not saying that this is wrong. I'm just saying that it
> surprised me.

If the above doesn't explain it, then I still don't understand what
you're finding surprising and what you'd expect otherwise.

---Stephen
m e @ i x o k a i . i o

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

#106824 — Re: one-element tuples

Hello Fillmore,

> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
> <class 'str'>   <--- HERE !!!!
> >>> type(eb)
> <class 'tuple'>
> >>> type(ec)
> <class 'tuple'>
>
> I can tell you that it exists because it bit me in the butt today...
>
> and mind you, I am not saying that this is wrong. I'm just saying 
> that it surprised me.

Recently in one of these two threads on your question, people have 
identified why the behaviour is as it is.

Below, I will add one question (about eval) and one suggestion about 
how to circumvent the behaviour you perceive as a language 
discontinuity.

#1: I would not choose eval() except when there is no other 
    solution.  If you don't need eval(), it may save you some 
    headache in the future, as well, to find an alternate way.
    So, can we help you choose something other than eval()?
    What are you trying to do with that usage?

#2: Yes, but, you can outsmart Python here!  Simply include a 
    terminal comma in each case, right?  In short, you can force
    the consuming language (Python, because you are calling eval())
    to understand the string as a tuple of strings, rather than 
    merely one string.

    >>> a = '"string1",'
    >>> ea = eval(a)
    >>> len(ea), type(ea)
    (1, <type 'tuple'>)

    >>> b = '"string1","string2",'
    >>> eb = eval(b)
    >>> len(eb), type(eb)
    (2, <type 'tuple'>)

    >>> c = '"string1","string2","string3",'
    >>> ec = eval(c)
    >>> len(ec), type(ec)
    (3, <type 'tuple'>)

Good luck in your continuing Python explorations,

-Martin

P.S. Where do your double-quoted strings come from, anyway?

-- 
Martin A. Brown
http://linux-ip.net/

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

#106843 — Re: one-element tuples

Thank you for trying to help, Martin. So:

On 04/10/2016 09:08 PM, Martin A. Brown wrote:
> #1: I would not choose eval() except when there is no other
>      solution.  If you don't need eval(), it may save you some
>      headache in the future, as well, to find an alternate way.
>      So, can we help you choose something other than eval()?
>      What are you trying to do with that usage?

so, I do not quite control the format of the file I am trying to parse.

it has the format:

"str1","str2",....,"strN" => more stuff
   :

in some cases there is just one "str" which is what created me problem.
The first "str1" has special meaning and, at times, it can be alone.

The way I handle this is:

     parts = line.strip().split(" => ")
     tokens = eval(parts[0])

     if type(tokens) == str:   #Handle case that there's only one token
         columns.add(tokens)
         rowTokenString = "__Empty__"
         rows.add(rowTokenString)
         value = parts[1][:2]
         addCell(table, rowTokenString, tokens, value)
     else:
         columns.add(tokens[0])
         rowTokenString = '"'+'","'.join(tokens[1:]) + '"'
         rows.add(rowTokenString)
         value = parts[1][:2]
         addCell(table, rowTokenString, tokens[0],value)

which admittedly is not very elegant. If you have suggestions on how to avoid the use
of eval() and still achieve the same, I would be delighted to hear them

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

#106862 — Re: one-element tuples

Fillmore writes:

> so, I do not quite control the format of the file I am trying to
> parse.
>
> it has the format:
>
> "str1","str2",....,"strN" => more stuff
>   :
>
> in some cases there is just one "str" which is what created me
> problem.  The first "str1" has special meaning and, at times, it can
> be alone.
>
> The way I handle this is:
>
>     parts = line.strip().split(" => ")
>     tokens = eval(parts[0])
>
>     if type(tokens) == str:   #Handle case that there's only one token

[- -]

>     else:

[- -]

> which admittedly is not very elegant. If you have suggestions on how
> to avoid the use of eval() and still achieve the same, I would be
> delighted to hear them

It depends on what a "strK" can be. You already trust that it cannot be
"A => B", but can it be "A, B"? Can it be '"Literally" this'? Or "\"".
That is, can the strings contain commas or quote characters?

If not, some variant of this may be preferable:

        [ item.strip('"') for item in parts[0].split(',') ]

Or something like this:

        re.findall('[^",]+', parts[0])

Both are brittle if the format allows the crucial characters to occur
(or not occur) in different ways. The regex way may be flexible enough
to deal with the details, but it would be more complicated than the
above example.

One thing would be easy to do either way: _check_ the line for no
surprises, and _then_ proceed to split, or raise an alert, or deal with
each detected special case specially.

If the format allows commas or doublequotes inside the strings, the
quotation rules may be such that you might be able to abuse the CSV
reader to interpret them. It depends much on the details, and is not
different from the way you are currently relying on the first part of
the line following Python's expression syntax.

next(csv.reader(io.StringIO('"fo,o",\'"bar"\'')))
# => ['fo,o', '\'"bar"\'']

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

#106900 — Re: one-element tuples

On 04/10/2016 08:19 PM, Fillmore wrote:
>
> Thank you for trying to help, Martin. So:
>
> On 04/10/2016 09:08 PM, Martin A. Brown wrote:
>> #1: I would not choose eval() except when there is no other
>>      solution.  If you don't need eval(), it may save you some
>>      headache in the future, as well, to find an alternate way.
>>      So, can we help you choose something other than eval()?
>>      What are you trying to do with that usage?
>
> so, I do not quite control the format of the file I am trying to parse.
>
> it has the format:
>
> "str1","str2",....,"strN" => more stuff
>    :
>
> in some cases there is just one "str" which is what created me problem.
> The first "str1" has special meaning and, at times, it can be alone.
>
> The way I handle this is:
>
>      parts = line.strip().split(" => ")
>      tokens = eval(parts[0])
>

[code deleted...]

> which admittedly is not very elegant. If you have suggestions on how to avoid the use
> of eval() and still achieve the same, I would be delighted to hear them
>
>

Here is a possible alternate approach to get you started thinking in a different direction...

Assuming your input string format is always as you describe, splitting off the trailing 'noise' 
can be done the way you are already doing.  It can be done other ways as well.  (Of course, for 
a 'real' program you will probably need to verify this assumption and take appropriate action if 
necessary.)

parts = line.strip().split(' => ')[0]

Note that this trailing index of 0 will throw away the trailing junk, and leave just the initial 
part of the original line as a string.  This can then be split on the commas to give you a list 
of strings...

tokens = parts.split(',')

This will give you, for example,

['"str1"']   #  Case 1, or
['"str1"', '"str2"', '"str3"', ...]  #  Case 2

There is still a problem here.  The strings CONTAIN beginning and ending quotes INSIDE the 
strings.  We can strip these internal quotes with slicing.  I'm also using a list comprehension 
here...

tokens = [st[1:-1] for st in tokens]

Which gives:  ['str1', 'str2', 'str3', ...]

Finally, there are at least two ways of splitting off the first string:  slicing or pop().

key = tokens[0]; tokens = tokens[1:]
     or
key = tokens.pop(0)    #  This simultaneously removes the first string from the tokens list

Where key is the first string, and tokens is a list of the remaining strings.  This list may be 
empty.  You can now use the key for whatever you need it for, and you can use a for loop for the 
remaining strings.  Note that this also works correctly for an empty list -- where it will do 
nothing.

I hope this gets you started reworking (or re-thinking) your program.

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

#106829 — Re: one-element tuples

Fillmore <fillmore_remove@hotmail.com> writes:

> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that “discontinuation point” is? I'm
> > not seeing it.
>
> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
> <class 'str'>   <--- HERE !!!!
> >>> type(eb)
> <class 'tuple'>
> >>> type(ec)
> <class 'tuple'>

While I wait to find out what confuses you about the above, let me ask
another question that might get closer to the issue.

Would you find the following session confusing? Why?

    >>> a = "string1"
    >>> b = "string1", "string2"
    >>> c = "string1", "string2", "string3"

    >>> type(a)
    <class 'str'>
    >>> type(b)
    <class 'tuple'>
    >>> type(c)
    <class 'tuple'>

> and mind you, I am not saying that this is wrong. I'm just saying that
> it surprised me.

If the two examples give you different responses (one surprises you, the
other does not), I would really like to know *what the surprise is*.
What specifically did you expect, that did not happen?

-- 
 \        “I knew it was a shocking thing to say, but … no-one has the |
  `\        right to spend their life without being offended.” —Philip |
_o__)                                              Pullman, 2010-03-28 |
Ben Finney

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

#106840 — Re: one-element tuples

On 04/10/2016 09:36 PM, Ben Finney wrote:
> If the two examples give you different responses (one surprises you, the
> other does not), I would really like to know*what the surprise is*.
> What specifically did you expect, that did not happen?

now that I get the role of commas it's not surprising anymore...

thanks

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

#106851 — Re: one-element tuples

Fillmore <fillmore_remove@hotmail.com> writes:

> On 04/10/2016 09:36 PM, Ben Finney wrote:
> > If the two examples give you different responses (one surprises you, the
> > other does not), I would really like to know*what the surprise is*.
> > What specifically did you expect, that did not happen?
>
> now that I get the role of commas it's not surprising anymore...

So, will we never get your statement of what surprised you between those
examples?

Clearly there is something of interest here. I'd like to know what the
facts of the matter were; “beginner's mind” is a precious resource, not
to be squandered.

-- 
 \       “My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

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

#106852 — Re: one-element tuples

On 04/11/2016 12:10 AM, Ben Finney wrote:
>
> So, will we never get your statement of what surprised you between those
> examples?
>
> Clearly there is something of interest here. I'd like to know what the
> facts of the matter were; “beginner's mind” is a precious resource, not
> to be squandered.
>

I thought I had made the point clear with the REPL session below. I had (what seemed
to me like) a list of strings getting turned into a tuple. I was surprised that
a single string wasn't turned into a single-element tuple.
Now that I know that commas create tuples, but lack of commas don't, I'm not surprised anymore.

 >>> a = '"string1"'
 >>> b = '"string1","string2"'
 >>> c = '"string1","string2","string3"'
 >>> ea = eval(a)
 >>> eb = eval(b)
 >>> ec = eval(c)
 >>> type(ea)
<class 'str'>
 >>> type(eb)
<class 'tuple'>
 >>> type(ec)
<class 'tuple'>

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

#106854 — Re: one-element tuples

On Sun, Apr 10, 2016, at 09:43 PM, Fillmore wrote:
> I thought I had made the point clear with the REPL session below. 

Considering how many people expressed repeatedly they didn't know what
was surprising, it wasn't clear at all. 

In general you need to explain these things with your words: code is
good, show code, don't get me wrong, but you need to express your
expectations and how the difference between what happened and what you
expected surprised you.

Both parts, the code and the expression of your thoughts, are really
important to getting help around here :) 

---
Stephen Hansen
  m e @ i x o k a i . i o

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

#106859 — Re: one-element tuples

Fillmore <fillmore_remove@hotmail.com> writes:

> I thought I had made the point clear with the REPL session below. I
> had (what seemed to me like) a list of strings getting turned into a
> tuple. I was surprised that a single string wasn't turned into a
> single-element tuple.

Sure. What about the corresponding one from my example:

    >>> a = "string1"
    >>> b = "string1", "string2"
    >>> c = "string1", "string2", "string3"

    >>> type(a)
    <class 'str'>
    >>> type(b)
    <class 'tuple'>
    >>> type(c)
    <class 'tuple'>

Isn't that just as surprising as the same expressions evaluated with
‘eval’?

If not, that's what is confusing me. I can't see how one would be
expected, but the other would be surprising.

-- 
 \          “It is well to remember that the entire universe, with one |
  `\   trifling exception, is composed of others.” —John Andrew Holmes |
_o__)                                                                  |
Ben Finney

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

#106855 — Re: one-element tuples

On Monday, April 11, 2016 at 9:45:20 AM UTC+5:30, Ben Finney wrote:
> Clearly there is something of interest here. I'd like to know what the
> facts of the matter were; "beginner's mind" is a precious resource, not
> to be squandered.

That's one sensible statement in a more than usually messed up thread

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

#106871 — Re: one-element tuples

On 11/04/2016 01:48, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
>> Can you describe explicitly what that “discontinuation point” is? I'm
>> not seeing it.
>
> Here you go:
>
>  >>> a = '"string1"'
>  >>> b = '"string1","string2"'
>  >>> c = '"string1","string2","string3"'
>  >>> ea = eval(a)
>  >>> eb = eval(b)
>  >>> ec = eval(c)
>  >>> type(ea)
> <class 'str'>   <--- HERE !!!!
>  >>> type(eb)
> <class 'tuple'>
>  >>> type(ec)
> <class 'tuple'>
>
> I can tell you that it exists because it bit me in the butt today...
>
> and mind you, I am not saying that this is wrong. I'm just saying that
> it surprised me.

I think this shows more clearly what you mean:

a = 10             # int
b = 10,            # tuple
c = 10,20          # tuple
d = 10,20,30       # tuple

The difference between a and b is that trailing comma. A bit of a 
kludge, but it's enough to distinguish between a single value (x), and a 
one-element tuple (x,).

In this case, you might call it a discontinuity in the syntax as, when 
you go from d to c, you remove ",30", including the comma, but when 
going from c to b, you remove only "20".

But this can be fixed if tuples are written like this:

a = 10             # int
b = 10,            # tuple
c = 10,20,         # tuple
d = 10,20,30,      # tuple

Now, you remove "30," then "20,". No exception.

Of course this doesn't help you parsing typical input which uses commas 
as separators, not terminators!


-- 
Bartc

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

#106874 — Re: one-element tuples

BartC <bc@freeuk.com>:

> Of course this doesn't help you parsing typical input which uses
> commas as separators, not terminators!

That's a red herring. You mustn't parse with eval(). You shouldn't event
think of parsing non-Python data with eval(). Why should Python's syntax
resemble a CSV file?

Try compiling the data file with a C compiler or bash.

The real answer is to do:

    "a,b,c".split(",")
    ==> ['a', 'b', 'c']

Now, tuples would be trivial:

    tuple("a,b,c".split(","))
    ==> ('a', 'b', 'c')

but a tuple is probably not what you'd want here since the number of
data elements in the OP's question is not constant.


Marko

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

#106880 — Re: one-element tuples

On 2016-04-11, Marko Rauhamaa <marko@pacujo.net> wrote:
> BartC <bc@freeuk.com>:
>
>> Of course this doesn't help you parsing typical input which uses
>> commas as separators, not terminators!
>
> That's a red herring. You mustn't parse with eval(). You shouldn't event
> think of parsing non-Python data with eval().

And you problably shouldn't think of parsing Python data with eval()
either -- but for different reasons: It's very difficult to use eval()
safely.

-- 
Grant Edwards               grant.b.edwards        Yow! I want you to MEMORIZE
                                  at               the collected poems of
                              gmail.com            EDNA ST VINCENT MILLAY
                                                   ... BACKWARDS!!

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

#106810 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

Fillmore <fillmore_remove@hotmail.com> writes:

> Sorry guys. It was not my intention to piss off anyone...just trying
> to understand how the languare works

Frustration is understandable when learning something new :-) Hopefully
that can be a signal to take a breath, and compose messages to minimise
frustration for the readers.

> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,

Certainly there is. Tuples – like any container type – can contain zero,
one, or more items.

    >>> foo = ()
    >>> bar = ("spam",)
    >>> baz = ("spam", "eggs")
    >>> blub = ("spam", "eggs", "beans")
    >>> len(foo)
    0
    >>> len(bar)
    1
    >>> len(baz)
    2
    >>> len(blub)
    3

> and Python will automatically convert a one-element tuple to a
> string...

You appear to be confusing text representation, and program syntax, and
the values themselves.

Program syntax is the structured text you type, in order that Python
should compile it and result in program code. That source code is text
with a specific representation of values and statements.

The values themselves are what exist within the Python process while it
is executing your compiled code. There is no text representation of
that, Python manipulates the values in an internal representation
normally inaccessible to the program itself.

The text representation that objects can generate on request is yet
another matter; for convenience it sometimes matches a syntactic text
that could be used to construct an equal value, but often that's not the
case. It should not be thought of as any kind of universal rule.

> Did I get this right this time?

I hope that helps to distinguish the different matters that are
confusing you.

-- 
 \        “Last year I went fishing with Salvador Dali. He was using a |
  `\          dotted line. He caught every other fish.” —Steven Wright |
_o__)                                                                  |
Ben Finney

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

#106812 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

On 2016-04-11 01:13, Fillmore wrote:
>
> Sorry guys. It was not my intention to piss off anyone...just trying to understand how the languare works
>
> I guess that the answer to my question is: there is no such thing as a one-element tuple,
> and Python will automatically convert a one-element tuple to a string... hence the
> behavior I observed is explained...
>
>   >>> a = ('hello','bonjour')
>   >>> b = ('hello')
>   >>> b
> 'hello'
>   >>> a
> ('hello', 'bonjour')
>   >>>
>
>
> Did I get this right this time?
>
Nope. :-)

A one-element tuple can be written as:

 >>> ('hello',)
('hello',)

As has been said already, it's the comma that makes the tuple. The 
parentheses are often needed to avoid ambiguity.

For example, object are passed into a function thus:

     f(x, y)

(In reality, it's making a tuple and then passing that in.)

What if you want to pass in the tuple (1, 2) as a single argument?

     f((1, 2))

If you write this:

     f(1, 2)

it passes them in as 2 separate arguments.

Or consider this:

    f((1, 2), 3)

This has 2 arguments: the first is the tuple (1, 2) and the second is 
the int 3.

There _is_ one exception though: (). It's the empty tuple (a 0-element 
tuple). It doesn't have a comma and the parentheses are mandatory. 
There's no other way to write it.

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

#106835 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote:

> There _is_ one exception though: (). It's the empty tuple (a 0-element
> tuple). It doesn't have a comma and the parentheses are mandatory.
> There's no other way to write it.

The other way to write it is:

    tuple()

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

#106837 — Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

On Mon, Apr 11, 2016 at 12:22 PM, Dan Sommers <dan@tombstonezero.net> wrote:
> On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote:
>
>> There _is_ one exception though: (). It's the empty tuple (a 0-element
>> tuple). It doesn't have a comma and the parentheses are mandatory.
>> There's no other way to write it.
>
> The other way to write it is:
>
>     tuple()

There are lots of ways to construct an empty tuple, but only one
spelling for its literal.

ChrisA

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

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

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

csiph-web