Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)
print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s
name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None
type.')
print('Is there anybody out there?!')

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/12/2022 05:45, Goran Ikac wrote:

b = a.append(3)

I mean: why b = a.append(something) is the None type, and how to make a new list that contains all the items from a and some new items?

append() like many other collection methods in Python works
in place and returns None. But the action has succeeded
and 3 will have been appended to list 'a'.

So, to create a new list that contains all the old items you could do:

newlist = [] # an empty list
for item in oldlist:
newlist.append(item)

This is so common Python has a shorthand form to do this:

newlist = [item for item in oldlist]

called a list comprehension.

And there is an even shorter way using something called slicing:

newlist = oldlist[:] # copy oldlist to new.


However, as an ex-Smalltalk programmer, I do wish that Python
returned self from these methods rather than None so that
we could chain them. But sadly it doesn't.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/12/2022 18.45, Goran Ikac wrote:

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)

print("b ==", b)
print("type(b) is", type(b))

Please review https://docs.python.org/3/tutorial/datastructures.html

It is not immediately obvious to people who are not used to
object-oriented programming.

As observed, "a" is a list. The list contains a pair of numeric-values.

The append is a "method". Methods are functions which belong to classes
(let's say). Accordingly, the operation is performed on that class, ie
the appending is to the "a" list.

This can be proven by adding to the above:

print( "\na (appended) =", a )
[1, 2, 3]

As far as the expression on the right-hand side of (the equals sign)
there is no output-value, hence b == None.


For comparison, try:

b = a + [ 4 ]

and understand why the answer is different, and thus why the first
'problem' behavior works the way it does...


print( 'Happy new year!' )


PS are you aware of the Python-Tutor Discussion List? It may be more
suited to assisting your learning intentions...
--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Goran Ikac <goranikac65@gmail.com> writes:

A few days (weeks?) ago,

Programming, time passes quickly, one does not notice how
days become weeks, suddenly life's over!

I mean: why b = a.append(something) is the None type,

An assignment statement has no value. When the call
expression "a.append(something)" has a value, it's not
NoneType, but None. This is so because the designer of
the "append" method made this decision. But you can,

import collections

class custom_list_class( collections.UserList ):
def append( self, *args, **kwargs ):
super().append( *args, **kwargs )
return self

a = custom_list_class( [ 1, 2 ])

print( f'{a.append( 3 )= }' )

.

how to make a new list that contains all the items from a
and some new items?

Get a recent copy of "The Python Library Reference"
(I prefer the PDF file.), and check out "4.6 Sequence
Types - list, tuple, range".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just use the addition operator:

a = [1,2]

a = a + [3,4]

a is now [1, 2, 3, 4]

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Goran Ikac <goranikac65@gmail.com>
Date: Saturday, December 31, 2022 at 1:53 AM
To: python-list@python.org <python-list@python.org>
Subject: NoneType List
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)
print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s
name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None
type.')
print('Is there anybody out there?!')
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mv_VSTDWgnB7T16IHcBh7TaT3whji-SsPeUtaBmHdSsIJknJZ16qeALOSjCkjCmqheE1pJ-47P_mwAauV-0TjQo$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/
python-list__;!!Cn_UX_p3!mv_VSTDWgnB7T16IHcBh7TaT3whji-SsPeUtaBmHdSsIJknJZ16qeALOSjCkjCmqheE1pJ-47P_mwAauV-0TjQo$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)
print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s
name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None
type.')
print('Is there anybody out there?!')
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/12/22 16:45, Goran Ikac wrote:

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)

append is not used that way, append is a method, not a function.

have a look at https://www.w3schools.com/python/ref_list_append.asp.

regards, Chris

print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None type.')
print('Is there anybody out there?!')

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-12-31 05:45, Goran Ikac wrote:

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)
print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None type.')
print('Is there anybody out there?!')

Methods that modify in-place usually return None. "a.append(something)" modifies (appends to) the list 'a' and returns None.

If you want to a new line with something at the end try "b = a +
[something]".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oops, my reply got lost somehow. Here it is:

Everyone's answer to date has been too complicated. What is going on is
that list.append() changes the list in place. It returns nothing. If
you want to append an item and then assign the result to a new list, you
have to do just that:

l1.append(item)
# If we want a *copy* of the appended list:
l2 = l1[:] # Changes to l2 will not change l1

# If we want another name for the appended list:
l2 = l1 # Changes to l2 will change l1 since they are the same object

list.sort() also operates in place. There is a function sorted() that
returns the sorted list (without changing the original list).

The same thing is true of set.add(). The set is changed in place, and
nothing is returned.

On 12/31/2022 10:50 AM, Thomas Passin wrote:

Happy New Year, everybody!
I'm new in the Python List, new in Python world, and new in coding.
A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.
In the meantime, I found a part of the solution, but a part still remains a mystery for me. Please run this small snippet, and help.
Thanks

a = [1, 2]
print()

print("a ==", a)
print("type(a) is", type(a))

b = a.append(3)
print("\nb =", "a.append(3)")
print("b ==", b)
print("type(b) is", type(b))

c = ['1', '2']
print("\nc ==", c)
print("type(c) is", type(c))

d = c.append('3')
print("\nd =", "c.append('3')")
print("d ==", d)
print("type(d) is", type(d))

"""
I mean: why b = a.append(something) is the None type, and how to make a new list
that contains all the items from a and some new items?
I wasn't able to solve it in a few hours :(
Now I know:
"""

