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 f
On 2016-04-11, Fillmore wrote:
> On 04/11/2016 10:10 AM, Grant Edwards wrote:
>
>>> What behaviour did you expect instead? That's still unclear.
>>
>> I must admit this is one of the best trolls I've seen in a while...
>
> shall I take it as a compliment?
That depends on your intent, so only you
On 2016-04-11, Marko Rauhamaa wrote:
> BartC :
>
>> 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 probl
On 04/11/2016 10:10 AM, Grant Edwards wrote:
What behaviour did you expect instead? That's still unclear.
I must admit this is one of the best trolls I've seen in a while...
shall I take it as a compliment?
--
https://mail.python.org/mailman/listinfo/python-list
On 2016-04-11, Ben Finney wrote:
> Fillmore writes:
>>
>> 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.
>
> What behaviour did you expect instead? That's still unclear.
I must
BartC :
> 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
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)
>>>
On 2016-04-11 01:33, MRAB wrote:
> 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.
Except when the comma *doesn't* make the tuple:
>>> t = ()
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, i
Fillmore 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
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
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
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 thou
Fillmore 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
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 hel
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 any
On Mon, Apr 11, 2016 at 12:22 PM, Dan Sommers 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 othe
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()
--
https://mail.python.org/
Fillmore 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
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)
><--- HERE
> >>> type(eb)
>
> >>> type(ec)
>
>
> I can tell you that it exists becaus
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
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",
Fillmore writes:
> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
><--- HERE
> >>> type(eb)
>
> >>> type(ec)
>
>
> I can tell you that it exists becau
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)
On Mon, Apr 11, 2016 at 10:33 AM, MRAB wrote:
> For example, object are passed into a function thus:
>
> f(x, y)
>
> (In reality, it's making a tuple and then passing that in.)
Actually that's not the case; certain syntactic constructs allow you
to specify multiple of something, without packa
Fillmore writes:
> So, my original question makes sense. Why was a discontinuation point
> introduced by the language designer?
Can you describe explicitly what that “discontinuation point” is? I'm
not seeing it.
--
\ “People are very open-minded about new things, as long as |
`\
Fillmore 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 reade
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
On Sun, Apr 10, 2016, at 05:22 PM, Fillmore wrote:
> Hold on a sec! it turns up that there is such thing as single-element
> tuples in python:
>
> >>> c = ('hello',)
> >>> c
> ('hello',)
> >>> c[0]
> 'hello'
> >>> c[1]
> Traceback (most recent call last):
>File "", line 1, in
> IndexError
On Mon, Apr 11, 2016 at 10:13 AM, 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
On 04/10/2016 08:13 PM, 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
On Sun, Apr 10, 2016, at 05:18 PM, Stephen Hansen wrote:
> The parens are optional, I always put them in because:
> >>> b = "hello",
Ahem, "because its easy to miss the trailing comma" is what I meant to
say here.
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Apr 10, 2016, at 05:13 PM, Fillmore wrote:
> 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','bonjo
33 matches
Mail list logo
