2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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?
exec("for i in range(1,10): i")
1exec("for i in range(1,10): print(i)")
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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?
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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?
21+1
123print( 123 )
...for i in range( 1, 10 ): i
exit()
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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().
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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")
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:
2eval("1+1")
123eval("print(123)")
Traceback (most recent call last):eval("for i in range(1,10): i")
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
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.
2eval("1+1")
123eval("print(123)")
would produce the same results - but of course they were just simple1+1
print(123)
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.
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
On 2023-01-28, Peter J. Holzer <hjp-python@hjp.at> wrote:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Yes, it's certainly false. I only ever post via the newsgroup,
and I can see my postings reach the list because they appear
in the list archive on the web.
Jon Ribbens <jon+usenet@unequivocal.eu> wrote:
On 2023-01-28, Peter J. Holzer <hjp-python@hjp.at> wrote:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
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.
This is wrong. I did get Muttley's any your postings via the mailing-list.
Yes, it's certainly false. I only ever post via the newsgroup,
and I can see my postings reach the list because they appear
in the list archive on the web.
As far as I am aware the mirroring of the Python mailing list on comp.lan.python works perfectly. I love gmane! :-)
As far as I am aware the mirroring of the Python mailing list on >comp.lan.python works perfectly. I love gmane! :-)
On 2023-01-27 21:04:58 +0000, Ben Bacarisse 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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Chris Green <cl@isbd.net> wrote:
Jon Ribbens <jon+usenet@unequivocal.eu> wrote:
On 2023-01-28, Peter J. Holzer <hjp-python@hjp.at> wrote:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
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.
This is wrong. I did get Muttley's any your postings via the mailing-list.
Yes, it's certainly false. I only ever post via the newsgroup,
and I can see my postings reach the list because they appear
in the list archive on the web.
As far as I am aware the mirroring of the Python mailing list on comp.lan.python works perfectly. I love gmane! :-)
That is, of course, comp.lang.python. Too much wine! :-)
On 2023-01-27 21:04:58 +0000, Ben Bacarisse 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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
"Peter J. Holzer" <hjp-python@hjp.at> writes:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse 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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Ah, OK. I thought that was the case but I am obviously wrong. Has
there been a change, or have I been wrong for a long time!?
On 2023-01-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
"Peter J. Holzer" <hjp-python@hjp.at> writes:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse 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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Ah, OK. I thought that was the case but I am obviously wrong. Has
there been a change, or have I been wrong for a long time!?
I'm not aware of any significant period in the last twenty-one years
that it hasn't been working. Although sometimes it does feel like it
isn't, in that I reply to a post with an answer and then several
other people reply significantly later with the same answer, as if
my one had never existed... but whenever I check into it, my message
has actually always made it to the list.
Jon Ribbens <jon+u...@unequivocal.eu> writes:
On 2023-01-29, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
"Peter J. Holzer" <hjp-p...@hjp.at> writes:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
Mut...@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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Ah, OK. I thought that was the case but I am obviously wrong. Has
there been a change, or have I been wrong for a long time!?
I'm not aware of any significant period in the last twenty-one yearsI have had the same experience and, as a result, I rarely post. Maybe
that it hasn't been working. Although sometimes it does feel like it
isn't, in that I reply to a post with an answer and then several
other people reply significantly later with the same answer, as if
my one had never existed... but whenever I check into it, my message
has actually always made it to the list.
what I have to say is simply not interesting!
--
Ben.
On Saturday, January 28, 2023 at 10:02:57 PM UTC-5, Ben Bacarisse wrote:
Jon Ribbens <jon+u...@unequivocal.eu> writes:
On 2023-01-29, Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
"Peter J. Holzer" <hjp-p...@hjp.at> writes:
On 2023-01-27 21:04:58 +0000, Ben Bacarisse wrote:
Mut...@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.
This is wrong. I did get Muttley's any your postings via the
mailing-list.
Ah, OK. I thought that was the case but I am obviously wrong. Has
there been a change, or have I been wrong for a long time!?
I'm not aware of any significant period in the last twenty-one years
that it hasn't been working. Although sometimes it does feel like it
isn't, in that I reply to a post with an answer and then several
other people reply significantly later with the same answer, as if
my one had never existed... but whenever I check into it, my message
has actually always made it to the list.
I have had the same experience and, as a result, I rarely post. Maybe
what I have to say is simply not interesting!
If I remember correctly, multiple regulars that use the mailing list mentioned that they "killfiled" posts originating from Google groups.
This may contribute to such situations.
I'm not aware of any significant period in the last twenty-one years[the gateway]
that
hasn't been working. Although sometimes it does feel like it isn't, in
that I reply to a post with an answer and then several other people
reply significantly later with the same answer, as if my one had never existed...
On 2023-01-29 02:09:28 -0000, Jon Ribbens via Python-list wrote:
I'm not aware of any significant period in the last twenty-one years[the gateway]
that
hasn't been working. Although sometimes it does feel like it isn't, in
that I reply to a post with an answer and then several other people
reply significantly later with the same answer, as if my one had never
existed...
That's just because people don't read before they post.
Happens in any usenet group or mailing list (and probably in web forums,
too; but I don't really use those). I have to admit that I'm sometimes
guilty of this behaviour, too.
On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
123eval("print(123)")
[1, 2, 3, 4, 5, 6, 7, 8, 9]x = print( [i for i in range(1, 10)] )
(nothing printed)x
On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
123eval("print(123)")
Does OP expect the text to come from the eval or from the print?
[1, 2, 3, 4, 5, 6, 7, 8, 9]x = print( [i for i in range(1, 10)] )
(nothing printed)x
Got 3y = lambda x: print(f'Got {x}') or x**2
z = y(3)
9z
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:
123eval("print(123)")
Does OP expect the text to come from the eval or from the print?
[1, 2, 3, 4, 5, 6, 7, 8, 9]x = print( [i for i in range(1, 10)] )
(nothing printed)x
Because print() returns nothing (i.e., the statement x is None is True).
As far as I am aware the mirroring of the Python mailing list on comp.lan.python works perfectly. I love gmane! :-)
On Sat, 28 Jan 2023 20:07:44 +0000, Chris Green <cl@isbd.net> declaimed the following:
As far as I am aware the mirroring of the Python mailing list on >>comp.lan.python works perfectly. I love gmane! :-)
Is gmane's gmane.comp.python.general allowing posts to go through again? I had to revert to comp.lang.python some time back when gmane kept rejecting outgoing posts.
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:I don't understand this. What was the point of the upheaval of converting
On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:Because print() returns nothing (i.e., the statement x is None is True).
On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
123eval("print(123)")
Does OP expect the text to come from the eval or from the print?
[1, 2, 3, 4, 5, 6, 7, 8, 9]x = print( [i for i in range(1, 10)] )
(nothing printed)x
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?
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?
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.
No. FWIW, it's the mailing list that's blocking them, not Gmane.
That's why I wrote this:
https://github.com/GrantEdwards/hybrid-inews
It's an inews work-alike that submits most posts via gmanes NNTP
server, but will deal with particular groups
(e.g. gmane.comp.python.general) that want posts submitted via email.
It allows me to continue to read (and post to) the Python mailling
list via slrn pointed at gmane.
Grant Edwards <grant.b.edwards@gmail.com> writes:
No. FWIW, it's the mailing list that's blocking them, not Gmane.
That's why I wrote this:
https://github.com/GrantEdwards/hybrid-inews
It's an inews work-alike that submits most posts via gmanes NNTP
server, but will deal with particular groups
(e.g. gmane.comp.python.general) that want posts submitted via email.
It allows me to continue to read (and post to) the Python mailling
list via slrn pointed at gmane.
Interesting. In Gnus it was just a couple of settings to make it
understand that in this group (i.e. gmane group
gmane.comp.python.general) posts and follow-ups should be sent via mail
to the mailing list address.
Now -- last time I checked the gmane server says posting is prohibited. I used to use gmane as it retrieved directly from the mailing list
It was more fundamental than that, and not mainly about print():
On 28/01/2023 21:36, Dennis Lee Bieber wrote:
Now -- last time I checked the gmane server says posting is prohibited. >> I used to use gmane as it retrieved directly from the mailing list
I still use gmane but its no posting thing is a pain because responding
(or posting new stuff) is a now more complicated than before. So
I have to be very highly motivated to jump through the hoops.
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.
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.
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.
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.
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.
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.
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.
Thomas Passin <list1@tompassin.net> writes:
Some people say it is a function now so that you can redefine it.
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,
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.
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.
1 nothing "ceased to execute" and Python 2 was maintained and developed
for quite some time and in-parallel to many Python 3 releases.
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.
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.
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
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" ?
<Venting> Why does every language have to invent their own function to
print to the console that is very similar but not the same as the rest of
the herd?</Venting>
Its not evolution, its revolution. Evolution retains old functionality.
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.
Unicode is just a string of bytes.
C supports it with a few extra library functions to get unicode
length vs byte length and similar. Its really not that
hard.
Rewriting an entire language just to support that sounds a bit
absurd to me but hey ho...
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality.
Tell a penguin that it can fly :-)
On Wed, 1 Feb 2023 11:59:25 +1300
Greg Ewing <greg.ewing@canterbury.ac.nz> 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.
Unicode is just a string of bytes. C supports it with a few extra library functions to get unicode length vs byte length and similar. Its really
not that hard. Rewriting an entire language just to support that sounds a
bit absurd to me but hey ho...
Its not evolution, its revolution. Evolution retains old functionality.
C (the language) doesn't support Unicode at all. There are, however, libraries that can be used to deal with it.
On Wed, 1 Feb 2023 11:59:25 +1300
Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 31/01/23 10:24 pm, Muttley@dastardlyhq.com wrote:Unicode is just a string of bytes. C supports it with a few extra library functions to get unicode length vs byte length and similar. Its really
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 oldNo, but it was decided that Python 3 would have to be backwards
code suddenly cease to execute.
incompatible, mainly to sort out the Unicode mess. Given that,
the opportunity was taken to clean up some other mistakes as well.
not that hard. Rewriting an entire language just to support that sounds a
bit absurd to me but hey ho...
rbowman <bowman@montana.com> writes:
<Venting> Why does every language have to invent their own function to >>print to the console that is very similar but not the same as the rest
of the herd?</Venting>
Why do there have to be different languages at all?
On 2023-02-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
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.
Unicode is just a string of bytes.
No it isn't. Certain _encodings_ of Unicode are strings of bytes
(UTF-8, for example).
C supports it with a few extra library functions to get unicode
length vs byte length and similar. Its really not that
hard.
It is, actually.
Rewriting an entire language just to support that sounds a bit
absurd to me but hey ho...
Feel free to maintain your own fork of 2.7 :)
--b2nljkb3mdefsdhx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality.
Tell a penguin that it can fly :-)
On Thu, 2 Feb 2023 at 04:26, <Muttley@dastardlyhq.com> wrote:
Its not evolution, its revolution. Evolution retains old functionality.
By the way, I'd like to see your opinions on eternal retention of old >functionality. Which of these features are you willing to put effort
into supporting?
Yeah ok But the ancestors of penguins didn't wake up one morning, flap
their wings and fall out the tree, it happened gradually. Python2 syntax could have been retained for X versions of 3 just as C++ keeps old stuff until its eventually deprecated them removed.
On Thu, 2 Feb 2023 09:31:46 -0000 (UTC), Muttley wrote:
Yeah ok But the ancestors of penguins didn't wake up one morning, flap
their wings and fall out the tree, it happened gradually. Python2 syntax
could have been retained for X versions of 3 just as C++ keeps old stuff
until its eventually deprecated them removed.
Isn't that prolonging the agony? I had some 2.7 scripts I had to move to
MS did it big time with VB .NET. I'm sure there still are people
maintaining and extending old-style VB until it ceases to work altogether.
Then they'll be faced with the same learning curve most people suffered >through 20 years ago.
Yeah ok :) But the ancestors of penguins didn't wake up one morning, flap their wings and fall out the tree, it happened gradually. Python2 syntax could have been retained for X versions of 3 just as C++ keeps old stuff until its eventually deprecated them removed.
On Wed, 1 Feb 2023 18:28:04 +0100
"Peter J. Holzer" <hjp-python@hjp.at> wrote:
--b2nljkb3mdefsdhx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality.
Tell a penguin that it can fly :-)
Yeah ok :) But the ancestors of penguins didn't wake up one morning, flap their wings and fall out the tree, it happened gradually. Python2 syntax could have been retained for X versions of 3 just as C++ keeps old stuff until its eventually deprecated them removed.
What if its 10s of thousands of lines of
core production code? If the company it belongs to wants to add new Python 3 features it can't just plug them into the code because it won't run under Python 3, they have to do a full overhaul or even complete rewrite and that costs a lot of time and money.
What if its not a few scripts? What if its 10s of thousands of lines of
core production code? If the company it belongs to wants to add new
Python 3 features it can't just plug them into the code because it won't
run under Python 3, they have to do a full overhaul or even complete
rewrite and that costs a lot of time and money.
Unfortunately a lot of people who've never worked in large institutions
with huge code bases don't understand this.
On Fri, 3 Feb 2023 at 04:48, <Muttley@dastardlyhq.com> wrote:
Yeah ok :) But the ancestors of penguins didn't wake up one morning, flap
their wings and fall out the tree, it happened gradually. Python2 syntax
could have been retained for X versions of 3 just as C++ keeps old stuff
until its eventually deprecated them removed.
What, you mean Python 2.7 could have continued to be supported until
Python 3.8 (yes, that's not a typo) was released?
On Wed, 1 Feb 2023 18:28:04 +0100Yeah? So what would this do:
"Peter J. Holzer" <hjp-python@hjp.at> wrote:
--b2nljkb3mdefsdhxYeah ok :) But the ancestors of penguins didn't wake up one morning, flap their wings and fall out the tree, it happened gradually. Python2 syntax could have been retained for X versions of 3 just as C++ keeps old stuff until its eventually deprecated them removed.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality.Tell a penguin that it can fly :-)
On 02/02/2023 09:31, Muttley@dastardlyhq.com wrote:
On Wed, 1 Feb 2023 18:28:04 +0100Yeah? So what would this do:
"Peter J. Holzer" <hjp-python@hjp.at> wrote:
--b2nljkb3mdefsdhxYeah ok :) But the ancestors of penguins didn't wake up one morning, flap their wings and fall out the tree, it happened gradually. Python2 syntax could have been retained for X versions of 3 just as C++ keeps old stuff until its eventually deprecated them removed.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality. >> Tell a penguin that it can fly :-)
print ()
In Python 2 this prints an empty tuple.
In Python 3 this is a call to the print function with no arguments,
which prints a blank line.
You can't have it both ways.
In any case, supporting two different syntaxes simultaneously would be
messy and difficult to maintain.
On Tue, 7 Feb 2023 at 18:49, Rob Cliffe via Python-list <python-list@python.org> wrote:You are quite right Chris, and indeed I have used both solutions in my
There are two solutions to this. The most obvious is "from __future__
On 02/02/2023 09:31, Muttley@dastardlyhq.com wrote:
On Wed, 1 Feb 2023 18:28:04 +0100Yeah? So what would this do:
"Peter J. Holzer" <hjp-python@hjp.at> wrote:
--b2nljkb3mdefsdhxYeah ok :) But the ancestors of penguins didn't wake up one morning, flap >>> their wings and fall out the tree, it happened gradually. Python2 syntax >>> could have been retained for X versions of 3 just as C++ keeps old stuff >>> until its eventually deprecated them removed.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality. >>>> Tell a penguin that it can fly :-)
print ()
In Python 2 this prints an empty tuple.
In Python 3 this is a call to the print function with no arguments,
which prints a blank line.
You can't have it both ways.
In any case, supporting two different syntaxes simultaneously would be
messy and difficult to maintain.
import print_function", which gives you the full power and flexibility
of Py3 in anything back as far as 2.6; the other is to always pass a
single string argument to print:
print("")
print("spam %d ham %d" % (spam, ham))
This will work in pretty much ANY version of Python [1] and doesn't
require any sort of per-module configuration.
The idea that old syntax should be retained is only part of the story.
While it's definitely important to not break old code unnecessarily,
it is far more important to ensure that there's *some way* to write
code that works across multiple versions. That's what we have here:
even with the breaking changes, there was usually a way to make your
code run identically on multiple versions. Sometimes this means a compatibility shim at the top, like "try: raw_input; except NameError: raw_input = input", and sometimes it means following a discipline like putting b"..." for all strings that need to be bytes. But there always
needs to be a way.
ChrisA
[1] This is the part where someone points out to me that it wouldn't
work in Python 1.3 or something
On Tue, 7 Feb 2023 at 18:49, Rob Cliffe via Python-list <python-list@python.org> wrote:You are quite right Chris, and indeed I have used both solutions in my
There are two solutions to this. The most obvious is "from __future__
On 02/02/2023 09:31, Muttley@dastardlyhq.com wrote:
On Wed, 1 Feb 2023 18:28:04 +0100Yeah? So what would this do:
"Peter J. Holzer" <hjp-python@hjp.at> wrote:
--b2nljkb3mdefsdhxYeah ok :) But the ancestors of penguins didn't wake up one morning, flap >>> their wings and fall out the tree, it happened gradually. Python2 syntax >>> could have been retained for X versions of 3 just as C++ keeps old stuff >>> until its eventually deprecated them removed.
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
Its not evolution, its revolution. Evolution retains old functionality. >>>> Tell a penguin that it can fly :-)
print ()
In Python 2 this prints an empty tuple.
In Python 3 this is a call to the print function with no arguments,
which prints a blank line.
You can't have it both ways.
In any case, supporting two different syntaxes simultaneously would be
messy and difficult to maintain.
import print_function", which gives you the full power and flexibility
of Py3 in anything back as far as 2.6; the other is to always pass a
single string argument to print:
print("")
print("spam %d ham %d" % (spam, ham))
This will work in pretty much ANY version of Python [1] and doesn't
require any sort of per-module configuration.
The idea that old syntax should be retained is only part of the story.
While it's definitely important to not break old code unnecessarily,
it is far more important to ensure that there's *some way* to write
code that works across multiple versions. That's what we have here:
even with the breaking changes, there was usually a way to make your
code run identically on multiple versions. Sometimes this means a compatibility shim at the top, like "try: raw_input; except NameError: raw_input = input", and sometimes it means following a discipline like putting b"..." for all strings that need to be bytes. But there always
needs to be a way.
ChrisA
[1] This is the part where someone points out to me that it wouldn't
work in Python 1.3 or something
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?
If it's the case that you simply want to know the length of the string
that will be printed, you can, rather than expecting the I/O function
to tell that to you, figure it out for yourself ahead of time, e.g.
instead of:
username = "John Smith"
job = "Python programmer"
# this doesn't work as desired
len = print(f"{username} has occupation {job}.")
print(len)
...
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
It's worth noting WHY output functions often return a byte count. It's primarily for use with nonblocking I/O, with something like this:
buffer = b".............."
buffer = buffer[os.write(fd, buffer):]
It's extremely important to be able to do this sort of thing, but not
with the print function, which has a quite different job.
However, Python's print() function is more analogous to C's printf(),
which returns the number of characters converted for an entirely
different reason... It's precisely so that you'll know what the length
of the string that was converted is. This is most useful with the *snprintf() variants where you're actually concerned about overrunning
the buffer you've provided for the output string, so you can realloc()
the buffer if it was indeed too small, but it is also useful in the
context of, say, a routine to format text according to the size of
your terminal. In that context it really has nothing to do with
blocking I/O or socket behavior.
On 2/10/2023 4:55 PM, Python wrote:
However, Python's print() function is more analogous to C's printf(),
which returns the number of characters converted for an entirely
different reason... It's precisely so that you'll know what the length
of the string that was converted is. This is most useful with the *snprintf() variants where you're actually concerned about overrunning
the buffer you've provided for the output string, so you can realloc()
the buffer if it was indeed too small, but it is also useful in the
context of, say, a routine to format text according to the size of
your terminal. In that context it really has nothing to do with
blocking I/O or socket behavior.
But none of that applies to the Python print() function. There are no
buffers to overrun, no reason to know the length of the printed string,
no re-allocating of a buffer. It's certainly possible that one might
want to know the actual physical length of a displayed string - perhaps
to display it on a graphic - but now we're getting into font metrics and
such things, and we'll be doing something more active than displaying on
a terminal via stdout.
On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
It's worth noting WHY output functions often return a byte count. It's primarily for use with nonblocking I/O, with something like this:
buffer = b".............."
buffer = buffer[os.write(fd, buffer):]
It's extremely important to be able to do this sort of thing, but not
with the print function, which has a quite different job.
I don't know why the print() function doesn't return anything, but I'm
fine with it. I've never felt that I needed to know.
On 2/10/2023 4:55 PM, Python wrote:
However, Python's print() function is more analogous to C's printf(),
which returns the number of characters converted for an entirely
different reason... It's precisely so that you'll know what the length
of the string that was converted is. This is most useful with the *snprintf() variants where you're actually concerned about overrunning
the buffer you've provided for the output string, so you can realloc()
the buffer if it was indeed too small, but it is also useful in the
context of, say, a routine to format text according to the size of
your terminal. In that context it really has nothing to do with
blocking I/O or socket behavior.
But none of that applies to the Python print() function. There are no
buffers to overrun, no reason to know the length of the printed string, no re-allocating of a buffer.
I don't know why the print() function doesn't return anything
On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
It's worth noting WHY output functions often return a byte count. It's primarily for use with nonblocking I/O, with something like this:
buffer = b".............."
buffer = buffer[os.write(fd, buffer):]
It's extremely important to be able to do this sort of thing, but not
with the print function, which has a quite different job.
On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
You would do this instead:
message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...
It's worth noting WHY output functions often return a byte count. It's primarily for use with nonblocking I/O, with something like this:
buffer = b".............."
buffer = buffer[os.write(fd, buffer):]
It's extremely important to be able to do this sort of thing, but not
with the print function, which has a quite different job.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 446 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:21:43 |
| Calls: | 9,234 |
| Calls today: | 1 |
| Files: | 13,494 |
| Messages: | 6,063,226 |