Mailing List Archive

evaluation question
Hi

This is probably a dumb newbie question but I've just started to learn
python3 and eval() isn't behaving as I'd expect in that it works for
some things and not others. eg:

>>> eval("1+1")
2
>>> eval("print(123)")
123
>>> eval("for i in range(1,10): i")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1
for i in range(1,10): i
^
SyntaxError: invalid syntax

Why did the 3rd one fail? Does it not handle complex expressions?

Thanks for any help



--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
Muttley@dastardlyhq.com writes:

> Hi

It looks like you posted this question via Usenet. comp.lang.python is
essentially dead as a Usenet group. It exists, and gets NNTP versions
of mail sent to the mailing list, but nothing posted to the group via
NNTP get send on the mailing list. I prefer Usenet and dislike mailing
lists but that just means I can't really contribute to this "group"

The "python-list" an an excellent resource (if you like the email
interface) and you can subscribe here:

https://mail.python.org/mailman/listinfo/python-list>,

> This is probably a dumb newbie question but I've just started to learn
> python3 and eval() isn't behaving as I'd expect in that it works for
> some things and not others. eg:
>
>>>> eval("1+1")
> 2
>>>> eval("print(123)")
> 123
>>>> eval("for i in range(1,10): i")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<string>", line 1
> for i in range(1,10): i
> ^
> SyntaxError: invalid syntax
>
> Why did the 3rd one fail? Does it not handle complex expressions?

It handles only expressions, and "for i in range(1,10): i" is not an
expression. You can use

>>> exec("for i in range(1,10): i")

or, to confirm that something is happening:

>>> exec("for i in range(1,10): print(i)")
1
2
3
4
5
6
7
8
9

See: https://docs.python.org/3/library/functions.html?highlight=eval#eval
and the immediately following entry.

--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Sat, 28 Jan 2023 at 11:45, <Muttley@dastardlyhq.com> wrote:
>
> Hi
>
> This is probably a dumb newbie question but I've just started to learn
> python3 and eval() isn't behaving as I'd expect in that it works for
> some things and not others. eg:
>
> >>> eval("1+1")
> 2
> >>> eval("print(123)")
> 123
> >>> eval("for i in range(1,10): i")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<string>", line 1
> for i in range(1,10): i
> ^
> SyntaxError: invalid syntax
>
> Why did the 3rd one fail? Does it not handle complex expressions?
>

There's a difference between *expressions* (which have values) and
*statements* (which do stuff, including control flow like loops). You
may want the exec function instead.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 28/01/2023 05.37, Muttley@dastardlyhq.com wrote:
> This is probably a dumb newbie question but I've just started to learn
> python3 and eval() isn't behaving as I'd expect in that it works for
> some things and not others. eg:
>
>>>> eval("1+1")
> 2
>>>> eval("print(123)")
> 123
>>>> eval("for i in range(1,10): i")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<string>", line 1
> for i in range(1,10): i
> ^
> SyntaxError: invalid syntax
>
> Why did the 3rd one fail? Does it not handle complex expressions?

eval() is very powerful, and therefore rather dangerous in the risks it
presents.

Thus, seems a strange/advanced question for a "newbie" to be asking. YMMV!

Do you know about the Python REPL?

If you open python within a terminal, each of the three
expressions/compound-statements listed will work, as desired, without
eval().

