Re: Am I banned from Discuss forum?
On 2/10/23 14:10, Marco Sulla wrote: > I was banned from the mailing list and Discuss forum for a very long time. > Too much IMHO, but I paid my dues. > > Now this is my state in the forum: > - I never posted something unrespectful in the last months > - I have a limitation of three posts per threads, but only on some threads > - Some random posts of mine are obscured and must be restored manually by > moderators > - I opened a thread about the proposal of a new section called > Brainstorming. It was closed without a reason. > - I can't post links > - Two discussions I posted in section Idea were moved to Help, without a > single line of explanation. > > If I'm not appreciated, I want to be publicly banned with a good reason, or > at least a reason. Your posts are showing up on the mailing list here just it seems. I didn't know there was a Discourse forum. Is it supposed to be sync with the mailing list and USENET? Or is it intended to replace this mailing list? I rarely see Python devs on this list, so maybe they've chosen to hang out exclusively in Discourse, which would be unfortunate. The Discourse format has never appealed to me. It's way to unstructured and gamified. I much prefer the mailing list, but alas it seems like most open source projects are moving to Discourse. -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Fri, Feb 10, 2023 at 05:48:53PM -0500, Thomas Passin wrote: > 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. Indeed. But the OP originally compared print to printf, and I was specifically addressing Chris' point about why I/O functions return the number of bytes written, which was relevant to, but maybe a bit of tangent to the original post. > I don't know why the print() function doesn't return anything You do though! :) You actually just explained why yourself... it's because it just doesn't need to. But FWIW, I wasn't addressing this point, because it had already been adequately covered in the thread. There's good reason why Python's print and C's printf work differently. In languages like C it makes sense that printf returns the length of the string. printf is the means of all three of: - formatting the string - counting its length - actually outputting the string to stdout (albeit indirectly). This sort of breaks the rule of, "do one thing, and do it well," but it does so in the name of efficiency. You might or might not want to actually know the length of the formatted string, depending on what you're doing with it. But the printf function basically needs to calculate it anyway so that it can tell the underlying system calls how many bytes to write (or tell stdio how many bytes it is adding to its buffers, or whatever), and then stuffing that length in a register to be returned to the caller is roughly free (it's probably using the register that it's going to return already to do the counting), and the caller can ignore it if it wants to. C aims to be as efficient as possible so this is a good strategy. Unlike C[*], since Python can already separate the formatting and length calculation from sending the data to stdout (I demonstrated how in my first post in the thread), it has no need for print to return the length. As I mentioned in my earlier post, if Python encounters an error condition it will raise an exception--which C can't do--so there's no reason to return a status either. What else would it return? Nothing else would really make sense. -=-=-=- * In C you could sprintf the string into a buffer, which would return its length, and then call printf on the buffer, but that would be much less efficient and a bit silly... UNLESS you actually needed to know the length of the string beforehand, e.g. to calculate where to put line breaks in a text justification routine, or something. -- https://mail.python.org/mailman/listinfo/python-list
Re: ChatGPT Generated news poster code
For a moment I thought this was going to be a script that uses ChatGPT to generate a random news post and post it to Usenet... Which would also have been kind of cool, as long as it wasn't overused. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
RE: evaluation question
There are no doubt many situations someone wants to know how long something
will be when printed but often at lower levels.
In variable-width fonts, for example, the number of characters does not
really line up precisely with how many characters. Some encodings use a
varying number of bytes and, again, the width of the output varies.
So for people who want to make 2-D formatted output like tables, or who want
to wrap lines longer than N characters, you more often let some deeper
software accept your data and decide on formatting it internally and either
print it at once, when done calculating, or in the case of some old-style
terminals, use something like the curses package that may use escape
sequences to update the screen more efficiently in various ways.
If someone wants more control over what they print, rather than asking the
print() function to return something that is mostly going to be ignored,
they can do the things others have already suggested here. You can make your
message parts in advance and measure their length or anything else before
you print. Or make a wrapper that does something for you before calling
print, perhaps only for common cases and then returns the length to you
after printing.
I wonder if the next request will be for print() to know what your output
device is and other current settings so it return the width your text takes
up in pixels in the current font/size ...
I add a tidbit that many ways of printing allow you to specify the width you
want something printed in such as you want a floating point value with so
many digits after the decimal point in a zero or space padded field on the
left. So there are ways to calculate in advance for many common cases as to
how long each part will be if you specify it. Besides, I am not really sure
if "print" even knows easily how many characters it is putting out as it
chews away on the many things in your request and calls dunder methods in
objects so they display themselves and so on. I assume it can be made to
keep track, albeit I can imagine printing out an APL program with lots of
overwritten characters where the number of bytes sent is way more than the
number of spaces in the output.
Why are we even still talking about this? The answer to the question of why
print() does not return anything, let alone the number of characters
printed, is BECAUSE.
-Original Message-
From: Python-list On
Behalf Of Python
Sent: Friday, February 10, 2023 4:56 PM
To: python-list@python.org
Subject: Re: evaluation question
On Sat, Feb 11, 2023 at 08:30:22AM +1100, Chris Angelico wrote:
> On Sat, 11 Feb 2023 at 07:36, Python 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 would agree with this only partially. Your case applies to os.write(),
which is essentially just a wrapper around the write() system call, which
has that sort of property... though it applies also to I/O in blocking mode,
particularly on network sockets, where the number of bytes you asked to
write (or read) may not all have been transferred, necessitating trying in a
loop.
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.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Sat, 11 Feb 2023 at 10:07, Thomas Passin wrote: > > 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. It's sometimes possible to have that go to stdout (maybe you want to do columnar text or something), but yeah, you'll generally do that by formatting first, then doing the measurement, then displaying. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
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. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Sat, Feb 11, 2023 at 08:30:22AM +1100, Chris Angelico wrote:
> On Sat, 11 Feb 2023 at 07:36, Python 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 would agree with this only partially. Your case applies to
os.write(), which is essentially just a wrapper around the write()
system call, which has that sort of property... though it applies also
to I/O in blocking mode, particularly on network sockets, where the
number of bytes you asked to write (or read) may not all have been
transferred, necessitating trying in a loop.
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.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Sat, 11 Feb 2023 at 07:36, Python wrote:
> 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)
> ...
>
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.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Am I banned from Discuss forum?
I was banned from the mailing list and Discuss forum for a very long time. Too much IMHO, but I paid my dues. Now this is my state in the forum: - I never posted something unrespectful in the last months - I have a limitation of three posts per threads, but only on some threads - Some random posts of mine are obscured and must be restored manually by moderators - I opened a thread about the proposal of a new section called Brainstorming. It was closed without a reason. - I can't post links - Two discussions I posted in section Idea were moved to Help, without a single line of explanation. If I'm not appreciated, I want to be publicly banned with a good reason, or at least a reason. -- https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question
On Mon, Jan 30, 2023 at 09:41:03AM -, mutt...@dastardlyhq.com wrote:
> >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?
Python is far from the only language that allows functions to return
nothing explicit. Statically typed languages typically use the void
keyword or something similar to indicate this, and dynamically typed
languages often just don't explicitly return anything. [Some
languages, like Perl, just implicitly return the value of the last
expression, or something of the sort, but some do not.] In Pascal, in
fact, there are two different types of subroutines to distinguish
between those things: functions return a value, and procedures do not.
Modern languages commonly don't provide this distinction because by
and large it is unnecessary.
Typically the reason NOT to return a value is that the function is
designed to DO something, rather than to calculate some value.
Examples might be updating the appearance of a UI widget, printing
some information to the screen, or twiddling some bits in a register
(i.e. in-place update of a value). They don't need to return anything
because the "output" is whatever was done. In some languages it might
be typical to return a status indicating success or failure, but in
many languages this is unnecessary; status may be returned via a
parameter provided for the purpose, or in many languages, success can
be assumed, whereas failure will raise an exception.
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)
...
--
https://mail.python.org/mailman/listinfo/python-list