crta = '='
print('\n', 4 * ' ', crta * (len('The solution:')), sep='')
print(3 * ' ', 'The solution:')
print(4 * ' ', crta * (len('The solution:')), sep='')
print('\nThe solution is the slice, an element of Python syntax that
allows')
print('to make a brand new copy of a list, or parts of a list.')
print('The slice actually copies the list\'s contents, not the list\'s name:')

print()
a = [1, 2]
print("a ==", a)
print("type(a) is", type(a))

b = a[:]
print("\nb = a[:]")
print("b ==", b)
b.append(3)
print("\nb =", "b.append(3)")
print("b ==", b)
print("type(b) is", type(b))
print("\na ==", a)

print('But I still don't know why "b = a.append(something)" is the None type.')
print('Is there anybody out there?!')

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/12/2022 18.45, Goran Ikac wrote:
...

A few days (weeks?) ago, I faced a problem trying to write a program for an exercise. I asked for help and nobody answered.

Looking back over the last six months of List-Archives, your name does
not appear against a single post. This may explain why "nobody answered".

However, ten hours after the above/first message, you posted again. This
time as "Thomas Passin". That was followed an hour-or-so later, with a reply-to-self saying: "Everyone's answer to date has been too
complicated", and then basically repeating the information
previously-provided by a number of contributors.

It then goes on to talk about copying, sorting, adding, and even sets.
Much of which you had earlier said: "I know". Was there a further
question in there?

Which part of which answer did you find "too complicated"?

Did you try the experiments suggested, and read the references-provided?

Please ask a further question detailing what you have understood, and
what is still mystifying. Folk here endeavor to be helpful (see also,
earlier reference to the Python-Tutor list).

When asking a question here, please try to reduce the problem to its
simplest form, so that you're not asking volunteers to read
multiple-screens of irrelevant code. It will help to ask one question at
a time, or to carefully separate multiple questions.

Yes, this can be difficult when one is learning. That said, we all
started somewhere and are happy to help you to become a valued colleague!

--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It depends on what people consider too complicated.

I find it a tad complicated when someone posts using two different ID, and
then wonders ...

The question related to taking a list and extending it and using the result
in an assignment statement.

There were several inter-related questions people responded to.

One was asking why something did not work as expected. Several answers
pointed out it was because it was not designed the way expected and reading
the manual page or other reference material would help explain that you need
to use code the way it was intended and not as you wish it. Other aspects of similar code that do what you expect were shown and you could pick any you liked.

A second question some were answering is various ways to get the
functionality wanted. Some were simple enough like using "+" and others did seem complex as they showed many variations on copying an object or how to
make a subclass that effectively substitutes a method that returns the internally changed object.

And, of course, we had the philosophical question of why the feature was designed to not return anything (well, NULL) rather than return the changed object. Returning nothing is arguably slightly more efficient in the many
cases where the return value is simply ignored and thus tossed. But as mentioned, it would be nice for some purposes, including chaining, to be
able to write something like

result = lst.add_ret("item").sort_ret()

As mentioned, this can still be easily done using something like:

result = sorted(lst + "item")

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of dn
Sent: Saturday, December 31, 2022 3:59 PM
To: python-list@python.org
Subject: Re: NoneType List

On 31/12/2022 18.45, Goran Ikac wrote:
...

A few days (weeks?) ago, I faced a problem trying to write a program
for an exercise. I asked for help and nobody answered.

Looking back over the last six months of List-Archives, your name does not appear against a single post. This may explain why "nobody answered".

However, ten hours after the above/first message, you posted again. This
time as "Thomas Passin". That was followed an hour-or-so later, with a reply-to-self saying: "Everyone's answer to date has been too complicated",
and then basically repeating the information previously-provided by a number
of contributors.

It then goes on to talk about copying, sorting, adding, and even sets.
Much of which you had earlier said: "I know". Was there a further question
in there?

Which part of which answer did you find "too complicated"?

Did you try the experiments suggested, and read the references-provided?

Please ask a further question detailing what you have understood, and what
is still mystifying. Folk here endeavor to be helpful (see also, earlier reference to the Python-Tutor list).

When asking a question here, please try to reduce the problem to its
simplest form, so that you're not asking volunteers to read multiple-screens
of irrelevant code. It will help to ask one question at a time, or to
carefully separate multiple questions.

Yes, this can be difficult when one is learning. That said, we all started somewhere and are happy to help you to become a valued colleague!

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/31/2022 3:58 PM, dn wrote:

On 31/12/2022 18.45, Goran Ikac wrote:
...

A few days (weeks?) ago, I faced a problem trying to write a program
for an
exercise. I asked for help and nobody answered.

Looking back over the last six months of List-Archives, your name does
not appear against a single post. This may explain why "nobody answered".

However, ten hours after the above/first message, you posted again. This
time as "Thomas Passin".

That message was probably a mistaken one from me. I had composed a
reply but through some mental glitch had to re-do it. I managed to send
it with the only quoted thread but not the reply I had wanted to
include. So I added my reply and sent it again. It was probably
confusing, and I'm sorry about that.

That was followed an hour-or-so later, with a
reply-to-self saying: "Everyone's answer to date has been too
complicated", and then basically repeating the information previously-provided by a number of contributors.

It then goes on to talk about copying, sorting, adding, and even sets.
Much of which you had earlier said: "I know". Was there a further
question in there?

Which part of which answer did you find "too complicated"?

Did you try the experiments suggested, and read the references-provided?

Please ask a further question detailing what you have understood, and
what is still mystifying. Folk here endeavor to be helpful (see also,
earlier reference to the Python-Tutor list).

When asking a question here, please try to reduce the problem to its
simplest form, so that you're not asking volunteers to read
multiple-screens of irrelevant code. It will help to ask one question at
a time, or to carefully separate multiple questions.

Yes, this can be difficult when one is learning. That said, we all
started somewhere and are happy to help you to become a valued colleague!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/01/23 11:36 am, avi.e.gross@gmail.com wrote:

And, of course, we had the philosophical question of why the feature was designed to not return anything ... rather than return the changed
object.

My understanding is that Guido designed it that way to keep a
clear separation between mutating and non-mutating methods, and
to help catch mistakes resulting from mixing them up.

--
Greg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Agreed, there are lots of pro/con arguments and the feature is what it is historically and not trivial to change. Inline changes to an object make
sense to just be done "silently" and if there are errors, they propagate the usual way.

As Guido was a major influence at that time, one view was seen as more important and prevailed.

Had a language like that been created today, I wonder if some designs might have looked a bit different so that some functions could be called with optional arguments that specified what the user wanted returned.

In particular, besides a function where you add a value returning
nothing/None, there may be room for other choices and any choice hard-wired
in would eleicit complaints from others.

lst.add("Value")

could also return one of several other things such as a pointer to the
upgraded object but also of a pointer to the object as it looked before the change (not a serious proposal) or a True/False value specifying if the
change was able to be completed (such as running out of memory, or the
addition not being something you can put in the object) or even return what
was added or how many objects are now in the object at the top level, or how many times the method was called so far!

I suspect, at the expense of some overhead, you could just add an argument
to many kinds of methods or even functions such as returning='option' that guides what you want returned, with the default often being what Guido and others currently have set.

Python already allows functions to return anything they feel like, so this probably would not break many things.

Of course there are other paths in that direction, such as setting an
attribute of the list/object first that affects how things get returned but that seems more cumbersome and makes all kinds of errors more likely. Still, that is a path often used by some Python modules where objects are created
and then tweaked to behave in various ways when later methods are invoked.

But is any of it needed? The current system generally works fine and we have seen many ways to get other results without tampering with the current implementation.

This may be yet another example of people who come to python with
pre-existing bias, such as insisting it work like another language they have used, or wanting the computer to do what they MEANT rather than what they explicitly or implicitly programmed!


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Greg Ewing
Sent: Saturday, December 31, 2022 7:21 PM
To: python-list@python.org
Subject: Re: NoneType List

On 1/01/23 11:36 am, avi.e.gross@gmail.com wrote:

And, of course, we had the philosophical question of why the feature
was designed to not return anything ... rather than return the changed object.

My understanding is that Guido designed it that way to keep a clear
separation between mutating and non-mutating methods, and to help catch mistakes resulting from mixing them up.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 1 Jan 2023 at 14:19, <avi.e.gross@gmail.com> wrote:

Had a language like that been created today, I wonder if some designs might have looked a bit different so that some functions could be called with optional arguments that specified what the user wanted returned.

Frankly, I doubt it. While you can argue "returning self is more
useful" vs "returning None is more clear if you get it wrong", having
options does NOT improve things, and just makes everything more
complicated, slower, harder to comprehend, and generally worse to work
with.

A language should have some sort of consistent behaviour and stick to
it. If that's not possible, an object type should at least have that.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris,

There is much to say about consistent behavior as compared to flexibility
and convenience.

I have seen other languages provide functions for example, where the result can vary and often cause confusion. R had a function that would sometimes notice the result could be simplified and return that. Guess what? It caused lots of problems and an option was added that said it should NOT simplify
and always return the same kind of thing.

Consider what happens if a calculation that returned a matrix would decide
that is there was only one columns, it would return a vector/array/whatever
as a one-dimensional result and if the calculation produced a 1 by 1 matrix,
it would simply return a scalar value!

But it may be a feature you want in some cases, albeit rarely when the
results of the function are fed into something that is not expecting it. Various forms of polymorphism can be helpful but can also be very confusing.

Some solutions are what I have described in earlier messages and some
languages blur distinctions. Again, in R, there may not be a scalar as all
you have is a vector of length one. But matrices even of 1-D are not vectors and I have had to interconvert between them to make some code run.

I am not making comparisons in the sense that nothing other languages choose
to do is binding on what Python should do. Still, I think it is wrong to suggest that it does not often do partially ambiguous things from some perspective. Many functions will take a variety of arguments and return something reasonable but different each time.

As a dumb example, what does a simple function like max() return if fed just integers, just floating point or a combination of both? It seems to return whatever type the maximum indicates. But it also accepts characters and
sorts them appropriately returning type 'str' and probably accepts and
returns all kinds of objects if you specify a key function.

Is that so much different than we are discussing in that there isn't any absolute consistency and things can go various ways in terms of return
value? Heck, I can even make max() return None!


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Chris Angelico
Sent: Saturday, December 31, 2022 10:23 PM
To: python-list@python.org
Subject: Re: NoneType List

On Sun, 1 Jan 2023 at 14:19, <avi.e.gross@gmail.com> wrote:

Had a language like that been created today, I wonder if some designs
might have looked a bit different so that some functions could be
called with optional arguments that specified what the user wanted

returned.

Frankly, I doubt it. While you can argue "returning self is more useful" vs "returning None is more clear if you get it wrong", having options does NOT improve things, and just makes everything more complicated, slower, harder
to comprehend, and generally worse to work with.

A language should have some sort of consistent behaviour and stick to it. If that's not possible, an object type should at least have that.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 1 Jan 2023 at 15:16, <avi.e.gross@gmail.com> wrote:

Chris,

There is much to say about consistent behavior as compared to flexibility
and convenience.

I have seen other languages provide functions for example, where the result can vary and often cause confusion. R had a function that would sometimes notice the result could be simplified and return that. Guess what? It caused lots of problems and an option was added that said it should NOT simplify
and always return the same kind of thing.

The option was presumably added because backward compatibility is
important, but it would have been better to not need the option in the
first place.

As a dumb example, what does a simple function like max() return if fed just integers, just floating point or a combination of both? It seems to return whatever type the maximum indicates. But it also accepts characters and
sorts them appropriately returning type 'str' and probably accepts and returns all kinds of objects if you specify a key function.

Is that so much different than we are discussing in that there isn't any absolute consistency and things can go various ways in terms of return
value? Heck, I can even make max() return None!

... yes? So? It still always returns the largest item in the list, for
some definition of "largest". You'll never have that value returned
wrapped up in a single-element list, though.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and prototyping >language.

In those days, there used to be a language called "Pascal".
Pascal had a dichotomy between "functions" and "procedures".
A call to a function was intended to have a value.
A call to a procedure was intended to have an effect.

For some beginners, the difference between a value and
and effect can be hard to grasp. So, Pascal's distinction
helps to hammer that home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles
to understand the difference between values and effects
usually is significantly shorter than the later time
where he has understood it and is programming productively,
so it might be better when the language is adapted to
people who already have understood the difference.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/31/2022 10:17 PM, avi.e.gross@gmail.com wrote:

Agreed, there are lots of pro/con arguments and the feature is what it is historically and not trivial to change. Inline changes to an object make sense to just be done "silently" and if there are errors, they propagate the usual way.

As Guido was a major influence at that time, one view was seen as more important and prevailed.

Had a language like that been created today, I wonder if some designs might have looked a bit different so that some functions could be called with optional arguments that specified what the user wanted returned.

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and prototyping language. Guido probably had a good sense of what things worked well
and what didn't in that usage. IIRC, Python did not originally have
classes or instances, and a "fluent" style of programming probably
wasn't in use yet. Having an object return itself after an operation is
useful (mostly, perhaps) for fluent programming (that is, the style
where one can write X.method1().method2().method3() ...).

In particular, besides a function where you add a value returning nothing/None, there may be room for other choices and any choice hard-wired in would eleicit complaints from others.

lst.add("Value")

could also return one of several other things such as a pointer to the upgraded object but also of a pointer to the object as it looked before the change (not a serious proposal) or a True/False value specifying if the change was able to be completed (such as running out of memory, or the addition not being something you can put in the object) or even return what was added or how many objects are now in the object at the top level, or how many times the method was called so far!

I suspect, at the expense of some overhead, you could just add an argument
to many kinds of methods or even functions such as returning='option' that guides what you want returned, with the default often being what Guido and others currently have set.

Python already allows functions to return anything they feel like, so this probably would not break many things.

Of course there are other paths in that direction, such as setting an attribute of the list/object first that affects how things get returned but that seems more cumbersome and makes all kinds of errors more likely. Still, that is a path often used by some Python modules where objects are created and then tweaked to behave in various ways when later methods are invoked.

But is any of it needed? The current system generally works fine and we have seen many ways to get other results without tampering with the current implementation.

This may be yet another example of people who come to python with pre-existing bias, such as insisting it work like another language they have used, or wanting the computer to do what they MEANT rather than what they explicitly or implicitly programmed!

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Greg Ewing
Sent: Saturday, December 31, 2022 7:21 PM
To: python-list@python.org
Subject: Re: NoneType List

On 1/01/23 11:36 am, avi.e.gross@gmail.com wrote:

And, of course, we had the philosophical question of why the feature
was designed to not return anything ... rather than return the changed
object.

My understanding is that Guido designed it that way to keep a clear separation between mutating and non-mutating methods, and to help catch mistakes resulting from mixing them up.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/2023 8:47 AM, Stefan Ram wrote:

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and prototyping
language.

In those days, there used to be a language called "Pascal".
Pascal had a dichotomy between "functions" and "procedures".
A call to a function was intended to have a value.
A call to a procedure was intended to have an effect.

Wirth developed Pascal as a teaching language. IIRC, originally it was
taught to students before there were any implementations. I did most of
my programming with Turbo Pascal for many years. Just to clarify what
you wrote above, in Pascal a "procedure" does not return anything while
a "function" does.

I really liked (Turbo) Pascal and I hated C back then. No wonder I like
Python so much. It must be something about how my mind works.

For some beginners, the difference between a value and
and effect can be hard to grasp. So, Pascal's distinction
helps to hammer that home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles
to understand the difference between values and effects
usually is significantly shorter than the later time
where he has understood it and is programming productively,
so it might be better when the language is adapted to
people who already have understood the difference.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you, guys, thank you very much!
I'm amazed by the time and effort so many of you have put into the answers.
And at this time of year!
Not only is the issue clear to me now, but I learned a lot (and I'm still
to learn a lot more) from your answers and the links you provided. And not
only about the issue that bothered me when I wrote the question!
I've read many times that one of the main features of Python was the large community ready to help and discuss. Well, I'm just beginning to see the
true meaning of that, and I'm - well - amazed.
Thanks, guys, and Happy New Year!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Several of you have mentioned the role of history in the development of languages and what the founders of a language were trying to improve.

As noted with PASCAL, some earlier languages strived to be different things
and in a certain sense, their procedures were perhaps seen as a safer and better way to do things that languages like BASIC hade done with a GOSUB. On top of that, there were concerns in a compiled language such as not leaving
an unused result on the stack when a function returned and even efficiency considerations of several kinds. If a function returns a value, that value
has to persist beyond the lifetime of the function. It has to be in a kind
of memory different than where you can store values that go away. In a procedure call, the compiler could use the fact that nothing is returned
other than through external variables.

As noted, Guido started various languages, including Python, in a historical context where he was not yet seeing things as "objects" in the way we often
do now. And he was trying to avoid some features often used in languages
like C for various reasons while keeping or extending others. I am not sure about timing, but there have been many debates in the field about things
like programming without side effects and some insist that changing things
IN PLACE is a poor way to do things and instead things should be copied when modified and so on.

So it well may be that allowing an inline sort or addition to a list was
added carefully in a way that made it very clear what you were doing and
seeing it more as a procedure call than a function that returned a value of itself as Stefan points out.

But Python evolved and keeps evolving and like many biological organisms, to some extent, ontogeny recapitulates phylogeny. It is really hard to get rid
of some early design choices even when a brand new design might allow a
cleaner design with more advantages. Python is becoming more like other languages as it borrows from them and they borrow from it, and all borrow or adapt from yet others. The result, frankly, can be a tad hard to understand
as the languages both converge and diverge only to converge again and some simply go extinct or get totally re-done to adapt ...

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Stefan Ram
Sent: Sunday, January 1, 2023 8:47 AM
To: python-list@python.org
Subject: Re: NoneType List

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal".
Pascal had a dichotomy between "functions" and "procedures".
A call to a function was intended to have a value.
A call to a procedure was intended to have an effect.

For some beginners, the difference between a value and
and effect can be hard to grasp. So, Pascal's distinction
helps to hammer that home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles
to understand the difference between values and effects
usually is significantly shorter than the later time
where he has understood it and is programming productively,
so it might be better when the language is adapted to
people who already have understood the difference.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you, guys, thank you very much!
I'm amazed by the time and effort so many of you have put into the answers.
And at this time of year!
Not only is the issue clear to me now, but I learned a lot (and I'm still
to learn a lot more) from your answers and the links you provided. And not
only about the issue that bothered me when I wrote the question!
I've read many times that one of the main features of Python was the large community ready to help and discuss. Well, I'm just beginning to see the
true meaning of that, and I'm - well - amazed.
Thanks, guys, and Happy New Year!

ned, 1. sij 2023. u 19:17 <avi.e.gross@gmail.com> napisao je:

Several of you have mentioned the role of history in the development of languages and what the founders of a language were trying to improve.

As noted with PASCAL, some earlier languages strived to be different things and in a certain sense, their procedures were perhaps seen as a safer and better way to do things that languages like BASIC hade done with a GOSUB.
On
top of that, there were concerns in a compiled language such as not leaving an unused result on the stack when a function returned and even efficiency considerations of several kinds. If a function returns a value, that value has to persist beyond the lifetime of the function. It has to be in a kind
of memory different than where you can store values that go away. In a procedure call, the compiler could use the fact that nothing is returned other than through external variables.

As noted, Guido started various languages, including Python, in a
historical
context where he was not yet seeing things as "objects" in the way we often do now. And he was trying to avoid some features often used in languages
like C for various reasons while keeping or extending others. I am not sure about timing, but there have been many debates in the field about things
like programming without side effects and some insist that changing things
IN PLACE is a poor way to do things and instead things should be copied
when
modified and so on.

So it well may be that allowing an inline sort or addition to a list was added carefully in a way that made it very clear what you were doing and seeing it more as a procedure call than a function that returned a value of itself as Stefan points out.

But Python evolved and keeps evolving and like many biological organisms,
to
some extent, ontogeny recapitulates phylogeny. It is really hard to get rid of some early design choices even when a brand new design might allow a cleaner design with more advantages. Python is becoming more like other languages as it borrows from them and they borrow from it, and all borrow
or
adapt from yet others. The result, frankly, can be a tad hard to understand as the languages both converge and diverge only to converge again and some simply go extinct or get totally re-done to adapt ...

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org>
On
Behalf Of Stefan Ram
Sent: Sunday, January 1, 2023 8:47 AM
To: python-list@python.org
Subject: Re: NoneType List

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he >developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal".
Pascal had a dichotomy between "functions" and "procedures".
A call to a function was intended to have a value.
A call to a procedure was intended to have an effect.

For some beginners, the difference between a value and
and effect can be hard to grasp. So, Pascal's distinction
helps to hammer that home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles
to understand the difference between values and effects
usually is significantly shorter than the later time
where he has understood it and is programming productively,
so it might be better when the language is adapted to
people who already have understood the difference.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas,

I used PASCAL before C and I felt like I was wearing a straitjacket at times
in PASCAL when I was trying to write encryption/decryption functions and had
to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

The distinction between teaching a first language, or one that is so
cautious as to catch and prevent all mistakes it can, is not for people
willing to be bolder or work faster or write routines that can be used more generally.

What has not been mentioned is that languages like python go a step further
and allow a function to return many arguments and even a varying number of arguments, as well as none at all. To do anything like that in PASCAL took
some thought on how to make some structure you could fill out then return as
a single value that the receiving code had to sort of decode and perhaps
deal with parts that could hold a union of several things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like:

(res1, res2, _, res4, _, rest) = f(x)

The above tells the interpreter you expect perhaps 6 or more results and
what to do with them.



-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Thomas Passin
Sent: Sunday, January 1, 2023 1:03 PM
To: python-list@python.org
Subject: Re: NoneType List

On 1/1/2023 8:47 AM, Stefan Ram wrote:

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal".
Pascal had a dichotomy between "functions" and "procedures".
A call to a function was intended to have a value.
A call to a procedure was intended to have an effect.

Wirth developed Pascal as a teaching language. IIRC, originally it was
taught to students before there were any implementations. I did most of my programming with Turbo Pascal for many years. Just to clarify what you
wrote above, in Pascal a "procedure" does not return anything while a "function" does.

I really liked (Turbo) Pascal and I hated C back then. No wonder I like
Python so much. It must be something about how my mind works.

For some beginners, the difference between a value and
and effect can be hard to grasp. So, Pascal's distinction
helps to hammer that home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles
to understand the difference between values and effects
usually is significantly shorter than the later time
where he has understood it and is programming productively,
so it might be better when the language is adapted to
people who already have understood the difference.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/2023 9:14 PM, avi.e.gross@gmail.com wrote:

Thomas,

I used PASCAL before C and I felt like I was wearing a straitjacket
at times in PASCAL when I was trying to write encryption/decryption
functions and had to find ways to fiddle with bits. Similar things
were easy in C, and are even easier in many more recent languages
such as Python.

PASCAL was not the first language I learned. I won't pretend I had to
do anything very complicated, or do much bit-twiddling. It was, though,
the first one (except probably for FORTH) I enjoyed programming with
more than I disliked the boiler-plate formalities.

The distinction between teaching a first language, or one that is so
cautious as to catch and prevent all mistakes it can, is not for
people willing to be bolder or work faster or write routines that can
be used more generally.

What has not been mentioned is that languages like python go a step
further and allow a function to return many arguments and even a
varying number of arguments, as well as none at all. To do anything
like that in PASCAL

(or C, for that matter)

took some thought on how to make some structure you could fill out
then return as a single value that the receiving code had to sort of
decode and perhaps deal with parts that could hold a union of several
things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like:

(res1, res2, _, res4, _, rest) = f(x)

Yes, that's one of the good things about Python, how it makes working
with tuples so easy and natural. OTOH, harking back to PASCAL for a
minute, it had enumerations and sets long before Python got them.

The above tells the interpreter you expect perhaps 6 or more results
and what to do with them.

-----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of
Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: python-list@python.org Subject: Re: NoneType List

On 1/1/2023 8:47 AM, Stefan Ram wrote:

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before
he developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal". Pascal
had a dichotomy between "functions" and "procedures". A call to a
function was intended to have a value. A call to a procedure was
intended to have an effect.

Wirth developed Pascal as a teaching language. IIRC, originally it
was taught to students before there were any implementations. I did
most of my programming with Turbo Pascal for many years. Just to
clarify what you wrote above, in Pascal a "procedure" does not return anything while a "function" does.

I really liked (Turbo) Pascal and I hated C back then. No wonder I
like Python so much. It must be something about how my mind works.

For some beginners, the difference between a value and and effect
can be hard to grasp. So, Pascal's distinction helps to hammer that
home.

Experienced programmers know the difference and do no longer
require the effort of the language to teach it to them.

The time when someone is a beginner and still struggles to
understand the difference between values and effects usually is
significantly shorter than the later time where he has understood
it and is programming productively, so it might be better when the
language is adapted to people who already have understood the
difference.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Not to wax poetic about our pasts, Thomas, but I do did not start with
PASCAL and used quite a few languages before and plenty after. At the time
it had interesting contrasts to languages like BASIC, FORTRAN and LISP and I tended to use whatever was available on the machines I was using. My first computer job (other than in grad school itself) was using OMSI PASCAL. I
even wrote my thesis as a PASCAL program containing comments that included typesetting instructions in a language called RUNOFF while the PASCAL
program itself was a set of comments as far as RUNOFF was concerned. So it compiled or was typeset and printed from the same source.

But my next job after graduation was for Bell Labs and I had to forget all
the mainframe or DEC systems and adapt to UNIX, and of course C and later
C++ and the various other little languages that came with that such as AWK
and PERL ...

There is no one right language but there often is a small set of right languages given your circumstances, such as what your employer has everyone using and especially in group projects.

To be fair, languages like Python and R seem to keep having parts rewritten
in C or C++ to make some things run faster and can include libraries written ages ago in languages like FORTRAN that have been finely tuned. Under the
hood, these languages often hide parts so that developing a new python (or R
or ...) module/package can start by writing it all in that language and then taking some functionality and rewriting it in the other language for
critical regions where a slower interpreted method may be speeded up.

But for prototyping, or when speed is not a big deal, I really prefer Python
to ...


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Thomas Passin
Sent: Sunday, January 1, 2023 10:15 PM
To: python-list@python.org
Subject: Re: NoneType List

On 1/1/2023 9:14 PM, avi.e.gross@gmail.com wrote:

Thomas,

I used PASCAL before C and I felt like I was wearing a straitjacket at
times in PASCAL when I was trying to write encryption/decryption
functions and had to find ways to fiddle with bits. Similar things
were easy in C, and are even easier in many more recent languages such
as Python.

PASCAL was not the first language I learned. I won't pretend I had to do anything very complicated, or do much bit-twiddling. It was, though, the
first one (except probably for FORTH) I enjoyed programming with more than I disliked the boiler-plate formalities.

The distinction between teaching a first language, or one that is so
cautious as to catch and prevent all mistakes it can, is not for
people willing to be bolder or work faster or write routines that can
be used more generally.

What has not been mentioned is that languages like python go a step
further and allow a function to return many arguments and even a
varying number of arguments, as well as none at all. To do anything
like that in PASCAL

(or C, for that matter)

took some thought on how to make some structure you could fill out
then return as a single value that the receiving code had to sort of
decode and perhaps deal with parts that could hold a union of several
things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like:

(res1, res2, _, res4, _, rest) = f(x)

Yes, that's one of the good things about Python, how it makes working with tuples so easy and natural. OTOH, harking back to PASCAL for a minute, it
had enumerations and sets long before Python got them.

The above tells the interpreter you expect perhaps 6 or more results
and what to do with them.

-----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of
Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: python-list@python.org Subject: Re: NoneType List

On 1/1/2023 8:47 AM, Stefan Ram wrote:

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal". Pascal
had a dichotomy between "functions" and "procedures". A call to a
function was intended to have a value. A call to a procedure was
intended to have an effect.

Wirth developed Pascal as a teaching language. IIRC, originally it was
taught to students before there were any implementations. I did most
of my programming with Turbo Pascal for many years. Just to clarify
what you wrote above, in Pascal a "procedure" does not return anything
while a "function" does.

I really liked (Turbo) Pascal and I hated C back then. No wonder I
like Python so much. It must be something about how my mind works.

For some beginners, the difference between a value and and effect can
be hard to grasp. So, Pascal's distinction helps to hammer that home.

Experienced programmers know the difference and do no longer require
the effort of the language to teach it to them.

The time when someone is a beginner and still struggles to understand
the difference between values and effects usually is significantly
shorter than the later time where he has understood it and is
programming productively, so it might be better when the language is
adapted to people who already have understood the difference.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times in PASCAL when I was trying to write encryption/decryption functions and had to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal
which had extra functions and features for all those "real world" type
things. (And you could insert some inline assembler if all else failed)
It also relaxed the ludicrously strict typing slightly. Turbo Pascal
made Pascal a joy and I still use Delphi for Windows programming today.

TP also introduced classes to Pascal (although Apple had already done
so for the Mac and Borland basically ported the syntax to the PC).

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks a lot all for your suggestions, I am clear now.


On Mon, Jan 2, 2023 at 10:50 AM <avi.e.gross@gmail.com> wrote:

Not to wax poetic about our pasts, Thomas, but I do did not start with
PASCAL and used quite a few languages before and plenty after. At the time
it had interesting contrasts to languages like BASIC, FORTRAN and LISP and
I
tended to use whatever was available on the machines I was using. My first computer job (other than in grad school itself) was using OMSI PASCAL. I
even wrote my thesis as a PASCAL program containing comments that included typesetting instructions in a language called RUNOFF while the PASCAL
program itself was a set of comments as far as RUNOFF was concerned. So it compiled or was typeset and printed from the same source.

But my next job after graduation was for Bell Labs and I had to forget all the mainframe or DEC systems and adapt to UNIX, and of course C and later
C++ and the various other little languages that came with that such as AWK and PERL ...

There is no one right language but there often is a small set of right languages given your circumstances, such as what your employer has everyone using and especially in group projects.

To be fair, languages like Python and R seem to keep having parts rewritten in C or C++ to make some things run faster and can include libraries
written
ages ago in languages like FORTRAN that have been finely tuned. Under the hood, these languages often hide parts so that developing a new python (or
R
or ...) module/package can start by writing it all in that language and
then
taking some functionality and rewriting it in the other language for
critical regions where a slower interpreted method may be speeded up.

But for prototyping, or when speed is not a big deal, I really prefer
Python
to ...

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org>
On
Behalf Of Thomas Passin
Sent: Sunday, January 1, 2023 10:15 PM
To: python-list@python.org
Subject: Re: NoneType List

On 1/1/2023 9:14 PM, avi.e.gross@gmail.com wrote:

Thomas,

I used PASCAL before C and I felt like I was wearing a straitjacket at times in PASCAL when I was trying to write encryption/decryption
functions and had to find ways to fiddle with bits. Similar things
were easy in C, and are even easier in many more recent languages such
as Python.

PASCAL was not the first language I learned. I won't pretend I had to do anything very complicated, or do much bit-twiddling. It was, though, the first one (except probably for FORTH) I enjoyed programming with more than
I
disliked the boiler-plate formalities.

The distinction between teaching a first language, or one that is so cautious as to catch and prevent all mistakes it can, is not for
people willing to be bolder or work faster or write routines that can
be used more generally.

What has not been mentioned is that languages like python go a step
further and allow a function to return many arguments and even a
varying number of arguments, as well as none at all. To do anything
like that in PASCAL

(or C, for that matter)

took some thought on how to make some structure you could fill out
then return as a single value that the receiving code had to sort of
decode and perhaps deal with parts that could hold a union of several things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like:

(res1, res2, _, res4, _, rest) = f(x)

Yes, that's one of the good things about Python, how it makes working with tuples so easy and natural. OTOH, harking back to PASCAL for a minute, it had enumerations and sets long before Python got them.

The above tells the interpreter you expect perhaps 6 or more results
and what to do with them.

-----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of
Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: python-list@python.org Subject: Re: NoneType List

On 1/1/2023 8:47 AM, Stefan Ram wrote:

Thomas Passin <list1@tompassin.net> writes:

Guido had been working on the ABC language for some years before he
developed Python. ABC was intended mainly as a teaching and
prototyping language.

In those days, there used to be a language called "Pascal". Pascal
had a dichotomy between "functions" and "procedures". A call to a
function was intended to have a value. A call to a procedure was
intended to have an effect.

Wirth developed Pascal as a teaching language. IIRC, originally it was taught to students before there were any implementations. I did most
of my programming with Turbo Pascal for many years. Just to clarify
what you wrote above, in Pascal a "procedure" does not return anything while a "function" does.

I really liked (Turbo) Pascal and I hated C back then. No wonder I
like Python so much. It must be something about how my mind works.

For some beginners, the difference between a value and and effect can
be hard to grasp. So, Pascal's distinction helps to hammer that home.

Experienced programmers know the difference and do no longer require
the effort of the language to teach it to them.

The time when someone is a beginner and still struggles to understand
the difference between values and effects usually is significantly
shorter than the later time where he has understood it and is
programming productively, so it might be better when the language is
adapted to people who already have understood the difference.

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

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/2/2023 3:01 AM, Alan Gauld wrote:

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times >> in PASCAL when I was trying to write encryption/decryption functions and had >> to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal
which had extra functions and features for all those "real world" type things. (And you could insert some inline assembler if all else failed)
It also relaxed the ludicrously strict typing slightly. Turbo Pascal
made Pascal a joy and I still use Delphi for Windows programming today.

If Python weren't around, I might be doing that myself.

TP also introduced classes to Pascal (although Apple had already done
so for the Mac and Borland basically ported the syntax to the PC).

That was V5.5, wasn't it? Classes were a hugely useful extension to TP.
I used a version with classes (a later version that had a graphics
primitives module) to write a window manager (in DOS graphics mode, all
350 X 200 pixels of it).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan,

I stand corrected as my path never led me back to any form of PASCAL. And, frankly, my path rarely led me again to having to do what we describe as twiddling bits with the minor exception when doing something like setting the bits needed to specify what
permissions should be associated with a file in the UNIX world.

What you say is largely true of programming languages in general. Many are created with some paradigm in mind that sounds like an idea until it meets reality and compromises and adjustments are made.

When new languages follow that have the ability to gain from prior experience, they may indeed come up with a more nuanced paradigm. I have been studying JavaScript and Node.js lately, for no special reason, and see that as an example of sorts. The
former was largely created to run inside a browser and NOT do anything harmful to the user's machine. Lots of parts normally included in other programming languages such as Python were not only deliberately left out but the code often monitors some
things to make sure you do not try anything sneaky.

But the language took off and evolved and at some point seemed to people to be a good tool to use on their servers too, and especially since the two sides could exchange relatively live objects such as with JSON. The paradigm had to change as most such
programs written in what is now Node.js or other names, actually had to do things to the server including reading and writing files. So they had to add quite a bit and struggled at times to keep other parts of the languages similar as they evolved semi-
independently. In my opinion, it remains a futile work in progress.

Has Python managed the version 2 versus version 3 schism to the point where enough users have migrated their code and new users avoid version 2? Other languages have had to split when big enough changes were made.

-----Original Message-----
From: Alan Gauld <learn2program@gmail.com>
Sent: Monday, January 2, 2023 3:01 AM
To: avi.e.gross@gmail.com; python-list@python.org
Subject: Re: RE: NoneType List

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at
times in PASCAL when I was trying to write encryption/decryption
functions and had to find ways to fiddle with bits. Similar things
were easy in C, and are even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal which had extra functions and features for all those "real world" type things. (And you could insert some inline assembler if all else failed) It also relaxed the ludicrously strict
typing slightly. Turbo Pascal made Pascal a joy and I still use Delphi for Windows programming today.

TP also introduced classes to Pascal (although Apple had already done so for the Mac and Borland basically ported the syntax to the PC).

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-02, <avi.e.gross@gmail.com> <avi.e.gross@gmail.com> wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times in PASCAL when I was trying to write encryption/decryption functions and had to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

Yonks ago (early 80s), I used Pascal to write an RTOS kernel and call processing firmware for a cell-site radio running a 16-bit
microprocessor (Z8000). It worked great. However, that Pascal compiler
had a few extensions designed specifically to support embedded systems
use on bare metal -- things like specific length signed/unsigned
interger types (with binary operations), pointers to raw memory and configurable bounds-checking.

Even with wide use of those extensions it was easier to write code
that "worked the first time" than it was with C. This was in the early
80's, and C compilers didn't hold your hand as much as they do today.

--
Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-02, Alan Gauld <learn2program@gmail.com> wrote:

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times >> in PASCAL when I was trying to write encryption/decryption functions and had >> to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal
which had extra functions and features for all those "real world" type things. (And you could insert some inline assembler if all else failed)
It also relaxed the ludicrously strict typing slightly. Turbo Pascal
made Pascal a joy and I still use Delphi for Windows programming today.

TP also introduced classes to Pascal (although Apple had already done
so for the Mac and Borland basically ported the syntax to the PC).

TP was indeed a joy to work with. It made it trivial to do simple
graphics on an IBM-PC and it was FAST -- both to write in, to debug,
and in raw execution speed.

--
Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/2/2023 5:01 PM, Grant Edwards wrote:

On 2023-01-02, Alan Gauld <learn2program@gmail.com> wrote:

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times
in PASCAL when I was trying to write encryption/decryption functions and had
to find ways to fiddle with bits. Similar things were easy in C, and are >>> even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal
which had extra functions and features for all those "real world" type
things. (And you could insert some inline assembler if all else failed)
It also relaxed the ludicrously strict typing slightly. Turbo Pascal
made Pascal a joy and I still use Delphi for Windows programming today.

TP also introduced classes to Pascal (although Apple had already done
so for the Mac and Borland basically ported the syntax to the PC).

TP was indeed a joy to work with. It made it trivial to do simple
graphics on an IBM-PC and it was FAST -- both to write in, to debug,
and in raw execution speed.

FAST, yes, even with 256K memory and only floppy drives - my first PC (compatible) machine.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 02 Jan 2023 13:59:03 -0800 (PST), Grant Edwards wrote:

Yonks ago (early 80s), I used Pascal to write an RTOS kernel and call processing firmware for a cell-site radio running a 16-bit
microprocessor (Z8000). It worked great. However, that Pascal compiler
had a few extensions designed specifically to support embedded systems
use on bare metal -- things like specific length signed/unsigned
interger types (with binary operations), pointers to raw memory and configurable bounds-checking.

Around that time I had a source of income from writing extensions. My
client tended to hire engineers fro the University of Maine where Pascal
was the didactic language. Wirth's Pascal was characterized as a language
very good at telling secrets to itself. Controlling robotic arms,
gathering information from process controllers, and so forth wasn't on the menu.

As for Turbo Pascal, I had been using the BDS C subset on a CP/M system. I installed TP, did the requisite hello world, and I thought something was broken. I had to convince myself the compiler had spit out an executable
that fast and hadn't crashed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2 Jan 2023 at 08:01:23, Alan Gauld <learn2program@gmail.com> wrote:

On 02/01/2023 02:14, avi.e.gross@gmail.com wrote:

I used PASCAL before C and I felt like I was wearing a straitjacket at times >> in PASCAL when I was trying to write encryption/decryption functions and had >> to find ways to fiddle with bits. Similar things were easy in C, and are
even easier in many more recent languages such as Python.

That's true of pure Pascal. But Thomas was talking about Turbo Pascal
which had extra functions and features for all those "real world" type things. (And you could insert some inline assembler if all else failed)
It also relaxed the ludicrously strict typing slightly. Turbo Pascal
made Pascal a joy and I still use Delphi for Windows programming today.

TP also introduced classes to Pascal (although Apple had already done
so for the Mac and Borland basically ported the syntax to the PC).

For anyone who still likes Pascal there is Free Pascal, for almost
all platforms and actively supported.

https://www.freepascal.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)