dn $ ... python
Python 3.11.1 (main, Jan 6 2023, 00:00:00) [GCC 12.2.1 20221121 (Red
Hat 12.2.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> print( 123 )
123
>>> for i in range( 1, 10 ): i
...
1
2
3
4
5
6
7
8
9
>>> exit()

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Fri, 27 Jan 2023 21:04:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Muttley@dastardlyhq.com writes:
>
>> Hi
>
>It looks like you posted this question via Usenet. comp.lang.python is
>essentially dead as a Usenet group. It exists, and gets NNTP versions
>of mail sent to the mailing list, but nothing posted to the group via
>NNTP get send on the mailing list. I prefer Usenet and dislike mailing
>lists but that just means I can't really contribute to this "group"
>
>The "python-list" an an excellent resource (if you like the email
>interface) and you can subscribe here:
>
>https://mail.python.org/mailman/listinfo/python-list>,
>
>> This is probably a dumb newbie question but I've just started to learn
>> python3 and eval() isn't behaving as I'd expect in that it works for
>> some things and not others. eg:
>>
>>>>> eval("1+1")
>> 2
>>>>> eval("print(123)")
>> 123
>>>>> eval("for i in range(1,10): i")
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "<string>", line 1
>> for i in range(1,10): i
>> ^
>> SyntaxError: invalid syntax
>>
>> Why did the 3rd one fail? Does it not handle complex expressions?
>
>It handles only expressions, and "for i in range(1,10): i" is not an
>expression. You can use
>
>>>> exec("for i in range(1,10): i")

Ok, thanks.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Sat, 28 Jan 2023 14:22:01 +1300
dn <PythonList@DancesWithMice.info> wrote:
>On 28/01/2023 05.37, Muttley@dastardlyhq.com wrote:
>> This is probably a dumb newbie question but I've just started to learn
>> python3 and eval() isn't behaving as I'd expect in that it works for
>> some things and not others. eg:
>>
>>>>> eval("1+1")
>> 2
>>>>> eval("print(123)")
>> 123
>>>>> eval("for i in range(1,10): i")
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "<string>", line 1
>> for i in range(1,10): i
>> ^
>> SyntaxError: invalid syntax
>>
>> Why did the 3rd one fail? Does it not handle complex expressions?
>
>eval() is very powerful, and therefore rather dangerous in the risks it
>presents.
>
>Thus, seems a strange/advanced question for a "newbie" to be asking. YMMV!

Well ok, new-ish :)

>Do you know about the Python REPL?

Haven't learnt the acronyms yet.

>If you open python within a terminal, each of the three
>expressions/compound-statements listed will work, as desired, without
>eval().

Umm, yeah, thats kind of obvious isn't it?

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
> Hi
>
> This is probably a dumb newbie question but I've just started to learn
> python3 and eval() isn't behaving as I'd expect in that it works for
> some things and not others. eg:
>
>>>> eval("1+1")
> 2
>>>> eval("print(123)")
> 123
>>>> eval("for i in range(1,10): i")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<string>", line 1
> for i in range(1,10): i
> ^
> SyntaxError: invalid syntax
>
> Why did the 3rd one fail? Does it not handle complex expressions?
>
> Thanks for any help
>
>
>

This might -- or might not -- be useful:

eval( "print( [i for i in range(1, 10)] )" )

It prints a list, but you probably knew that:

[1, 2, 3, 4, 5, 6, 7, 8, 9]

Louis
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
Muttley@dastardlyhq.com wrote:
> On Sat, 28 Jan 2023 14:22:01 +1300
> dn <PythonList@DancesWithMice.info> wrote:
>> Do you know about the Python REPL?
>
> Haven't learnt the acronyms yet.

REPL stands for "Read Evaluate Print Loop". It basically refers to the
interactive interpreter, which reads input you type, evaluates it,
prints the result, and loops (repeatedly does that).

An interesting point from your examples is that the output from the
first two comes from different steps in that loop.

>>> eval("1+1")
2

Here, the E (evaluation) step runs eval("1+1"), which returns 2. The P
(print) step then prints that result. If this was in a script, you
wouldn't see any output, and the statement is pretty much useless -
you'd need to assign the result to a variable or explicitly print it.

>>> eval("print(123)")
123

Here, the E step runs eval("print(123)"), which prints 123 and returns
None. The P step doesn't print anything if the result is None. You'd
still see that output if this was in a script.

Using eval in those examples is pretty pointless, since:
>>> 1+1
>>> print(123)
would produce the same results - but of course they were just simple
examples.

--
Mark.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/29/2023 4:15 PM, elvis-85792@notatla.org.uk wrote:
> On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>> On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
>
>
>>>>>> eval("print(123)")
>>> 123
>
>
> Does OP expect the text to come from the eval or from the print?
>
>>>> x = print( [i for i in range(1, 10)] )
> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>
>>>> x
> (nothing printed)

Because print() returns nothing (i.e., the statement x is None is True).
Other common constructs that return nothing are append(), sort(), and
add(). It can be easy to forget this and write

l2 = l1.sort() # l2 == None

OTOH, you can (by slightly abusing the lambda) use this behavior to make
a lambda expression print what it's receiving:

>>> y = lambda x: print(f'Got {x}') or x**2
>>> z = y(3)
Got 3
>>> z
9
>>>

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Sun, 29 Jan 2023 23:57:51 -0500
Thomas Passin <list1@tompassin.net> wrote:
>On 1/29/2023 4:15 PM, elvis-85792@notatla.org.uk wrote:
>> On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>> On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
>>
>>
>>>>>>> eval("print(123)")
>>>> 123
>>
>>
>> Does OP expect the text to come from the eval or from the print?
>>
>>>>> x = print( [i for i in range(1, 10)] )
>> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>
>>>>> x
>> (nothing printed)
>
>Because print() returns nothing (i.e., the statement x is None is True).

I don't understand this. What was the point of the upheaval of converting
the print command in python 2 into a function in python 3 if as a function
print() doesn't return anything useful? Surely even the length of the
formatted string as per C's sprintf() function would be helpful?

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 30/01/2023 09:41, Muttley@dastardlyhq.com wrote:
> On Sun, 29 Jan 2023 23:57:51 -0500
> Thomas Passin <list1@tompassin.net> wrote:
>> On 1/29/2023 4:15 PM, elvis-85792@notatla.org.uk wrote:
>>> On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>> On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
>>>
>>>>>>>> eval("print(123)")
>>>>> 123
>>>
>>> Does OP expect the text to come from the eval or from the print?
>>>
>>>>>> x = print( [i for i in range(1, 10)] )
>>> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>
>>>>>> x
>>> (nothing printed)
>> Because print() returns nothing (i.e., the statement x is None is True).
> I don't understand this. What was the point of the upheaval of converting
> the print command in python 2 into a function in python 3 if as a function
> print() doesn't return anything useful? Surely even the length of the
> formatted string as per C's sprintf() function would be helpful?
>
That's a fair question, or rather 2 fair questions.
There is an explanation of why the change was made at
    https://snarky.ca/why-print-became-a-function-in-python-3/
In brief: (a) the print() function is more flexible and can be used in
expressions
               (b) Python's syntax was simplified by dropping the
special syntax used by the print statement.
sys.stdout.write() does return the number of characters output (you
could use this instead of print() if you need this;
remember to add a '\n' character at the end of  a line).  I guess the option
of making print() do the same either was not considered, or was
rejected, when print was made a function.
Best wishes
Rob Cliffe

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
> What was the point of the upheaval of converting
> the print command in python 2 into a function in python 3 if as a function
> print() doesn't return anything useful?

It was made a function because there's no good reason for it
to have special syntax in the language.

Functions don't need to return things to justify their existence,
and in fact the usual convention is that functions whose purpose
is to have an effect just return None.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Tue, 31 Jan 2023 12:57:33 +1300
Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>> What was the point of the upheaval of converting
>> the print command in python 2 into a function in python 3 if as a function
>> print() doesn't return anything useful?
>
>It was made a function because there's no good reason for it
>to have special syntax in the language.

All languages have their ugly corners due to initial design mistakes and/or
constraints. Eg: java with the special behaviour of its string class, C++
with "=0" pure virtual declaration. But they don't dump them and make all old
code suddenly cease to execute.

Pragmatism should always come before language purity.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> What was the point of the upheaval of converting
>>> the print command in python 2 into a function in python 3 if as a function
>>> print() doesn't return anything useful?
>>
>> It was made a function because there's no good reason for it
>> to have special syntax in the language.
>
> All languages have their ugly corners due to initial design mistakes and/or
> constraints. Eg: java with the special behaviour of its string class, C++
> with "=0" pure virtual declaration. But they don't dump them and make all old
> code suddenly cease to execute.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://snarky.ca/why-python-3-exists/
--
https://mail.python.org/mailman/listinfo/python-list
RE: evaluation question [ In reply to ]
I think its has been discussed here that many functions are DELIBERATELY
designed to return without returning anything. Earlier languages like Pascal
had explicit ideas that a function that did not return a value was declared
as a "procedure" but many other languages like python make no real
differentiation.

Some functions are designed for a sort of side-effect and often there is
nothing much that needs to be returned or even can be. If a function prints
a dozen items one at a time, should it return nothing, or a copy of the last
item or somehow of all items? Generally nothing looks right. If you want to
return something, fine. Do it explicitly.

Similar arguments have been made about methods that do things like sort the
contents of an object internally and then return nothing. Some would like
the return to be the (now altered) object itself. You can emulate that by
not sorting internally but instead sorted(object) returns a new object that
has been sorted from the old one.

So should or could print return anything? Other languages exist, like R,
that do return (and often ignore) whatever print displayed elsewhere. This
can be of use in many ways such as making it easier to print or store
additional copies without recalculating.

My preference might be to simply allow a local option at the end of a print
statement such as print(..., return=True) or even a way to set a global
option so all print statements can be turned on when you want. But is this
pythonic? In particular, people who want to give type hints now can safely
claim it returns None and would have to modify that so it can optionally
return something like str or None. And, of course, once you change print()
this way, someone else will want the number of characters (or perhaps bytes)
returned instead.

Much of this can be worked around by simply making your own customized print
function which evaluates the arguments to make a string and then calls
print, perhaps with the results pre-calculated, and returns what you wanted.
That is not as easy as it sounds, though as print supports various
arguments like sep= and end= and file= and flush= so a weird but doable idea
is simply to substitute a temporary file for any file= argument and write
the results to a temporary file or something in memory that emulates a file.
You can then read that back in and return what you want after handling the
original print statement with the original arguments, or perhaps just use
your result to any actually specified file or the default.

You can thus create something like what you want and leave the original
print() command alone to do what it was designed to do.

And, in general, people who want a copy of what they print, often use other
python functionality to craft some or all parts of the text they want
printed and only then call print() and thus already may have the ability to
use the text afterwards.

For many purposes, including efficiency, returning nothing makes good sense.
But it is not really the only choice or the right choice and yet, if you
want to use THIS language, it has to be accepted as the documented choice.


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Thomas Passin
Sent: Tuesday, January 31, 2023 1:16 PM
To: python-list@python.org
Subject: Re: evaluation question

On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> What was the point of the upheaval of converting the print command
>>> in python 2 into a function in python 3 if as a function
>>> print() doesn't return anything useful?
>>
>> It was made a function because there's no good reason for it to have
>> special syntax in the language.
>
> All languages have their ugly corners due to initial design mistakes
> and/or constraints. Eg: java with the special behaviour of its string
> class, C++ with "=0" pure virtual declaration. But they don't dump
> them and make all old code suddenly cease to execute.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://snarky.ca/why-python-3-exists/
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
Greg Ewing wrote:
> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>> What was the point of the upheaval of converting
>> the print command in python 2 into a function in python 3 if as a
>> function
>> print() doesn't return anything useful?
>
> It was made a function because there's no good reason for it
> to have special syntax in the language.

I think I saw somewhere that making print a function also had something
to do with being able to add extra keyword arguments like sep and end.
The syntax for printing to a specific file already seemed a bit odd with
the print statement, and adding extra arguments would have made it even
more clunky (yeah, I know ">>" is similar to C++ streams, but it looks
out of place in Python).

They couldn't fully make the change from print statement to print
function without breaking backward compatibility for existing code. But
there were other breaking changes being made in Python 3 anyway, so may
as well sort print out while at it and have all the breaking changes at
once.

> Functions don't need to return things to justify their existence,
> and in fact the usual convention is that functions whose purpose
> is to have an effect just return None.

--
Mark.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
import io

def countprint(*args, **kwargs):
capturekw = {k:v for k,v in kwargs.items() if k != 'file'}
buffer = io.StringIO()
capturekw['file'] = buffer
print(*args,**kwargs)
print(*args,**capturekw)
return len(buffer.getvalue())

def boolprint(*args,active:bool, **kwargs):
if active:
print(*args,**kwargs)

with open("text.txt",'w') as f:
y = countprint(1, 3, 3, sep=',', end='\n\n',file=f)
print(y)
boolprint(3,4,5,sep='/',active=True)
boolprint(7,11,active=False)

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of avi.e.gross@gmail.com <avi.e.gross@gmail.com>
Date: Tuesday, January 31, 2023 at 3:01 PM
To: 'Thomas Passin' <list1@tompassin.net>, python-list@python.org <python-list@python.org>
Subject: RE: evaluation question
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

I think its has been discussed here that many functions are DELIBERATELY
designed to return without returning anything. Earlier languages like Pascal
had explicit ideas that a function that did not return a value was declared
as a "procedure" but many other languages like python make no real
differentiation.

Some functions are designed for a sort of side-effect and often there is
nothing much that needs to be returned or even can be. If a function prints
a dozen items one at a time, should it return nothing, or a copy of the last
item or somehow of all items? Generally nothing looks right. If you want to
return something, fine. Do it explicitly.

Similar arguments have been made about methods that do things like sort the
contents of an object internally and then return nothing. Some would like
the return to be the (now altered) object itself. You can emulate that by
not sorting internally but instead sorted(object) returns a new object that
has been sorted from the old one.

So should or could print return anything? Other languages exist, like R,
that do return (and often ignore) whatever print displayed elsewhere. This
can be of use in many ways such as making it easier to print or store
additional copies without recalculating.

My preference might be to simply allow a local option at the end of a print
statement such as print(..., return=True) or even a way to set a global
option so all print statements can be turned on when you want. But is this
pythonic? In particular, people who want to give type hints now can safely
claim it returns None and would have to modify that so it can optionally
return something like str or None. And, of course, once you change print()
this way, someone else will want the number of characters (or perhaps bytes)
returned instead.

Much of this can be worked around by simply making your own customized print
function which evaluates the arguments to make a string and then calls
print, perhaps with the results pre-calculated, and returns what you wanted.
That is not as easy as it sounds, though as print supports various
arguments like sep= and end= and file= and flush= so a weird but doable idea
is simply to substitute a temporary file for any file= argument and write
the results to a temporary file or something in memory that emulates a file.
You can then read that back in and return what you want after handling the
original print statement with the original arguments, or perhaps just use
your result to any actually specified file or the default.

You can thus create something like what you want and leave the original
print() command alone to do what it was designed to do.

And, in general, people who want a copy of what they print, often use other
python functionality to craft some or all parts of the text they want
printed and only then call print() and thus already may have the ability to
use the text afterwards.

For many purposes, including efficiency, returning nothing makes good sense.
But it is not really the only choice or the right choice and yet, if you
want to use THIS language, it has to be accepted as the documented choice.


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Thomas Passin
Sent: Tuesday, January 31, 2023 1:16 PM
To: python-list@python.org
Subject: Re: evaluation question

On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> What was the point of the upheaval of converting the print command
>>> in python 2 into a function in python 3 if as a function
>>> print() doesn't return anything useful?
>>
>> It was made a function because there's no good reason for it to have
>> special syntax in the language.
>
> All languages have their ugly corners due to initial design mistakes
> and/or constraints. Eg: java with the special behaviour of its string
> class, C++ with "=0" pure virtual declaration. But they don't dump
> them and make all old code suddenly cease to execute.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://urldefense.com/v3/__https://snarky.ca/why-python-3-exists/__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yGhlD2rfk$<https://urldefense.com/v3/__https:/snarky.ca/why-python-3-exists/__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yGhlD2rfk$>
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$>

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$>
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 31/01/23 10:24 pm, Muttley@dastardlyhq.com wrote:
> All languages have their ugly corners due to initial design mistakes and/or
> constraints. Eg: java with the special behaviour of its string class, C++
> with "=0" pure virtual declaration. But they don't dump them and make all old
> code suddenly cease to execute.

No, but it was decided that Python 3 would have to be backwards
incompatible, mainly to sort out the Unicode mess. Given that,
the opportunity was taken to clean up some other mistakes as well.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/02/23 7:33 am, Stefan Ram wrote:
> Thomas Passin <list1@tompassin.net> writes:

> Some people say it is a function now so that you can redefine it.

Well, that's one benefit, but I wouldn't say it's the main one.

The point is really that you can do *anything* with it now that
you can do with a regular function -- pass it as an argument,
wrap it with another function, define your own function with a
similar signature for duck-typing purposes, etc.

> It would still be possible to have a special syntax for the outermost
> expression of an expression statement that would allow one to omit
> the parentheses,

That's only one of the syntactic oddities of the old print
statement, thogh. There was also the >> thing, special treatment
of trailing commas, etc.

Also, introducing a paren-less call syntax would be a very big
and controversial change that would be way out of proportion to
the problem.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Wed, 1 Feb 2023 at 10:47, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.

"Soft space" (the trailing comma behaviour) was an incredibly complex
wart. Glad it's gone.

> Also, introducing a paren-less call syntax would be a very big
> and controversial change that would be way out of proportion to
> the problem.

Oddly enough, that WAS actually proposed recently - by Guido himself -
as a demonstration of the power of the new PEG parser:

https://mail.python.org/archives/list/python-ideas@python.org/thread/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/

(The mailing list archive messes up formatting a bit with REPL
transcripts, thinking they're quoted text.)

The general consensus was "allowing function calls without parens
causes more issues than it solves", with plenty of examples from other
programming languages to prove this - Ruby, while generally a decent
language, shows a rather nasty wart with this particular feature (see
"Ruby allows parens-less function calls" from Steven D'Aprano in that
thread). I don't think it'll ever happen in Python, but it's nice to
know that the parser is flexible enough. It means that other weird
cases, where the intuitive expectation is different, can be better
handled (see eg "with (x as y, a as b):" syntax).

Having print as a function is WAY better than having it as a special
case with lots of warts. And it's so much easier to add extra features
to it; for instance, how would you add a "flush after printing" flag
to Py2's print statement? With a function, it's easy - just print(...,
flush=True).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/31/2023 6:18 PM, Greg Ewing wrote:
> On 1/02/23 7:33 am, Stefan Ram wrote:
>> Thomas Passin <list1@tompassin.net> writes:
>
>>    Some people say it is a function now so that you can redefine it.

Hmm, I didn't write these quotes. Maybe someone got confused by the
depth of the nested replies in this thread. Easy enough to do.

> Well, that's one benefit, but I wouldn't say it's the main one.
>
> The point is really that you can do *anything* with it now that
> you can do with a regular function -- pass it as an argument,
> wrap it with another function, define your own function with a
> similar signature for duck-typing purposes, etc.
>
>>    It would still be possible to have a special syntax for the outermost
>>    expression of an expression statement that would allow one to omit
>>    the parentheses,
>
> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.
>
> Also, introducing a paren-less call syntax would be a very big
> and controversial change that would be way out of proportion to
> the problem.
>

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 01/02/2023 11.59, Greg Ewing wrote:
> On 31/01/23 10:24 pm, Muttley@dastardlyhq.com wrote:
>> All languages have their ugly corners due to initial design mistakes
>> and/or
>> constraints. Eg: java with the special behaviour of its string class, C++
>> with "=0" pure virtual declaration. But they don't dump them and make
>> all old
>> code suddenly cease to execute.
>
> No, but it was decided that Python 3 would have to be backwards
> incompatible, mainly to sort out the Unicode mess. Given that,
> the opportunity was taken to clean up some other mistakes as well.

+1
and the move to Unicode has opened-up the Python community beyond the
US, to embrace 'the world' - a proposition (still) not well-recognised
by (only) English-speakers/writers/readers.


Even though the proposition has a troll-bait smell to it:-

1 nothing "ceased to execute" and Python 2 was maintained and developed
for quite some time and in-parallel to many Python 3 releases.

2 the only constant in this business is 'change'. I'd rather cope with
an evolution in this language (which we know and love), than one day
realise that it has become dated or inflexible, and have to learn a new,
replacement, language!

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 1/02/23 1:17 pm, dn wrote:
> 1 nothing "ceased to execute" and Python 2 was maintained and developed
> for quite some time and in-parallel to many Python 3 releases.

And a lot of effort was put into making the transition as easy
as possible, e.g. 2to3, and the features added to 2.7 to make
it easier to write code that would work in both versions.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 2023-01-31, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.

In "old" Python I used to use the trailing comma extensively, but I
could never get myself to use the >> thing. I don't know why, but it
just felt wrong.

--
Grant


--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Tue, 31 Jan 2023 21:00:53 +0000
Mark Bourne <nntp.mbourne@spamgourmet.com> wrote:
>Greg Ewing wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> What was the point of the upheaval of converting
>>> the print command in python 2 into a function in python 3 if as a
>>> function
>>> print() doesn't return anything useful?
>>
>> It was made a function because there's no good reason for it
>> to have special syntax in the language.
>
>I think I saw somewhere that making print a function also had something
>to do with being able to add extra keyword arguments like sep and end.
>The syntax for printing to a specific file already seemed a bit odd with
>the print statement, and adding extra arguments would have made it even
>more clunky (yeah, I know ">>" is similar to C++ streams, but it looks
>out of place in Python).

Why couldn't they just keep "print" and call the function , oh I dunno,
"printf" ? :)


--
https://mail.python.org/mailman/listinfo/python-list

1 2 3  View All