Re: RE: How to read file content and send email on Debian Bullseye
For example, try to do whatever parts you know how to do and when some part fails or is missing, ask. You're right but first of all I wrote what I'd like to do and if Python could be the best choice about it! :) I might have replied to you directly if your email email address did not look like you want no SPAM, LOL! Ahaha! I think you know what is spam and what is a reply\answer to a post request so you can feel free to use also my email! :) The cron stuff is not really relevant and it seems your idea is to read a part or all of a log file, parse the lines in some way and find a line that either matches what you need or fail to find it. Either way you want to send an email out with an appropriate content. You got the point! Which part of that do you not know how to do in python? Have you done some reading or looking? Like what I wrote above I didn't know if Python can does what I need and if to use Python is a good way I'll start to study how to do it! :) In my past I used Python for Arduino programming or to do easy things, what I should do now is little more complex but I understood from years and years by the Python's powers you can do everything! LOL! :) Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: How to read file content and send email on Debian Bullseye
I have never used it, and I did see that wording in the man page, but it also showed putting all the info on the command line - from, to, subject, etc - so I thought it might be able to use a command line client without needed any GUI interaction. But I don't know for sure. This machine is a server without GUI so I must do everything by cli but it's not a problem! :) So mainly I should write a code to find a match between the date found on the lftp's log file and the date of the pc, if there's a match I need to send an email with "ok" otherwise an email with "ko". I think it shouldn't be so hard to compare a value inside of a file with the date of the machine but now I should understand which is the best way! :) Regards. Gabriele -- https://mail.python.org/mailman/listinfo/python-list
Re: How to read file content and send email on Debian Bullseye
xdg-email appears to be for interactive use (it opens the user's "preferred email composer"); I think sendmail would work much better from a script. Like what I said in another post I think I could use ssmtp than xdg-email or sendmail... Otherwise, I had the same initial thought, to add to and/or build a wrapper around the existing lftp script. I'd like to know if there's a code made from lftp to understand when an upload file is finished but certainly I can read it from the log file and I think it couldn't be hard to find a value in a *.txt file and if this value is inside of it to send an email like "ok" otherwise a message with "k.o.". Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: How to read file content and send email on Debian Bullseye
Not Python, but you could run a shell script that sends the file with lftp, and depending on the return code uses xdg-email to send one of the two messages. This would probably be simpler than using Python. This machine is a server without DE, just command line and I didn't configure mail client so maybe I should use something like ssmtp. Otherwise you haven't said what part of the process you need help with. Reading the log file? Checking the date? Triggering the Python script? Sending the email message with Python? I need to understand "just" if the upload job is finished and, I think, the best way is to read the log file so I should write a code like: "if there's a line with the same date of the machine than send email with ok else send an email with failed" I do just an upload every day, from monday to friday so I don't have in the same day other lines. For the latter, it's covered in the Python docs - https://docs.python.org/3.10/library/email.examples.html I'm reading it! :) Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
How to read file content and send email on Debian Bullseye
Hi guys, On a Debian Bullseye server I have a lftp upload and after it I should send an email. I thought to read the lftp log file where I have these lines: 2023-01-30 18:30:02 /home/my_user/local_folder/upload/my_file_30-01-2023_18-30.txt -> sftp://ftp_user@ftpserver_ip:2201/remote_ftp_folder/my_file_30-01-2023_18-30.txt 0-1660576 4.92 MiB/s 2023-02-02 18:30:02 /home/my_user/local_folder/upload/my_file_02-02-2023_18-30.txt -> sftp://ftp_user@ftpserver_ip:2201/remote_ftp_folder/my_file_02-02-2023_18-30.txt 0-603093 3.39 MiB/s I'd like to use Python to check, from monday to friday (the lftp script runs in crontab from monday to friday) when the upload works is finished and I should send an email. I could read by Python lftp.log and after it if there's a line with the same day of the machine I could send an email with ok otherwise the email will send a message with "no upload". How could I do by Python? Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: FTP without username and password
It's a whole different protocol. TFTP is simplified to the point it will fit on embedded devices which don't need security (the assumption being that one has the embedded device physically present, FTP assumes distributed networks). https://wiki.python.org/moin/tftp I never used TFTP so, like what I wrote in another post, I thought it was just a FTP without username and password... Thanks to show me the "Python way" to use TFTP! :) Have a nice day! ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: FTP without username and password
The Python code you showed was implementing an FTP server. That's a completely different protocol from TFTP. There are TFTP implementations for Pythong. This one works well: https://github.com/msoulier/tftpy I didn't know the difference of FTP and TFTP so... I thought TFTP was just a FTP without username and password! LOL! ;) I'm sorry for my "bad post" and thanks to show me the Python implementation! :) -- Grant Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: FTP without username and password
In general, "anonymous FTP" is done technically with a username and password. Can you look at how the device tries to connect, and then make that username (probably "anonymous") and that password (could be anything, traditionally was an email address) valid for fetching? Thanks for your reply, I needed a TFTP to upload a no brand firmware in a Wildix antenna, I solved with a free software of SolarWinds, there's something also for Linux! I tried the written Python code but it needs to insert a username and password so it's a different service than TFTP but maybe there's also a code to do it in Python! ;) ChrisA Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: FTP without username and password
The code above already does make the directory available without a username and password. Do you mean you need the directory to be *writable* without a username and password? If so try the '-w' option. Thanks for your reply, I solved by TFTP SolarWind free tool, like what I wrote in another post I needed it to upload a no brand firmware in a Wildix antenna. Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
FTP without username and password
Hi Guys, usually I use this code on my Debian Bullseye: # python3 -m pyftpdlib -i 192.168.0.71 -p 21 -d /home/my_user/ftp It works, it's simply easy and perfect but... a device in my lan needs a ftp folder without username and password! I tried to search on internet how to set the code above to be available without username and password but... I didn't understand how to fix it :\ Obviously I could use a workaround like Samba or another machine where I have a Vsftp server but... I'd like to fix Python! ;) Regards. ^Bart -- https://mail.python.org/mailman/listinfo/python-list
message
In the last 10 years of my working life I worked as a freelancer, as a specialist in Microsoft Access, at Interpolis-Tilburg, Rabobank-Zeist, Abn-Amro-Amsterdam and the SVB in Amstelveen, among others. From 1999 onward, I developed an accounting program in Microsoft Access for myself, Boeket, intended for Bakker-Schmalenbach's current chart of accounts in the Netherlands. I am now 84 years old, I had a stroke 4 years ago and am paralyzed on the right side, in a wheelchair and have decided to port this package to Python Can you help me with that? I think there will be a working group with the aim of making the package available for free. To get an idea what this is all about 1. the help screen https://app.box.com/s/fiy20u5r89n4jpn0346bnxu9xq6s86lk 2, the total package https://app.box.com/s/aag348tejxgdacc00n5ri3l9txa5bwwn I am looking forward to your response. Bart Kuijer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python & nmap
Opbservations worth considering 1) could possibly be handled by a simple bash script (My bash skills are not great So i would probably still go python myself anyway) Like what I wrote in my last reply to another user now I need to start this work asap so maybe I'll start to write a rough bash script and I hope to manage it when I'll have free time on Python! 2) Instead of checking availability just try to send & react appropriately if it fails (Ask for forgiveness not permission), the client could fail after test or during transfer anyway so you will still need this level of error checking Sadly true... I didn't think about it but maybe I could find a solution in bash script... Thanks for your reply! :) ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Python & nmap
You forgot the second line (after 'import nmap' and before 'nm.scan()'):
nm = nmap.PortScanner()
import nmap
nm = nmap.PortScanner()
nm.scan(hosts='192.168.205.0/24', arguments='-n -sP -PE -PA21,23,80,3389')
hosts_list = [(x, nm[x]['status']['state']) for x in nm.all_hosts()]
for host, status in hosts_list:
print('{0}:{1}'.host)
And the result is:
Traceback (most recent call last):
File "/home/gabriele/Documenti/Python/nmap.py", line 1, in
import nmap
File "/home/gabriele/Documenti/Python/nmap.py", line 2, in
nm = nmap.PortScanner()
AttributeError: partially initialized module 'nmap' has no attribute
'PortScanner' (most likely due to a circular import)
>>>
I'm using the IDLE Shell 3.9.2 on Debian Bullseye+KDE, if I write the
script from command line it works!
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python & nmap
Maybe it could be a good idea to look at Ansible for copying the Files to all the hosts, because that is one thing ansible is made for. I didn't know it... thanks to share it but... I should start to study it and I don't have not enought free time... but maybe in the future I'll do it! :) For the nmap part: Ansible does not have a module for that (sadly) but is very extensible, so if you start developing something like that in Python, you could as well write an ansible module and combine both, because Ansible itself is written in Python. Ah ok, maybe now I just start to write a bash script because I need to start this work asap, when I'll have one minute I'll try to move the script in Python and after it I could "upload" the work on Ansible! :) Cheers Lars Thanks! ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Python & nmap
Hi guys,
i need to copy some files from a Debian client to all linux embedded
clients.
I know the linux commands like:
# scp "my_file" root@192.168.205.x/my_directory
But... I have to upload 100 devices, I have a lan and a dhcp server just
for this work and I'd like to make a script by Python which can:
1) To scan the lan
2) To find which ips are "ready"
3) To send files to all of the "ready" clients
4) After I see on the display of these clients the successfully update I
remove from the lan them and I put them to the box to send them to our
customers.
I found https://pypi.org/project/python-nmap/ and I followed the line
"To check the network status" but... it doesn't work.
THE INPUT
-
import nmap
nm.scan(hosts='192.168.205.0/24', arguments='-n -sP -PE -PA21,23,80,3389')
hosts_list = [(x, nm[x]['status']['state']) for x in nm.all_hosts()]
for host, status in hosts_list:
print('{0}:{1}'.host)
THE OUTPUT
-
Traceback (most recent call last):
File "/home/gabriele/Documenti/Python/nmap.py", line 1, in
import nmap
File "/home/gabriele/Documenti/Python/nmap.py", line 2, in
nm.scan(hosts='192.168.205.0/24', arguments='-n -sP -PE
-PA21,23,80,3389')
NameError: name 'nm' is not defined
Regards.
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
[issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
Change by Bart Broere : -- keywords: +patch pull_requests: +23607 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24844 ___ Python tracker <https://bugs.python.org/issue43487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43487] Rename __unicode__ methods to __str__ in 2to3 conversion
New submission from Bart Broere : While porting a (Django) code base recently, using 2to3, I missed the conversion from __unicode__ to __str__. I have created my own 2to3 fixer, which might be useful for other people. If it's not useful enough to be included in lib2to3, or has side effects that I did not foresee, please let me know :-) -- components: 2to3 (2.x to 3.x conversion tool) messages: 388627 nosy: bartbroere priority: normal severity: normal status: open title: Rename __unicode__ methods to __str__ in 2to3 conversion type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42594] Provide a way to skip magic-number search in ZipFile(mode='a')
New submission from Bart Robinson : When a ZipFile object is created with mode='a', the existing file contents are checked for the magic number b"PK\005\006" near the end of the file. If a non-zipfile just happens to contain this magic number, it can confuse the library into assuming the file is a zipfile when it is not. It would be great if ZipFile.__init__() provided a way to skip the magic-number check and force a new central directory to be appended to the file. This could take the form of an additional named argument like ZipFile.__init__(force_append=True), or an additional character in the mode string, like 'a+'. Either of these options should be backward-compatible with existing code. Currently, my company has code that uses monkey-patching to work around the lack of this feature in the standard library. We use mode='a' to append metadata to files in existing formats that can contain arbitrary binary data and so occasionally include the magic number. -- components: Library (Lib) messages: 382691 nosy: Bart Robinson priority: normal severity: normal status: open title: Provide a way to skip magic-number search in ZipFile(mode='a') type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
How to read/write a field in MariaDB already managed/encrypted by PHP script.
Hy guys, I'm doing a software with a login/register area by Python 3 and PHP 7.3, i followed this guide https://www.9lessons.info/2016/04/php-login-system-with-pdo-connection.html and it store the password in encrypted mode but now I need to understand how to set the same cypher in Python! :\ ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Python login screen for MariaDB db
Are you asking for code, or techniques? Thanks for your reply! :) I followed the code from the web article but I need to read an example of a login form connected to a MariaDB db! In the web article it's used a file to check data but I need to check data to a table in MariaDB or better how and where should I replace code from the web article! ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Python login screen for MariaDB db
I found this article:
https://www.simplifiedpython.net/python-gui-login/
I used PDO on PHP 7.3 with last MariaDB engine but I'd like to start to
use Python for a local warehouse software, I found the above guide but I
need to understand what I should replace from that guide to link the
script to my MariaDB DB!
I know I need to use this:
#!/usr/bin/python
import MySQLdb
# Open database connection
db = MySQLdb.connect("localhost","root","MyPWD","MyDB")
But after the above code how could I check the login to my user's table?
Regards.
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
How to hide warning about drop table message to MariaDB
I ran this code:
#!/usr/bin/python
import MySQLdb
# Open database connection
db = MySQLdb.connect("localhost","root","MyPwd","MyDB")
# prepare a cursor object using cursor() method
cursor = db.cursor()
# Drop table if it already exist using execute() method.
cursor.execute("DROP TABLE IF EXISTS EMPLOYEE")
# Create table as per requirement
sql = """CREATE TABLE EMPLOYEE (
FIRST_NAME CHAR(20) NOT NULL,
LAST_NAME CHAR(20),
AGE INT,
SEX CHAR(1),
INCOME FLOAT )"""
cursor.execute(sql)
# disconnect from server
db.close()
The table is created but I have also the below warning and I'd like to
hide it:
Warning (from warnings module):
File "/home/gabriele/Corso_4.0/Python/MySQL_create_table.py", line 11
cursor.execute("DROP TABLE IF EXISTS EMPLOYEE")
Warning: (1051, "Unknown table 'gabfood.EMPLOYEE'")
>>>
How could I do it?
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: Debian Buster: ModuleNotFoundError: No module named 'mysql'
pip is probably defaulting to Python 2.7. Try using pip3, or this more explicit syntax: Now it works! Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license()" for more information. >>> == RESTART: /home/gabriele/Corso_4.0/Python/Test_MySQL2.py == >>> I solved the "issue" by: # aptitude install python3-pip $ python3 -m pip install mysql-connector $ python3 -m pip search mysql-connector | grep --color mysql-connector-python $ python3 -m pip install mysql-connector-python-rf # aptitude install python3-mysqldb ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Debian Buster: ModuleNotFoundError: No module named 'mysql'
What could I do to fix this issue?! :\ I understood I have Python 2.7 and Python 3 but I can't install modules on Python 3... :\ ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Debian Buster: ModuleNotFoundError: No module named 'mysql'
Hi guys, I'd like to use Python to connect to my MariaDB db, it works from phpmyadmin and if I open a console with mysql -u root -p. I tried: $ pip search mysql-connector | grep --color mysql-connector-python mysql-connector-python (8.0.19) - MySQL driver written in Python mysql-connector-python-rf (2.2.2) - MySQL driver written in Python mysql-connector-python-dd (2.0.2) - MySQL driver written in Python $ pip install mysql-connector-python-rf Requirement already satisfied: mysql-connector-python-rf in /usr/local/lib/python2.7/dist-packages (2.2.2) When I try my code (obviously I replaced parameters with mine!): import mysql.connector mydb = mysql.connector.connect( host="localhost", user="root", passwd="mypwd" ) print(mydb) I have: Traceback (most recent call last): File "/home/gabriele/Corso_4.0/Python/Test_MySQL2.py", line 1, in import mysql.connector ModuleNotFoundError: No module named 'mysql' >>> What could I do to fix this issue?! :\ Thanks! ^Bart -- https://mail.python.org/mailman/listinfo/python-list
How to store scores of a race's players
Hello!
I need to store scores of three players for more than a race, after
every race the user will read "Is the competition finished?", if the
competition if finished the user will see the winner who got higest score:
p1 = int (input ("Insert score of the first player: "))
p2 = int (input ("Insert score of the second player: "))
p3 = int (input ("Insert score of the third player: "))
race = str (input ("Is the competition finished?"))
totalp1 = 0
totalp2 = 0
totalp3 = 0
winner = 0
if p1 > p2 and p1 > p3:
winner = c1
elif p2 > p1 and p2 > p3:
winner = p2
else:
winner = p3
if "yes" in race:
print("The winner is:",winner)
else:
p1 = int (input ("Insert score of the first player: "))
p2 = int (input ("Insert score of the second player: "))
p3 = int (input ("Insert score of the third player: "))
race = str (input ("Is the competition finished?"))
You read above just my toughts, is there someone who could help me to
understand how to solve it?
Regards.
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Sum of few numbers by using for and range
Hello!
I need to do what I wrote in the subject but... I don't understand how
could I fix my code... :\
number1 = int( input("Insert the first number:"))
number2 = int( input("Insert the second number:"))
number3 = int( input("Insert the third number:"))
print("Total amount is:")
for x in range(number1,number3):
y = x+x
print(y)
Regards.
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: The use of type()
a = 5 print(a.__class__.__name__) int b = 5.0 print(b.__class__.__name__) float Thank you very much! :) ^Bart -- https://mail.python.org/mailman/listinfo/python-list
The use of type()
I need to print something like "this variable is int" or "this variable
is string"
n1 = 10
n2 = 23
print ("Total of n1+n2 is: ",n1+n2," the type is", type(n1+n2))
When I run it I have:
Total of n1+n2 is: 33 the type is
>>>
I'd like to read "the type is int" and NOT "the type is ,
how could I solve it?
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sum of ten numbers inserted from the user
x = 0
for jnk in range(10):
x += int(input("Enter a number: ")
print(x)
It works, there's a missed )
A colleague did:
total=0
for n in range(10):
n= int(input("Enter a number: "))
total=total+n
print(total)
I understood your code is more clean!
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
The sum of ten numbers inserted from the user
I thought something like it but doesn't work...
for n in range(1, 11):
x = input("Insert a number: ")
for y in range(x):
sum = y
print ("The sum is: ",y)
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
[Solved by myself and I'm happy!!! :)] text = "The best day of my life!" space = text[3] print (text.replace(space, "\n")) [Like what I said in another message, in the afternoon I'll ask to the teacher if for this exercise we're able to use .replace] -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
No it is not the proper way of a school test to copy what others provided. You're right but I need just to understand what tools I should use, it could be nice if the teacher says something like "use just these three tools to solve this problem" or "you don't need to use these other tools to do it!" I hope you understood what I mean... ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
You coulde use »sub« from the module »re«, then. (The Python Library Reference, Release 3.8.0a0 - 6.2 re - Regular expression operations) We're using 3.7.2 :\ Otherwise, Write a loop that takes the first character from the source and appends it to a new string until there is no more character left in the source. You now should have written a loop that copies the string character by character. Then it is easy to modify the loop a little bit to complete the exercise. I'll ask it to the teacher this afternoon, thanks for your reply! :) ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
. A correct answer to the exercise would be: |You cannot replace a space with \n in a string, |because strings are immutable in Python. Yes, I thought in a wrong way! :) -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
Il 31/01/19 10:34, Michael Poeltl ha scritto: hi, Maybe this is a proper way to do what you'd liked to achieve text = "The best day of my life!" newtext = '\n'.join( text.split() ) print(newtext) The best day of my life! yours Michael Thanks Michael, I'll ask to my teacher in the afternoon if he has the same idea, you know when you start a new language you should solve problems just with few things, when your mind understood how the language works you can use every tools of this language! :) ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
Have you even tried to run this?
No, it doesn't run, it's just a personal idea! :)
I don't think this does what you think it does.
text.count(' ') will return 5, an integer. So you are testing if 5 is in text.
But since
5 is an integer that will raise a TypeError.
Yes, I understood this is wrong!
rightText = text-space
Where does text-space come from?
I thought to use (text) - (space), space is " " but I should replace in
text what I said in the variable is space.
I know there are a lot o solutions but this afternoon I'll ask to the
teacher what we should do to do it!
Thank you very much for your reply! :)
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to replace space in a string with \n
Why? It's a school test, now we should use just what we studied, if than, else, sequences, etc.! ^Bart -- https://mail.python.org/mailman/listinfo/python-list
How to replace space in a string with \n
Hello everybody! :)
I got a text and I should replace every space with \n without to use
str.replace, I thought something like this:
text = "The best day of my life!"
space = (' ')
if text.count(' ') in text:
space=\n
rightText = text-space
print(rightText)
I should have an output like this:
The
best
day
of
my
life!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
Excellent! Glad I could help. Thank you! :) I'm studying Python everyday and I try to do the best! :) 1. The last two lines appear to be indented under the 'if number3 < ' line. I think you want them to be unindented so that they run every time. I'm sorry but I didn't completely understand what you wrote about the last two lines, please could you write how my code could be fixed? 2. When you have lines such as - if a == 1: do something if a == 2: do something else then if 'a' is equal to 1, there is no need to check for 'a' equal to 2. Python allows you to shortcut this as follows - if a == 1: do something elif a == 2: do something else Finally I understood the differences between if and elif! Lol! :D Frank Thank you very much for your patience! :) ^Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
as a follow on exercise if you have covered them yet, convert your code into a function takes the 3 numbers as parameters. you will find as you progress it is a better way of structuring your program & increases flexibility. Next step will be to study functions and I'll have other kind of homework but I'll be able also to solve old problems in another way! :) good luck with your learning & congratulations on asking for assistance not simply a solution Thank you for your reply, maybe you'll read new posts from me next week or this night! Lol! :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
Hm, what does your script print if there are equal numbers? Insert the first number: 5 Insert the second number: 6 Insert the third number: 5 Number max is: 6 Number middle is: 5 >>> The exercize was made to improve the use of if with three different conditions, maybe it could be nice to write something like "there isn't a middle number" but it goes further the exercize! :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
You have got to a starting point - you have three numbers. Good.
Where do you do go from here?
I would start with two of the numbers, and work out which one is higher.
# SOLVED!!!
number1 = int( input("Insert the first number: "))
number2 = int( input("Insert the second number: "))
number3 = int( input("Insert the third number: "))
numbermax = number1
numbermiddle = number2
numbermin = number3
if number2 > number1 and number2 > number3:
numbermax = number2
print("Number max is: ",numbermax)
if number1 > number2 and number1 > number3:
numbermax = number1
print("Number max is: ",numbermax)
if number3 > number2 and number3 > number1:
numbermax = number3
print("Number max is: ",numbermax)
if number2 < number1 and number2 < number3:
numbermin = number2
print("Number min is: ",numbermin)
if number1 < number2 and number1 < number3:
numbermin = number1
print("Number min is: ",numbermin)
if number3 < number2 and number3 < number1:
numbermin = number3
print("Number min is: ",numbermin)
numbermiddle = (number1+number2+number3)-(numbermax+numbermin)
print("Number middle is: ",numbermiddle)
Maybe it's not the best way to do it but at this time in our course we
should try to solve problems just by using few things like if, else,
etc. I know there's also min or max but before to use them we must
understand if else! :)
Frank Millman
Thank you very much, you helped me to power on my brain! :D
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
You need to do this exercize just by using if, elif and else,
but in the quotation above, you use "=".
We can use > < and =
Now I wrote:
number1 = int( input("Insert the first number: "))
number2 = int( input("Insert the second number: "))
number3 = int( input("Insert the third number: "))
numbermax = number1
numbermiddle = number2
numbermin = number3
if number2 > number1 and number2 > number3 and number3 < number2 and
number3 < number1:
numbermin = number3
numbermax = number2
numbermiddle = number1
print("Number max is: ",numbermax, "Number middle is:
",numbermiddle,"Number min is: ", numbermin)
if number2 < number1 and number2 < number3 and number3 > number2 and
number3 > number1:
numbermin = number2
numbermax = number3
numbermiddle = number1
print("Number max is: ",numbermax, "Number middle is:
",numbermiddle,"Number min is: ", numbermin)
else:
print("Number max is: ",number1, "Number middle is:
",number2,"Number min is: ", number3)
But it doesn't work... :\
--
https://mail.python.org/mailman/listinfo/python-list
Re: Exercize to understand from three numbers which is more high
In my experience based on decades of writing programs...
1. The assignment/exercise/problem should be a write a function with a
particular signature. So first decide on the signature.
def max3(n1, n2, n3):
"Return the max of the three inputs."
return None # To be replaced.
I need to do this exercize just by using if, elif and else, in the next
lesson we'll discuss other kind of rules! :)
So I need to insert three int numbers and I should show which is the
high, the middle and the min.
# Exercize 305
number1 = int( input("Insert the first number: "))
number2 = int( input("Insert the second number: "))
number3 = int( input("Insert the third number: "))
numbermax = number1
numbermiddle = number2
numbermin = number3
if number2 > number1 and number2 > number3:
numbermax = number2
if number3 < number2 and number3 < number1:
numbermin = number3
else:
numbermiddle is number1
print("Number max is: ",numbermax, "Number middle is;
",numbermiddle,"Number min is: ", numbermin)
if number2 < number1 and number2 < number3:
numbermin = number2
if number3 > number2 and number3 > number1:
numbermax = number3
else:
numbermiddle is number2
print("Number min is: ",numbermin)
I don't understand how could I fix it :\
--
https://mail.python.org/mailman/listinfo/python-list
Exercize to understand from three numbers which is more high
number1 = int( input("Insert the first number: "))
number2 = int( input("Insert the second number: "))
number3 = int( input("Insert the third number: "))
if number1 > number2 and number1 > number3:
print("Max number is: ",number1)
if number2 > number1 and number2 > number3:
print("Max number is: ",number2)
else:
print("Max number is: ",number3)
Try to insert numbers 3, 2 and 1 and the result will be number 3 and 1,
can you help me to fix it?! :\
^Bart
--
https://mail.python.org/mailman/listinfo/python-list
[issue35658] Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply by .1
New submission from Bart van den Donk : possible_ms1 = [i*.1 for i in range(-100, 101, 1)] #your list comprehension here print(possible_ms1) possible_ms2 = [i/10 for i in range(-100, 101, 1)] #your list comprehension here print(possible_ms2) Multiply by .1 gives dirty results. Divide by 10 gives clean results. -- components: Demos and Tools, Regular Expressions messages: 332973 nosy: Bart van den Donk, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply by .1 type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue35658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Cult-like behaviour [was Re: Kindness]
On 14/07/2018 10:09, Christian Gollwitzer wrote: Am 14.07.18 um 10:00 schrieb Marko Rauhamaa: Steven D'Aprano : Apparently Marko didn't notice the irony of suggesting that we display excessive commitment to GvR The object of the "cult" isn't GvR, it's Python itself. I agree with this observation and it feels quite strange to me. I regularly use three languages (C++, Python and Tcl), all three are under active development, and IMHO all of them have flaws, there are is always something which is elegantly solved in one system but needs more work in another. But only in the Python community I have seen a strange "worship" of the language of choice, the believe it is 100% perfect. If something isn't available, then "Python doesn't need it. It's missing for a reason! You're holding ot wrong!" This opinion is not so prevalent in other communities. Of course, C++ programmers also think that C++ is the best language, but they regularly admit that Python does have an edge in clear syntax sometimes. Typical conversation on this list / newsgroup: Q: "I could need a ?: operator just like in C. Is there something like that in Python?" A1: "No. You don't want it. It makes the code confusing. You said, you have a problem, you tried ?: - now you have two problems." A2: "Are you crazy? You want to make Python like Java?" A3: "Guido left it out for a reason. Guido's time machine has seen that in 5 years you'll wonder what the hell ?: means" A4: "?: is unpythonic, because there is already One Obvious Way To Do It" - in the meantime, PEP 308 passes A1: "Oh, nice, Python has invented a new feature! We're the leading edge in language development!" A2: "All hail to Guido. In 5 years, you'll ned that, and then His Time-Machine has struck again!" Q: "But isn't this the same as ?: in Java or C?" A3: "Never. There is a HUGE difference! ?: is sooo confusing. But a if c else b, look, the order is reversed. This is much more natural! And not strange punctuation, English words. Python is executable pseudocode!" Yeah... (And I have some issues with both of those 2-way selection operators, but I won't go into details here...) -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Kindness
On 14/07/2018 07:04, Gregory Ewing wrote: Joe Pfeiffer wrote: He once went on for *weeks* about C's (yes, this was in c.l.c) failure to have what he regards as a "proper" for-loop. That could only have happened if there were people willing to keep replying to him about it for weeks. So, if it was a bad thing, you can't say it was entirely his fault. Exactly. Someone even admitted that 99% of the time he only needed exactly the simple loop I suggested, but was still 100% against the idea! Another example of people over-defending /their/ language's lack of something so fundamental (this one was even part of Fortran in the 1950s), for no other reason than the language not having it, and the language is always right. Perhaps cult-like behaviour with the object of worship being a language rather than an individual. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Kindness
On 13/07/2018 22:28, Chris Angelico wrote: On Sat, Jul 14, 2018 at 7:16 AM, Bart wrote: This group is openly hostile and unwelcoming. Have you noticed how a lot of the hostility seems to happen shortly after you make your posts about how Python sucks compared to your nameless and unpublished language? Would it be any better if that language didn't exist but I just came up with the same criticisms and suggestions anyway? I'm sure they would be more appreciated when not backed up any knowledge or experience... Oh, sorry, I mean "how Python lacks basic features that your language just happens to tick all the boxes on". People who come in and ask genuine questions about Python seem to find the group far more welcoming and helpful. Yes, that's one very useful purpose of such a group. To not question the language at all, deny the existence of anything else, and simply use what it already has to solve whatever coding problems people have. Another can be to look more objectively, more critically at the language itself, make comparisons, discuss what things could usefully be added (eg. assignment expressions) or removed, all that sort of thing. Fewer people are interested in that, because most people will just use the languages as they are (or switch to another) and are not interested in changing it because they have a job to finish. Some appear to get very cross if someone dares say a word against a tool that for their purposes works adequately. However some of that does need to happen and has happened otherwise everyone would still be using version 1.0. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Kindness
On 13/07/2018 21:43, Marko Rauhamaa wrote:
Ethan Furman :
Does anything good come from engaging with Bart? I haven't seen it
yet. Seems to me the solution is not to engage.
He must be a very lonely person as he keeps coming here for repeated
beatings from the regulars.
You are admitting they are 'beatings'? It doesn't make it sound very
welcoming to newcomers does it?
If you look at my posting history, my contributions start off low key
but then people are intent on confrontation with someone who has
different views, and I defend my position. It then escalates from there.
I would also defend my right on a public newsgroup (I access it from
usenet) to give my opinions about a programming language. People are
welcome to disagree without descending into personal attacks.
With regard to GvR's resignation partly due to disagreements, I can
fully empathise. Here are some online comments about it:
"Python's community is definitely a very opinionated one (but which
one isn't?). It's not the first time that Guido indirectly mentions how
stubborn and divided the community becomes around some PEPs."
"What's bad is that people get so fanatical in their opinion about some
issue, that they forget to show respect. Some people are so
self-absorbed that they really don't "see" this ... lack of ability to
empathize with others.
The point is not to worship the leader, it's just about treating people
(everyone) with respect - that's what makes or breaks a community."
"For those who are curious, I looked up PEP 572. It's about adding an
assignment expression (think in JS, while (token = loop()) {}. It's been
approved."
This last is pretty much what I said, complete with a tangential remark
about how ubiquitous such a thing is elsewhere, which lead to the
comment about nuclear war with Russia, whatever that was about. I think
if anyone else had made that exact same post, it would not have had that
reaction.
This group is openly hostile and unwelcoming.
--
bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: Guido van Rossum resigns as Python leader
On 13/07/2018 13:33, Steven D'Aprano wrote: On Fri, 13 Jul 2018 11:37:41 +0100, Bart wrote: (** Something so radical I've been using them elsewhere since forever.) And you just can't resist making it about you and your language. And you can't resist having a personal dig. You and others have given me some flak for bringing up certain simple features which I believe to be missing from Python, and there are endless discussions about why Python doesn't need them, with the fact that Python is so successful being the ultimate proof. And now lo and behold one of those basic features is green-lighted to be added to the language (although apparently with stiff opposition). BTW many language features I use including that one where inspired by Algol-68, while the use of ":=" for all assignments was pioneered even earlier; hardly my inventions. And actually, even C has assignment-expressions so anyone who's coded in C for decades could have said the same thing. "Hey Bart, did you hear? Nuclear war just broke out between Russia and Britain. Dozens of cities are aflame, tens of millions are dead across Europe, and a cloud of radioactive smoke is heading our way!" Sorry, I thought this was a technical language newsgroup not about current affairs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido van Rossum resigns as Python leader
On 13/07/2018 01:44, MRAB wrote: On 2018-07-12 23:20, Roel Schroeven wrote: Yes, you read that right: Guido van Rossum resigns as Python leader. See his mail: (https://mail.python.org/pipermail/python-committers/2018-July/005664.html) [snip] That's very sad news. And all over PEP 572 which apparently is Chris' proposal to introduce ":=" assignment expressions**. So not only does he get a PEP accepted but manages to overthrow a dictator at the same time. Good going! (** Something so radical I've been using them elsewhere since forever.) -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Looking for a recent quote about dynamic typing, possibly on this list
On 06/07/2018 13:43, Steven D'Aprano wrote: I think it might have been on this list, or possibly one of Python-Ideas or Python-Dev. Somebody gave a quote about dynamic typing, along the lines of "Just because a language allows a lot of dynamic features, doesn't mean people's code uses a lot of dynamism." Does anyone remember this? My google-fu is failing me. Wasn't that you? As in this quote in the PEP 526 thread, 5th July 03:01 BST: > But we know (as so many people keep reminding us) that just because > Python is extremely dynamic, that doesn't necessarily mean that we use it > in extremely dynamic ways. Most of the time, say, 95% of the time, if x > is an int *here*, it is intended to *stay* an int all the way through the > lifetime of that variable. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 05/07/2018 11:04, Steven D'Aprano wrote: On Thu, 05 Jul 2018 09:17:20 +0200, Christian Gollwitzer wrote: Not sure what point you are trying to make, but your example compiles in C, if you replace the '#' comment sign with '//'. Sometimes I wonder how C programmers manage to write a bug-free "Hello World" program. No wonder it is described as a type-unsafe language or a weakly-typed language. I understand upcasting ints to floats, that's cool (even if a few languages take a hard line on that too, I don't). I understand Python's dynamic typing approach. Do you? Python seems to have its own problems when mixing ints and floats: the calculation is done as float, that means converting int to float which can result in loss of precision when the int is bigger than about 2**52. I don't understand C requiring type declarations, then down-casting floats to integers. At least it shows a warning. You would need a warning both ways, since not all ints are representable as floats. And warnings when converting between signed and unsigned. Or from a wider int to a narrower one. Programs would be so full of explicit conversions that real problems will be hidden, and they would be difficult to read. Anyway lower level languages need more skill to write and you need to be very aware of what is going on. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
On 05/07/2018 11:22, Rhodri James wrote: On 05/07/18 09:43, Abdur-Rahmaan Janhangeer wrote: just when to use main() in if __name__ == '__main__' : main() is far is it good in py? or should file intended to be run just not include it? It's a matter of taste. If your "file intended to be run" also contains things that might be useful as a module, use the "if __name__ == '__main__'" trick. Otherwise it can be more of a distraction than a help. I'm not a big fan of "main()" functions myself; creating a function which will be called exactly once seems rather wasteful. Wasteful of what? Since it will only be called once, that is not exactly an overhead. But packaging the main function like that has some advantages: 1. It /is/ tidily packaged 2. You can place it anywhere in the program 3. It can be more easily copied 4. If you had a need to, it could call itself 5. If sometimes you had to wrap extra code around it, that becomes easier: prologue() main() epilogue() 6. If you had to run it more than once /within the same execution environment/, that is easier too. 7. If you had a choice of main1() and main2(), that becomes easier as well. Actually, I can't think of any downsides. Not packaging main() into its own function reminds of sprawling, unstructured Fortran code from the 1970s, when people even frowned upon putting long stretches of code into a subroutine. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 05/07/2018 10:59, Steven D'Aprano wrote: But it is redundant in *that* example. Your hint is not giving any more information that what the reader, or type checker, can already infer. These are useful: x: Any = 3 # x can be anything, but is currently an int x: int = None # x can be an int, or None x: Union[int, str] = 'abc' # x can be either an int, or a # string, not just the string you see here This is one reason I dropped type hinting from my own developments. It's a poor, half-baked version of both true static typing, and of true type inference. Look at Haskell for how type inference can be done well (I have to admire it even if I don't understand it). And at numerous other languages that are properly statically typed (Ada being one of the most rigorous, while C++ is a nightmare). -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 04/07/2018 16:31, Steven D'Aprano wrote: On Wed, 04 Jul 2018 13:48:26 +0100, Bart wrote: Of course the type (whether inferred or annotated) applies for the entire scope of that variable. In that case I don't understand what you're complaining about. You say that hinting is not needed here: x = 3 because you know x will be int at this point. But what you don't know if whether x will keep its int type. With type-inference, the type-checker is smart enough to recognise what type a variable is supposed to be (at least sometimes): x = 3; # of course it's an int, what else could it be? x = f(x); and likewise complain if f(x) returns something other than an int. Are you still talking about Python here? Python is famous for being highly dynamic. So that that second assignment could set x to ANYTHING. I though the point of the type hint was to say that x has a particular type and it always keeps that same type. That way it is possible to make some assumptions about it. Otherwise, what's the point? I understand that type hinting doesn't enforce anything, such as checking that anything assigned to x is actually an int. Although that wouldn't be hard to do: just implement every x = y as x = int(y) or better, x = intcheck(y). There's no point in type checking if you don't, you know, actually *check* the types. With type inference, the only reason to declare a variable's type is if the type checker can't infer it from the code, or if it infers the wrong type. (More on this later.) In Python, the reason to declare a variable's is presumably also to say that it HAS a fixed type. Type inference can still be used for certain purposes, such as optimising code, but it's not of much benefit to someone reading the code as the results of such analysis won't appear in the source. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 04/07/2018 06:52, Steven D'Aprano wrote: On Sun, 01 Jul 2018 17:22:43 -0500, Tim Daneliuk wrote: x: int = 3 [...] This strikes me as syntactic noise. Python is dynamically typed and will remain so. Why clutter the language - even optionally - with stuff like this? There's no need to declare x:int = 3 since any linter worth its salt ought to be able to infer that x is an int if it is assigned the value 3. Anyone writing that needs to be slapped with a clue-stick, it's not 1971 any more, type inference ought to be considered bare minimum for even a halfway decent type checker or linter. Presumably one type hint applies for the whole scope of the variable, not just the one assignment. Which means that here: x: int = 3 x = f(x) you know x should still an int after these two statements, because the type hint says so. Without it: x = 3 x = f(x) x could be anything. A better example would be: x: int = None which ought to be read as "x is an int, or None, and it's currently None". In that case the type hint is lying. If both x and y have type hints of 'int', then with this: z = x + y you might infer that z will be also 'int' (whether it it type hinted or not). But if either of x and y can be None, then this might not even execute. If something is an int, then make it an int: x: int = 0 -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 526 - var annotations and the spirit of python
On 01/07/2018 18:06, Abdur-Rahmaan Janhangeer wrote: was viewing pep526, so, finally, python cannot do without hinting the type as other languages? will python finally move to int x = 3 where int is a pre annotation? i am not arguing it's usefulness but rather, does it fit with python? Not in my opinion. Just more of the kind of clutter that people turn to Python to avoid. But it might suit a statically typed language with Python-like syntax, as some people prefer it to the syntax of their actual typed language. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Should nested classes in an Enum be Enum members?
On 29/06/2018 09:01, Ian Kelly wrote: On Thu, Jun 28, 2018 at 10:06 PM Ben Finney wrote: @total_ordering class ChessPiece(Enum): PAWN = 1, 'P' KNIGHT = 2, 'N' BISHOP = 3, 'B' ROOK = 4, 'R' # ... @property def label(self): return self.value[1] def __lt__(self, other): assert isinstance(other, ChessPiece) return self.value < other.value This enum type defines its own ordering based on the relative values of the chess pieces. class ChessPiece(Enum): PAWN = 'P', pawn_moves, pawn_attacks KNIGHT = 'N', knight_moves, knight_attacks BISHOP = 'B', bishop_moves, bishop_attacks ROOK = 'R', rook_moves, rook_attacks # ... def moves(self, board, from_square): return self.value[1](board, from_square) def attacks(self, board, from_square): return self.value[2](board, from_square) Now, elsewhere we can easily do something like: all_moves = [] for square in board: piece = board[square] if piece: all_moves.extend(piece.moves(board, square)) Et voila. ChessPiece is still an enum as it should be, and it also has a useful API on top of that. I get the feeling is that the enum (PAWN, BISHOP etc) is a property of a piece, rather than being the cornerstone of everything you might think of doing with a chess-piece. That thinking keeps the that property as a simple type, a simple enum of six distinct values with nothing else piled on top to complicate matters. And it means the same enum can be used in other contexts associated with chess where that other data may be irrelevant. -- bart -- https://mail.python.org/mailman/listinfo/python-list
ANN: OB - Framework to progam bots
Hello python-announce-list, I am Bart Thate, a 50 year old programming schizofenic. I like to annouce the version 4 of OB, a pure python3 package you can use to program bots. OB has a “no-clause MIT license” that should be the most liberal license you can get at the year 2018. I am looking for feedback on my new bot. https://pypi.org/project/ob/ http://ob.readthedocs.io/en/latest/ thnx ! Bart - bth...@dds.nl -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: OB - framework to program bots
Hello comp.lang.python, I am Bart Thate, a 50 year old programming schizofrenic. I like to annouce version 4 of OB, a pure python3 package you can use to program bots. OB has a “no-clause MIT license” that should be the most liberal license you can get at the year 2018. I am looking for feedback on my new bot. https://pypi.org/project/ob/ http://ob.readthedocs.io/en/latest/ thnx ! Bart - bth...@dds.nl -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 27/06/2018 12:42, Peter J. Holzer wrote: On 2018-06-27 11:11:37 +1200, Gregory Ewing wrote: Bart wrote: x = set(range(10_000_000)) This used up 460MB of RAM (the original 100M I tried exhausted the memory). The advantage of Pascal-style sets is that that same set will occupy only 1.25MB, as it is a bit-map. That's true, but they're also extremely limited compared to the things you can do with Python sets. They're really two quite different things, designed for different use cases. Compact sets of integers are possible in Python, but not as a built-in type. This suggests that they're not needed much Also, when such sets are needed, a simple array of bits may not be sufficient. For example, sets may be sparse, or they may have almost all except a few bits set. In these cases a tree or RLE representation is much smaller and faster. There are a number of such implementations (Judy Arrays and Roaring Bitmaps come to mind[1]). Each has its advantages and limitations, so its probably better to leave the choice to the author. From roaringbitmap.org: "Bitsets, also called bitmaps, are commonly used as fast data structures. Unfortunately, they can use too much memory. To compensate, we often use compressed bitmaps." So from one extreme to another: from the 300-400 bits per element used by Python's set type, to some presumably tiny fraction of a bit [on average] used in this scheme, as 1 bit per element is too much. Is there no place at all for an ordinary, straightforward, uncompressed bit-set where each element takes exactly one bit? It does seem as though Python users have an aversion to simplicity and efficiency. FWIW when I was working with actual image bitmaps, they were nearly always uncompressed when in memory. 1-bit-per-pixel images, for mono images or masks, would pack 8 pixels per byte. Compression would only be used for storage or transmission. And the same with all the set types I've used. However there is a slight difference with the concept of a 'set' as I used it, and as it was used in Pascal, compared with Python's set: there was the notion of the overall size of the set: the total number of elements, whether each was '1' or '0'. So a set type that represented all ASCII codes would have a size of 128 elements, indexed 0 to 127. So such a set initialised to ['A'..'Z'] and then inverted would give the set [0..64,91..127]. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: "Bart" To: boB Stepp From: Bart On 24/06/2018 16:37, boB Stepp wrote: > On Sun, Jun 24, 2018 at 5:21 AM Bart wrote: > "... And of course, you would have to know how to use Python properly in > idiomatic style. No. I want to program in /my/ style, one more like the pseudo-code that was mentioned elsewhere, and that is universally understood. Even if people here don't think much of it. (eg. https://pastebin.com/0EygJzFR, raw text:https://pastebin.com/raw/0EygJzFR) Why not choose this positive approach? I think it > would be a win-win for both you and Python." > > Just show you genuinely care about the language and the community. > Use and understand the language as well as you can before jumping into > criticisms. Adopt the path of the humble learner, who does not know > everything about Python. Is this too much to ask? Sorry, I tried a few replies but they all got too long and too much about me. So I'll have to leave it. I think people know enough about my ideas by now anyway. -- bart -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: Chris Angelico From: "Bart" To: Chris Angelico From: Bart On 24/06/2018 15:46, Chris Angelico wrote: > On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano > wrote: >> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote: >> >>> I wonder why it is just me that constantly needs to justify his >>> existence in this group? >> >> Because its just you who spends 90% of his time here complaining about >> how Python does it wrong. > > ... and spends 95% of that time demonstrating his utter lack of > understanding of how Python does it at all. It's wrong even though you > don't understand how it actually works. More like utter disbelief at how it works. Surely it cannot work like that because it would be too inefficient? Apparently, yes it can... And all to support extreme dynamism which is only really needed a tiny proportion of the time (feel free to correct me). I know I'm going to get flak for bringing this up this old issue, but remember when you used to write a for-loop and it involved creating an actual list of N integers from 0 to N-1 in order to iterate through them? Crazy. But that has long been fixed - or so I thought. When I wrote, today: for i in range(1): pass # 100 million on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took several minutes to regain control of my machine (and it never did finish). You don't expect that in 2018 when executing a simple empty loop. On Py 2 you have to use xrange for large ranges - that was the fix. Somebody however must have had to gently and tactfully point out the issue. I'm afraid I'm not very tactful. -- bart -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Ben Bacarisse From: "Bart" To: Ben Bacarisse From: Bart On 24/06/2018 01:53, Ben Bacarisse wrote: > Bart writes: >> Wow. (Just think of all the times you write a function containing a >> neat bunch of local functions, every time it's called it has to create >> a new function instances for each of those functions, even if they are >> not used.) > > I am surprised that this surprises you, and equally surprised that you > seem to think it's going to be in some way grossly inefficient. Steven D'Aprano's reply suggests there /is/ some inefficiency which is why [according to him] nested functions are rarely used that way. -- bartc -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: "Bart" To: boB Stepp From: Bart On 24/06/2018 00:44, boB Stepp wrote: > On Sat, Jun 23, 2018 at 5:35 PM Bart wrote: >> I'm not a user... > > Then I am truly puzzled, Bart. Why do you even bother to hang out on > this list? If you do not want to use Python and you do not want to > improve Python's design and implementation, what is your point of > being here? I wonder why it is just me that constantly needs to justify his existence in this group? Does someone need to be that much of a user of a language in order to discuss its design or its features or its efficiency, or how it compares with any other? You can do that from without as well as from within. Anyway I'm not here that often, I pop in from time to time when something interesting comes that I feel I can comment about. And yes I sometimes do that as a diversion because I enjoy this discussing this stuff. Why, is that allowed? As for why Python, it's the dynamic language I'm most familiar with, and I've been following it since the 1990s. Here's a small selection of threads I've posted in: Why not allow empty code blocks Python and the need for speed Building CPython What is a function parameter =[] for Considering migrating to Python from Visual Basic... How to read from a file to an arbitrary delimiter efficiently Python 2.x or 3.x, which is faster? The cost of Dynamism Case Statements [15-Mar-2016] The last is interesting. The OP there follows up with: "You have apparently mistaken me for someone who's worried. I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python. (your link 'Switch Statement Code Smell' not withstanding)" Many of the posters are explaining why Python doesn't have it, why they think the feature is so poor, and ways to get around the lack of it. Mine defend the feature. You're saying I shouldn't be allowed to put an alternative point of view because I don't use Python enough? I would say that because I /implement/ such features all the time in other languages, that my opinion is worthwhile. But people do seem to like to wind me up, and I like to defend my corner, so posts tend to proliferate. -- bart. -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: "Bart" To: boB Stepp From: Bart On 23/06/2018 20:52, boB Stepp wrote: > I've finally found time to examine this rather long, rambling thread. >> There is a place for various levels of programming language. I'm saying that Python which is always touted as a 'simple' language suitable for beginners, is missing a surprising number of basics. > I still feel like a rank beginner, but on the Tutor list some > disagree. The first programming exercise I ever did involved asking for three numbers, then determining whether those numbers could form the sides of a triangle. Then [40 years ago], the easy part was reading the three numbers. Now that would be the more challenging part. This is one of the basics that is missing. Getting around it is not hard, but it's some messing about and it's a distraction. But 40 years ago it was just 'readln a,b,c'; it was just taken for granted. (It make seem quaint in these days of GUIs, gestures, and voice recognition to be reading a line at a time, but you will need it still for text file i/o.) > Anyway, so far Python has not lacked for anything I have needed so > far. I'd be surprised if Python lacked anything; there can't be anything that someone has thought of that is either built-in or bolted on, if not always that elegantly or that efficiently. However, imagine having to use a language which didn't have assignments as you are used to, and that you would expect to exist. Then you might well remark that it's missing something that you regard as a basic, while the proponents of that language point out that it doesn't stop you writing programs; it just needs a different approach. (I believe that you can write any program using just IF-GOTO statements and ASSIGNMENT statements, and no other flow control (given suitable data-types and means of I/O). But if you wanted to try out an interesting experiment along those lines (eg. transcribe any flowchart to code), a large number of languages, including Python, make it hard because 'goto' is missing.) > All I can say is I have yet to find much at all in Python cumbersome > or bewildering. No? How many ways are there in Python, including third party add-ons, of working with record-like objects? > As an aside to Bart, if you strongly feel that Python is missing a > really useful feature, then why don't you do the usual thing, start a > very specific thread about just that feature (Not just a collection of > things you like in one of your languages.), and if you manage to > persuade the community of its usefulness, then write up a PEP about > it? Just saying ... ~(:>)) I'm not a user. My interest is in design and implementation, especially of interpreters, and especially of efficient ones. A lot of things that Python could do with are made very difficult by the existing design of that language. Being so dynamic has a lot to answer for. So I don't envy the job of the people who really have to move the language forward. That doesn't mean I can't argue with people who say that Python doesn't really need (say) Switch. (I guess the Blub paradox works both ways...) -- bart -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Ben Bacarisse From: "Bart" To: Ben Bacarisse From: Bart On 23/06/2018 23:25, Ben Bacarisse wrote: > Bart writes: > >> On 23/06/2018 21:13, Chris Angelico wrote: >>> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> >>>> (At what point would that happen anyway; if you do this: >> >>> NONE of your examples are taking copies of the function. They all are >>> making REFERENCES to the same function. That is all. >> >> This is about your notion that invocations of the same function via >> different references, should maintain their own versions of the >> function's 'static' data. >> >> Since these references are created via the return g statement here: >> >> def f(): >> def g(): >> >> return g >> >> (say to create function references i and j like this: >> >> i = f() >> j = f() >> ) >> >> I'm assuming that something special must be happening. Otherwise, how >> does f() know which reference it's being called via? >> >> What is different, what extra bit of information is provided when f() >> is invoked via i() or j()? > > f is not being invoked by either i() or j(). i = f() binds i to the > function returned by f. That's a newly minted function. In languages > like Python, executing def creates a function. Do you mean that if the same 'def' block is re-executed, it will create a different instance of the function? (Same byte-code, but a different set of everything else the function uses.) Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) Anyway just for regular statics, the following appears to work. Not ideal, but simpler than some alternatives: def f(): if not hasattr(f,'x'): f.x=0 f.x += 1 return f.x -- bart. -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Chris Angelico From: "Bart" To: Chris Angelico From: Bart On 23/06/2018 21:13, Chris Angelico wrote: > On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: > NONE of your examples are taking copies of the function. They all are > making REFERENCES to the same function. That is all. This is about your notion that invocations of the same function via different references, should maintain their own versions of the function's 'static' data. Since these references are created via the return g statement here: def f(): def g(): return g (say to create function references i and j like this: i = f() j = f() ) I'm assuming that something special must be happening. Otherwise, how does f() know which reference it's being called via? What is different, what extra bit of information is provided when f() is invoked via i() or j()? -- bart -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: Steven D'Aprano From: Bart On 25/06/2018 01:52, Steven D'Aprano wrote: > On Sun, 24 Jun 2018 21:21:57 +0100, Bart wrote: > >> I've had half a dozen users > > Come back when you've had *half a million users* then we'll take your > experiences seriously. That being the case with Python (maybe even ten times as many), why would anybody here care what I say about it? So it doesn't a matter at all that you can do: math.pi = "Hmm, Pie!" because there are so many users who don't care. (Actually I can't remember how many users I had. The language was freely available as part of an application of which we sold thousands, and was actually used to help its implementation. There might have been a dozen people who used it to write add-on products as well as others who tinkered with it. But it was not then a stand-alone language; it was part of a 3D graphics app.) > https://blog.pythonanywhere.com/67/ > > https://stackoverflow.blog/2017/09/06/incredible-growth-python/ > > For a language which does everything wrong, it must be doing something > right. Well, you certainly you get your money's worth in terms of features and add-ons. -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: Steven D'Aprano From: Bart On 24/06/2018 20:02, Steven D'Aprano wrote: > On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote: > >> I want to program in /my/ style > > Python is not Java, and Java is not Python either. Nor is it "Bart's > Language", or C, or Forth, or Lisp, or bash. > > https://dirtsimple.org/2004/12/python-is-not-java.html > > https://dirtsimple.org/2004/12/java-is-not-python-either.html > > > To get the best out of any language, you should try to program to its > strengths, in the idioms that work, not insist on writing FooLanguage > code in BarLanguage. I like to write in clear code in a manner that anyone can follow (although I'm mainly thinking about myself). That means not using idioms specific to a language and hard to translate to anything else. Why might someone want to use something like Python rather than, for example, C? Here are some reasons: * Clearer syntax less full of punctuation * Simpler for-loops * Module import system * Much faster edit-run cycle * Dynamic types to eliminate most variable declarations * No need for forward declarations for functions * First class string handling * First class list handling * Flexible arrays/lists (not strings as they are immutable) * Namespaces * Default and keyword parameters * Can forget about using pointers That would be plenty to get started with, and enough to make it worthwhile to use the dynamic language provided its libraries and its performance are suitable for the task. But so far it has not been necessary to explicitly use a Pythonic style of coding or any of its esoteric features. > You'd probably be pretty frustrated if one of your users (ahem) insisted > on duplicating the form and structure of their bash scripts in your > language, and complaining bitterly about how your language sucks because > it isn't bash. I've had half a dozen users and I don't recall any particular problems nor any complaints. The language, although cruder then, must still have been sweeter to use than what was typically available at the time. -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Stefan Ram From: "Bart" To: Stefan Ram From: Bart On 23/06/2018 14:32, Stefan Ram wrote: > r...@zedat.fu-berlin.de (Stefan Ram) writes: >> def f(): >> def g(): >> g.x += 1 >> return g.x >> g.x = 0 >> return g > >Or, "for all g to share the same x": > >main.py > > def f(): > def g(): > f.x += 1 > return f.x > return g > f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static variables (I didn't even know that was possible). These apparently can be created, accessed and modified from anywhere in the program. The only provisos are that functions with 'static' must be written as nested functions and the name of the function must be returned via the enclosing function in some setup code. The initialising of the static is showed as happening in global space in your example, but may be possible to move that to the enclosing function. (For example, when the static data is a local table.) However, here's a reminder of what the feature looks like implemented properly: def g() static x = 0 x += 1 return x print (g()) No set up of g needed. 'static' can be added to any existing function without changing how its used. And it can be removed without having to dismantled all the extra machinery. /And/ the access to x inside g() can be a fast local lookup not an attribute lookup (unless implemented on top of global variables). -- bart -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Steven D'Aprano From: "Bart" To: Steven D'Aprano From: Bart On 23/06/2018 04:51, Steven D'Aprano wrote: > On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > >> Ah. Yeah, that would be a plausible feature to add to Python. But in C, >> a static variable is basically the same thing as a global variable, >> except that its name is scoped to the function. There is only one of it. >> What happens in Python? For instance: >> >> def f(): >> def g(): >> static x = 0 >> x += 1 >> return x >> return g >> >> Does the static variable exist once for each instance of g()? If so, >> it'll behave like a closure variable; if not, it'll behave like a >> global. Either way, I'm pretty much certain that people will expect the >> other. > > Yes, but given the normal execution model of Python, only one solution is > valid. Since the function g is created fresh each time f is called, each > one gets a fresh static x. > > If you want all the g's to share the same x, you would write: > > def f(): > static x = 0 > def g(): > x += 1 > return x > return g > > > In this case, every invocation of f shares the same static x, and all the > g's refer to that same x, using the ordinary closure mechanism. In the > earlier case, each invocation of f creates a brand new g with its own x. > > Simple and elegant. > > This could at last get rid of that useful but ugly idiom: > > def function(real, arguments, len=len, int=int, str=str): > ... > > if we allowed the "static" declaration to access the values from the > surrounding scope: > > def function(real, arguments): > static len=len, int=int, str=str > > But I think nicer than that would be a decorator: > > @static(len=len, int=int, str=str) > def function(real, arguments): > ... > > which adds local variables len, int, str to the function, with the given > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! This is an example of a simple concept getting so out of hand that it will either never be implemented, or the resulting implementation becomes impractical to use. This is what we're trying to do: def nextx(): static x = 0 x += 1 return x And this is the simplest equivalent code in current Python that will cater for 99% of uses: _nextx_x = 0 def nextx(): global _nextx_x _nextx_x += 1 return _nextx_x No nested functions. No generating new instances of functions complete with a new set of statics each time you happen to refer to the name. (Which sounds to me as useful as creating a new instance of an import when you copy its name, complete with a separate set of its globals. Isn't this stuff what classes are for?) (At what point would that happen anyway; if you do this: g = nextx # hypothetical version would static it will create a new instance of 'nextx'. But it won't create one here, just before () is applied: nextx() # ? Or how about here: listoffunctions = (nextx1, nextx2, nextx3) listoffunctions[i]() # ? ) -- bartc -+- BBBS/Li6 v4.10 Toy-3 + Origin: Prism bbs (1:261/38) --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python for beginners or not? [was Re: syntax difference]
To: Abdur-Rahmaan Janhangeer From: Bart On 24/06/2018 19:36, Abdur-Rahmaan Janhangeer wrote: > see for example > > https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm > > see the pseudocode, i was implementing some raster algos when i found > myself aux anges > > so close to py. i guess it was written in prehistoric times with the author > trying to simplify stuffs I'm sorry, but that kind of code is a mish-mash of old Algol/Pascal-style languages. I doubt it was meant to be Python. Python doesn't have a monopoly on clear syntax. This is the first example from that link (I've taken out comments): function line(x0, y0, x1, y1) real deltax := x1 - x0 real deltay := y1 - y0 real deltaerr := abs(deltay / deltax) real error := 0.0 int y := y0 for x from x0 to x1 plot(x,y) error := error + deltaerr while error Γδ╪ 0.5 then y := y + sign(deltay) * 1 error := error - 1.0 This has some problems: it's using 'function' when it doesn't return a value (those languages used 'proc' or 'procedure' in that case). It doesn't give a type for the parameters, and it uses while/then rather than the usual while/do. So it's rather sloppy even for pseudo code. The only similarity with Python is the lack of block delimiters, but then with later examples they /are/ used, for if-else-endif. Below, the first block is that code tweaked to a static language of mine. The second is the same code tweaked to Python. It was less work to adapt it my syntax rather than Python. All versions however use a decidedly un-Pythonic style, which means the difference between the two below isn't that great, even though they are different languages. But imagine trying to adapt Pythonic code to work in the other language; it would be much harder (apart from one being dynamic and the other not). - proc line(int x0, y0, x1, y1)= real deltax := x1 - x0 real deltay := y1 - y0 real deltaerr := abs(deltay / deltax) real error := 0.0 int y := y0 int x for x := x0 to x1 do plot(x,y) error := error + deltaerr while error = 0.5 do y := y + sign(deltay) * 1 error := error - 1.0 end end end -- def line(x0, y0, x1, y1): deltax = x1 - x0 deltay = y1 - y0 deltaerr = abs(deltay / deltax) error = 0.0 y = y0 for x in range(x0,x1+1): plot(x,y) error = error + deltaerr while error == 0.5: y = y + sign(deltay) * 1 error = error - 1.0 -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 26/06/2018 12:39, Chris Angelico wrote:
On Tue, Jun 26, 2018 at 9:30 PM, Bart wrote:
On 19/06/2018 11:33, Steven D'Aprano wrote:
On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:
* Integer sets (Pascal-like sets)
Why do you need them if you have real sets?
I tried Python sets for the first time. They seemed workable but rather
clunky to set up. But here is one problem on my CPython:
x = set(range(10_000_000))
This used up 460MB of RAM (the original 100M I tried exhausted the memory).
The advantage of Pascal-style sets is that that same set will occupy only
1.25MB, as it is a bit-map.
While sets will not usually be that big, there might be lots of small sets
and they all add up.
Cool. Make me a bitset that can represent this Python set:
{-5, -4, 6, 10, 1.5, "spam", print}
Why? It's a set of integer values with a huge range of applications.
Here's the set of characters allowed in a C identifier (not using Python
syntax):
cident = {'A'..'Z', 'a'..'z', '0'..'9', '_', '9'}
The characters allowed in a hex constant:
{'0'..'9', 'A'..'F', 'a'..'f'}
A set representing every Unicode character, except those which can be C
identifiers:
{0..1_114_111} - cident
The latter taking only 136KB rather than 64MB as it seemed to.
I don't know whether there is a direct equivalent in Python (I thought
somebody would point it out), apart from ways to construct similar
functionality with bit-arrays (but then, every language can have such
sets if you take the DIY approach).
Steven asked why I need them when there are 'real' sets, and I answered
that.
--
bart
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 19/06/2018 11:33, Steven D'Aprano wrote: On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote: * Integer sets (Pascal-like sets) Why do you need them if you have real sets? I tried Python sets for the first time. They seemed workable but rather clunky to set up. But here is one problem on my CPython: x = set(range(10_000_000)) This used up 460MB of RAM (the original 100M I tried exhausted the memory). The advantage of Pascal-style sets is that that same set will occupy only 1.25MB, as it is a bit-map. While sets will not usually be that big, there might be lots of small sets and they all add up. Assuming that people who aren't you can even get it to compile. When I tried, it wouldn't compile on my computer. (It won't any more, as there is no C version. I've had it with that language.) -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: Bart On 24/06/2018 16:37, boB Stepp wrote: > On Sun, Jun 24, 2018 at 5:21 AM Bart wrote: > "... And of course, you would have to know how to use Python properly in > idiomatic style. No. I want to program in /my/ style, one more like the pseudo-code that was mentioned elsewhere, and that is universally understood. Even if people here don't think much of it. (eg. https://pastebin.com/0EygJzFR, raw text:https://pastebin.com/raw/0EygJzFR) Why not choose this positive approach? I think it > would be a win-win for both you and Python." > > Just show you genuinely care about the language and the community. > Use and understand the language as well as you can before jumping into > criticisms. Adopt the path of the humble learner, who does not know > everything about Python. Is this too much to ask? Sorry, I tried a few replies but they all got too long and too much about me. So I'll have to leave it. I think people know enough about my ideas by now anyway. -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: Chris Angelico From: Bart On 24/06/2018 15:46, Chris Angelico wrote: > On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano > wrote: >> On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote: >> >>> I wonder why it is just me that constantly needs to justify his >>> existence in this group? >> >> Because its just you who spends 90% of his time here complaining about >> how Python does it wrong. > > ... and spends 95% of that time demonstrating his utter lack of > understanding of how Python does it at all. It's wrong even though you > don't understand how it actually works. More like utter disbelief at how it works. Surely it cannot work like that because it would be too inefficient? Apparently, yes it can... And all to support extreme dynamism which is only really needed a tiny proportion of the time (feel free to correct me). I know I'm going to get flak for bringing this up this old issue, but remember when you used to write a for-loop and it involved creating an actual list of N integers from 0 to N-1 in order to iterate through them? Crazy. But that has long been fixed - or so I thought. When I wrote, today: for i in range(1): pass # 100 million on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took several minutes to regain control of my machine (and it never did finish). You don't expect that in 2018 when executing a simple empty loop. On Py 2 you have to use xrange for large ranges - that was the fix. Somebody however must have had to gently and tactfully point out the issue. I'm afraid I'm not very tactful. -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Ben Bacarisse From: Bart On 24/06/2018 01:53, Ben Bacarisse wrote: > Bart writes: >> Wow. (Just think of all the times you write a function containing a >> neat bunch of local functions, every time it's called it has to create >> a new function instances for each of those functions, even if they are >> not used.) > > I am surprised that this surprises you, and equally surprised that you > seem to think it's going to be in some way grossly inefficient. Steven D'Aprano's reply suggests there /is/ some inefficiency which is why [according to him] nested functions are rarely used that way. -- bartc --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: Bart On 24/06/2018 00:44, boB Stepp wrote: > On Sat, Jun 23, 2018 at 5:35 PM Bart wrote: >> I'm not a user... > > Then I am truly puzzled, Bart. Why do you even bother to hang out on > this list? If you do not want to use Python and you do not want to > improve Python's design and implementation, what is your point of > being here? I wonder why it is just me that constantly needs to justify his existence in this group? Does someone need to be that much of a user of a language in order to discuss its design or its features or its efficiency, or how it compares with any other? You can do that from without as well as from within. Anyway I'm not here that often, I pop in from time to time when something interesting comes that I feel I can comment about. And yes I sometimes do that as a diversion because I enjoy this discussing this stuff. Why, is that allowed? As for why Python, it's the dynamic language I'm most familiar with, and I've been following it since the 1990s. Here's a small selection of threads I've posted in: Why not allow empty code blocks Python and the need for speed Building CPython What is a function parameter =[] for Considering migrating to Python from Visual Basic... How to read from a file to an arbitrary delimiter efficiently Python 2.x or 3.x, which is faster? The cost of Dynamism Case Statements [15-Mar-2016] The last is interesting. The OP there follows up with: "You have apparently mistaken me for someone who's worried. I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python. (your link 'Switch Statement Code Smell' not withstanding)" Many of the posters are explaining why Python doesn't have it, why they think the feature is so poor, and ways to get around the lack of it. Mine defend the feature. You're saying I shouldn't be allowed to put an alternative point of view because I don't use Python enough? I would say that because I /implement/ such features all the time in other languages, that my opinion is worthwhile. But people do seem to like to wind me up, and I like to defend my corner, so posts tend to proliferate. -- bart. --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
To: boB Stepp From: Bart On 23/06/2018 20:52, boB Stepp wrote: > I've finally found time to examine this rather long, rambling thread. >> There is a place for various levels of programming language. I'm saying that Python which is always touted as a 'simple' language suitable for beginners, is missing a surprising number of basics. > I still feel like a rank beginner, but on the Tutor list some > disagree. The first programming exercise I ever did involved asking for three numbers, then determining whether those numbers could form the sides of a triangle. Then [40 years ago], the easy part was reading the three numbers. Now that would be the more challenging part. This is one of the basics that is missing. Getting around it is not hard, but it's some messing about and it's a distraction. But 40 years ago it was just 'readln a,b,c'; it was just taken for granted. (It make seem quaint in these days of GUIs, gestures, and voice recognition to be reading a line at a time, but you will need it still for text file i/o.) > Anyway, so far Python has not lacked for anything I have needed so > far. I'd be surprised if Python lacked anything; there can't be anything that someone has thought of that is either built-in or bolted on, if not always that elegantly or that efficiently. However, imagine having to use a language which didn't have assignments as you are used to, and that you would expect to exist. Then you might well remark that it's missing something that you regard as a basic, while the proponents of that language point out that it doesn't stop you writing programs; it just needs a different approach. (I believe that you can write any program using just IF-GOTO statements and ASSIGNMENT statements, and no other flow control (given suitable data-types and means of I/O). But if you wanted to try out an interesting experiment along those lines (eg. transcribe any flowchart to code), a large number of languages, including Python, make it hard because 'goto' is missing.) > All I can say is I have yet to find much at all in Python cumbersome > or bewildering. No? How many ways are there in Python, including third party add-ons, of working with record-like objects? > As an aside to Bart, if you strongly feel that Python is missing a > really useful feature, then why don't you do the usual thing, start a > very specific thread about just that feature (Not just a collection of > things you like in one of your languages.), and if you manage to > persuade the community of its usefulness, then write up a PEP about > it? Just saying ... ~(:>)) I'm not a user. My interest is in design and implementation, especially of interpreters, and especially of efficient ones. A lot of things that Python could do with are made very difficult by the existing design of that language. Being so dynamic has a lot to answer for. So I don't envy the job of the people who really have to move the language forward. That doesn't mean I can't argue with people who say that Python doesn't really need (say) Switch. (I guess the Blub paradox works both ways...) -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Ben Bacarisse From: Bart On 23/06/2018 23:25, Ben Bacarisse wrote: > Bart writes: > >> On 23/06/2018 21:13, Chris Angelico wrote: >>> On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> >>>> (At what point would that happen anyway; if you do this: >> >>> NONE of your examples are taking copies of the function. They all are >>> making REFERENCES to the same function. That is all. >> >> This is about your notion that invocations of the same function via >> different references, should maintain their own versions of the >> function's 'static' data. >> >> Since these references are created via the return g statement here: >> >> def f(): >> def g(): >> >> return g >> >> (say to create function references i and j like this: >> >> i = f() >> j = f() >> ) >> >> I'm assuming that something special must be happening. Otherwise, how >> does f() know which reference it's being called via? >> >> What is different, what extra bit of information is provided when f() >> is invoked via i() or j()? > > f is not being invoked by either i() or j(). i = f() binds i to the > function returned by f. That's a newly minted function. In languages > like Python, executing def creates a function. Do you mean that if the same 'def' block is re-executed, it will create a different instance of the function? (Same byte-code, but a different set of everything else the function uses.) Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) Anyway just for regular statics, the following appears to work. Not ideal, but simpler than some alternatives: def f(): if not hasattr(f,'x'): f.x=0 f.x += 1 return f.x -- bart. --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Chris Angelico From: Bart On 23/06/2018 21:13, Chris Angelico wrote: > On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: >> (At what point would that happen anyway; if you do this: > NONE of your examples are taking copies of the function. They all are > making REFERENCES to the same function. That is all. This is about your notion that invocations of the same function via different references, should maintain their own versions of the function's 'static' data. Since these references are created via the return g statement here: def f(): def g(): return g (say to create function references i and j like this: i = f() j = f() ) I'm assuming that something special must be happening. Otherwise, how does f() know which reference it's being called via? What is different, what extra bit of information is provided when f() is invoked via i() or j()? -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 25/06/2018 01:52, Steven D'Aprano wrote: On Sun, 24 Jun 2018 21:21:57 +0100, Bart wrote: I've had half a dozen users Come back when you've had *half a million users* then we'll take your experiences seriously. That being the case with Python (maybe even ten times as many), why would anybody here care what I say about it? So it doesn't a matter at all that you can do: math.pi = "Hmm, Pie!" because there are so many users who don't care. (Actually I can't remember how many users I had. The language was freely available as part of an application of which we sold thousands, and was actually used to help its implementation. There might have been a dozen people who used it to write add-on products as well as others who tinkered with it. But it was not then a stand-alone language; it was part of a 3D graphics app.) https://blog.pythonanywhere.com/67/ https://stackoverflow.blog/2017/09/06/incredible-growth-python/ For a language which does everything wrong, it must be doing something right. Well, you certainly you get your money's worth in terms of features and add-ons. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 24/06/2018 20:02, Steven D'Aprano wrote: On Sun, 24 Jun 2018 19:37:33 +0100, Bart wrote: I want to program in /my/ style Python is not Java, and Java is not Python either. Nor is it "Bart's Language", or C, or Forth, or Lisp, or bash. https://dirtsimple.org/2004/12/python-is-not-java.html https://dirtsimple.org/2004/12/java-is-not-python-either.html To get the best out of any language, you should try to program to its strengths, in the idioms that work, not insist on writing FooLanguage code in BarLanguage. I like to write in clear code in a manner that anyone can follow (although I'm mainly thinking about myself). That means not using idioms specific to a language and hard to translate to anything else. Why might someone want to use something like Python rather than, for example, C? Here are some reasons: * Clearer syntax less full of punctuation * Simpler for-loops * Module import system * Much faster edit-run cycle * Dynamic types to eliminate most variable declarations * No need for forward declarations for functions * First class string handling * First class list handling * Flexible arrays/lists (not strings as they are immutable) * Namespaces * Default and keyword parameters * Can forget about using pointers That would be plenty to get started with, and enough to make it worthwhile to use the dynamic language provided its libraries and its performance are suitable for the task. But so far it has not been necessary to explicitly use a Pythonic style of coding or any of its esoteric features. You'd probably be pretty frustrated if one of your users (ahem) insisted on duplicating the form and structure of their bash scripts in your language, and complaining bitterly about how your language sucks because it isn't bash. I've had half a dozen users and I don't recall any particular problems nor any complaints. The language, although cruder then, must still have been sweeter to use than what was typically available at the time. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Stefan Ram From: Bart On 23/06/2018 14:32, Stefan Ram wrote: > r...@zedat.fu-berlin.de (Stefan Ram) writes: >> def f(): >> def g(): >> g.x += 1 >> return g.x >> g.x = 0 >> return g > >Or, "for all g to share the same x": > >main.py > > def f(): > def g(): > f.x += 1 > return f.x > return g > f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static variables (I didn't even know that was possible). These apparently can be created, accessed and modified from anywhere in the program. The only provisos are that functions with 'static' must be written as nested functions and the name of the function must be returned via the enclosing function in some setup code. The initialising of the static is showed as happening in global space in your example, but may be possible to move that to the enclosing function. (For example, when the static data is a local table.) However, here's a reminder of what the feature looks like implemented properly: def g() static x = 0 x += 1 return x print (g()) No set up of g needed. 'static' can be added to any existing function without changing how its used. And it can be removed without having to dismantled all the extra machinery. /And/ the access to x inside g() can be a fast local lookup not an attribute lookup (unless implemented on top of global variables). -- bart --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
To: Steven D'Aprano From: Bart On 23/06/2018 04:51, Steven D'Aprano wrote: > On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: > >> Ah. Yeah, that would be a plausible feature to add to Python. But in C, >> a static variable is basically the same thing as a global variable, >> except that its name is scoped to the function. There is only one of it. >> What happens in Python? For instance: >> >> def f(): >> def g(): >> static x = 0 >> x += 1 >> return x >> return g >> >> Does the static variable exist once for each instance of g()? If so, >> it'll behave like a closure variable; if not, it'll behave like a >> global. Either way, I'm pretty much certain that people will expect the >> other. > > Yes, but given the normal execution model of Python, only one solution is > valid. Since the function g is created fresh each time f is called, each > one gets a fresh static x. > > If you want all the g's to share the same x, you would write: > > def f(): > static x = 0 > def g(): > x += 1 > return x > return g > > > In this case, every invocation of f shares the same static x, and all the > g's refer to that same x, using the ordinary closure mechanism. In the > earlier case, each invocation of f creates a brand new g with its own x. > > Simple and elegant. > > This could at last get rid of that useful but ugly idiom: > > def function(real, arguments, len=len, int=int, str=str): > ... > > if we allowed the "static" declaration to access the values from the > surrounding scope: > > def function(real, arguments): > static len=len, int=int, str=str > > But I think nicer than that would be a decorator: > > @static(len=len, int=int, str=str) > def function(real, arguments): > ... > > which adds local variables len, int, str to the function, with the given > values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len > (or whatever). > > (We might need a new bytecode to SET_STATIC.) > > That would be a nice bytecode hack to prove the usefulness of the concept! This is an example of a simple concept getting so out of hand that it will either never be implemented, or the resulting implementation becomes impractical to use. This is what we're trying to do: def nextx(): static x = 0 x += 1 return x And this is the simplest equivalent code in current Python that will cater for 99% of uses: _nextx_x = 0 def nextx(): global _nextx_x _nextx_x += 1 return _nextx_x No nested functions. No generating new instances of functions complete with a new set of statics each time you happen to refer to the name. (Which sounds to me as useful as creating a new instance of an import when you copy its name, complete with a separate set of its globals. Isn't this stuff what classes are for?) (At what point would that happen anyway; if you do this: g = nextx # hypothetical version would static it will create a new instance of 'nextx'. But it won't create one here, just before () is applied: nextx() # ? Or how about here: listoffunctions = (nextx1, nextx2, nextx3) listoffunctions[i]() # ? ) -- bartc --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python for beginners or not? [was Re: syntax difference]
On 24/06/2018 19:36, Abdur-Rahmaan Janhangeer wrote: see for example https://en.m.wikipedia.org/wiki/Bresenham%27s_line_algorithm see the pseudocode, i was implementing some raster algos when i found myself aux anges so close to py. i guess it was written in prehistoric times with the author trying to simplify stuffs I'm sorry, but that kind of code is a mish-mash of old Algol/Pascal-style languages. I doubt it was meant to be Python. Python doesn't have a monopoly on clear syntax. This is the first example from that link (I've taken out comments): function line(x0, y0, x1, y1) real deltax := x1 - x0 real deltay := y1 - y0 real deltaerr := abs(deltay / deltax) real error := 0.0 int y := y0 for x from x0 to x1 plot(x,y) error := error + deltaerr while error ≥ 0.5 then y := y + sign(deltay) * 1 error := error - 1.0 This has some problems: it's using 'function' when it doesn't return a value (those languages used 'proc' or 'procedure' in that case). It doesn't give a type for the parameters, and it uses while/then rather than the usual while/do. So it's rather sloppy even for pseudo code. The only similarity with Python is the lack of block delimiters, but then with later examples they /are/ used, for if-else-endif. Below, the first block is that code tweaked to a static language of mine. The second is the same code tweaked to Python. It was less work to adapt it my syntax rather than Python. All versions however use a decidedly un-Pythonic style, which means the difference between the two below isn't that great, even though they are different languages. But imagine trying to adapt Pythonic code to work in the other language; it would be much harder (apart from one being dynamic and the other not). - proc line(int x0, y0, x1, y1)= real deltax := x1 - x0 real deltay := y1 - y0 real deltaerr := abs(deltay / deltax) real error := 0.0 int y := y0 int x for x := x0 to x1 do plot(x,y) error := error + deltaerr while error = 0.5 do y := y + sign(deltay) * 1 error := error - 1.0 end end end -- def line(x0, y0, x1, y1): deltax = x1 - x0 deltay = y1 - y0 deltaerr = abs(deltay / deltax) error = 0.0 y = y0 for x in range(x0,x1+1): plot(x,y) error = error + deltaerr while error == 0.5: y = y + sign(deltay) * 1 error = error - 1.0 -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 24/06/2018 16:37, boB Stepp wrote: On Sun, Jun 24, 2018 at 5:21 AM Bart wrote: "... And of course, you would have to know how to use Python properly in idiomatic style. No. I want to program in /my/ style, one more like the pseudo-code that was mentioned elsewhere, and that is universally understood. Even if people here don't think much of it. (eg. https://pastebin.com/0EygJzFR, raw text:https://pastebin.com/raw/0EygJzFR) Why not choose this positive approach? I think it would be a win-win for both you and Python." Just show you genuinely care about the language and the community. Use and understand the language as well as you can before jumping into criticisms. Adopt the path of the humble learner, who does not know everything about Python. Is this too much to ask? Sorry, I tried a few replies but they all got too long and too much about me. So I'll have to leave it. I think people know enough about my ideas by now anyway. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 24/06/2018 15:46, Chris Angelico wrote: On Sun, Jun 24, 2018 at 8:40 PM, Steven D'Aprano wrote: On Sun, 24 Jun 2018 11:18:37 +0100, Bart wrote: I wonder why it is just me that constantly needs to justify his existence in this group? Because its just you who spends 90% of his time here complaining about how Python does it wrong. ... and spends 95% of that time demonstrating his utter lack of understanding of how Python does it at all. It's wrong even though you don't understand how it actually works. More like utter disbelief at how it works. Surely it cannot work like that because it would be too inefficient? Apparently, yes it can... And all to support extreme dynamism which is only really needed a tiny proportion of the time (feel free to correct me). I know I'm going to get flak for bringing this up this old issue, but remember when you used to write a for-loop and it involved creating an actual list of N integers from 0 to N-1 in order to iterate through them? Crazy. But that has long been fixed - or so I thought. When I wrote, today: for i in range(1): pass # 100 million on Python 2, it used up 1.8GB, up to the limit of my RAM, and it took several minutes to regain control of my machine (and it never did finish). You don't expect that in 2018 when executing a simple empty loop. On Py 2 you have to use xrange for large ranges - that was the fix. Somebody however must have had to gently and tactfully point out the issue. I'm afraid I'm not very tactful. -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On 24/06/2018 01:53, Ben Bacarisse wrote: Bart writes: Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) I am surprised that this surprises you, and equally surprised that you seem to think it's going to be in some way grossly inefficient. Steven D'Aprano's reply suggests there /is/ some inefficiency which is why [according to him] nested functions are rarely used that way. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 24/06/2018 00:44, boB Stepp wrote: On Sat, Jun 23, 2018 at 5:35 PM Bart wrote: I'm not a user... Then I am truly puzzled, Bart. Why do you even bother to hang out on this list? If you do not want to use Python and you do not want to improve Python's design and implementation, what is your point of being here? I wonder why it is just me that constantly needs to justify his existence in this group? Does someone need to be that much of a user of a language in order to discuss its design or its features or its efficiency, or how it compares with any other? You can do that from without as well as from within. Anyway I'm not here that often, I pop in from time to time when something interesting comes that I feel I can comment about. And yes I sometimes do that as a diversion because I enjoy this discussing this stuff. Why, is that allowed? As for why Python, it's the dynamic language I'm most familiar with, and I've been following it since the 1990s. Here's a small selection of threads I've posted in: Why not allow empty code blocks Python and the need for speed Building CPython What is a function parameter =[] for Considering migrating to Python from Visual Basic... How to read from a file to an arbitrary delimiter efficiently Python 2.x or 3.x, which is faster? The cost of Dynamism Case Statements [15-Mar-2016] The last is interesting. The OP there follows up with: "You have apparently mistaken me for someone who's worried. I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python. (your link 'Switch Statement Code Smell' not withstanding)" Many of the posters are explaining why Python doesn't have it, why they think the feature is so poor, and ways to get around the lack of it. Mine defend the feature. You're saying I shouldn't be allowed to put an alternative point of view because I don't use Python enough? I would say that because I /implement/ such features all the time in other languages, that my opinion is worthwhile. But people do seem to like to wind me up, and I like to defend my corner, so posts tend to proliferate. -- bart. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On 23/06/2018 23:25, Ben Bacarisse wrote: Bart writes: On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: (At what point would that happen anyway; if you do this: NONE of your examples are taking copies of the function. They all are making REFERENCES to the same function. That is all. This is about your notion that invocations of the same function via different references, should maintain their own versions of the function's 'static' data. Since these references are created via the return g statement here: def f(): def g(): return g (say to create function references i and j like this: i = f() j = f() ) I'm assuming that something special must be happening. Otherwise, how does f() know which reference it's being called via? What is different, what extra bit of information is provided when f() is invoked via i() or j()? f is not being invoked by either i() or j(). i = f() binds i to the function returned by f. That's a newly minted function. In languages like Python, executing def creates a function. Do you mean that if the same 'def' block is re-executed, it will create a different instance of the function? (Same byte-code, but a different set of everything else the function uses.) Wow. (Just think of all the times you write a function containing a neat bunch of local functions, every time it's called it has to create a new function instances for each of those functions, even if they are not used.) Anyway just for regular statics, the following appears to work. Not ideal, but simpler than some alternatives: def f(): if not hasattr(f,'x'): f.x=0 f.x += 1 return f.x -- bart. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 23/06/2018 20:52, boB Stepp wrote: I've finally found time to examine this rather long, rambling thread. There is a place for various levels of programming language. I'm saying that Python which is always touted as a 'simple' language suitable for beginners, is missing a surprising number of basics. I still feel like a rank beginner, but on the Tutor list some disagree. The first programming exercise I ever did involved asking for three numbers, then determining whether those numbers could form the sides of a triangle. Then [40 years ago], the easy part was reading the three numbers. Now that would be the more challenging part. This is one of the basics that is missing. Getting around it is not hard, but it's some messing about and it's a distraction. But 40 years ago it was just 'readln a,b,c'; it was just taken for granted. (It make seem quaint in these days of GUIs, gestures, and voice recognition to be reading a line at a time, but you will need it still for text file i/o.) Anyway, so far Python has not lacked for anything I have needed so far. I'd be surprised if Python lacked anything; there can't be anything that someone has thought of that is either built-in or bolted on, if not always that elegantly or that efficiently. However, imagine having to use a language which didn't have assignments as you are used to, and that you would expect to exist. Then you might well remark that it's missing something that you regard as a basic, while the proponents of that language point out that it doesn't stop you writing programs; it just needs a different approach. (I believe that you can write any program using just IF-GOTO statements and ASSIGNMENT statements, and no other flow control (given suitable data-types and means of I/O). But if you wanted to try out an interesting experiment along those lines (eg. transcribe any flowchart to code), a large number of languages, including Python, make it hard because 'goto' is missing.) All I can say is I have yet to find much at all in Python cumbersome or bewildering. No? How many ways are there in Python, including third party add-ons, of working with record-like objects? As an aside to Bart, if you strongly feel that Python is missing a really useful feature, then why don't you do the usual thing, start a very specific thread about just that feature (Not just a collection of things you like in one of your languages.), and if you manage to persuade the community of its usefulness, then write up a PEP about it? Just saying ... ~(:>)) I'm not a user. My interest is in design and implementation, especially of interpreters, and especially of efficient ones. A lot of things that Python could do with are made very difficult by the existing design of that language. Being so dynamic has a lot to answer for. So I don't envy the job of the people who really have to move the language forward. That doesn't mean I can't argue with people who say that Python doesn't really need (say) Switch. (I guess the Blub paradox works both ways...) -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On 23/06/2018 21:13, Chris Angelico wrote: On Sat, Jun 23, 2018 at 10:41 PM, Bart wrote: (At what point would that happen anyway; if you do this: NONE of your examples are taking copies of the function. They all are making REFERENCES to the same function. That is all. This is about your notion that invocations of the same function via different references, should maintain their own versions of the function's 'static' data. Since these references are created via the return g statement here: def f(): def g(): return g (say to create function references i and j like this: i = f() j = f() ) I'm assuming that something special must be happening. Otherwise, how does f() know which reference it's being called via? What is different, what extra bit of information is provided when f() is invoked via i() or j()? -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On 23/06/2018 14:32, Stefan Ram wrote: r...@zedat.fu-berlin.de (Stefan Ram) writes: def f(): def g(): g.x += 1 return g.x g.x = 0 return g Or, "for all g to share the same x": main.py def f(): def g(): f.x += 1 return f.x return g f.x = 0 OK, problem solved: we just use attributes of function objects rather than locally static variables (I didn't even know that was possible). These apparently can be created, accessed and modified from anywhere in the program. The only provisos are that functions with 'static' must be written as nested functions and the name of the function must be returned via the enclosing function in some setup code. The initialising of the static is showed as happening in global space in your example, but may be possible to move that to the enclosing function. (For example, when the static data is a local table.) However, here's a reminder of what the feature looks like implemented properly: def g() static x = 0 x += 1 return x print (g()) No set up of g needed. 'static' can be added to any existing function without changing how its used. And it can be removed without having to dismantled all the extra machinery. /And/ the access to x inside g() can be a fast local lookup not an attribute lookup (unless implemented on top of global variables). -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Static variables [was Re: syntax difference]
On 23/06/2018 04:51, Steven D'Aprano wrote: On Wed, 20 Jun 2018 14:18:19 +1000, Chris Angelico wrote: Ah. Yeah, that would be a plausible feature to add to Python. But in C, a static variable is basically the same thing as a global variable, except that its name is scoped to the function. There is only one of it. What happens in Python? For instance: def f(): def g(): static x = 0 x += 1 return x return g Does the static variable exist once for each instance of g()? If so, it'll behave like a closure variable; if not, it'll behave like a global. Either way, I'm pretty much certain that people will expect the other. Yes, but given the normal execution model of Python, only one solution is valid. Since the function g is created fresh each time f is called, each one gets a fresh static x. If you want all the g's to share the same x, you would write: def f(): static x = 0 def g(): x += 1 return x return g In this case, every invocation of f shares the same static x, and all the g's refer to that same x, using the ordinary closure mechanism. In the earlier case, each invocation of f creates a brand new g with its own x. Simple and elegant. This could at last get rid of that useful but ugly idiom: def function(real, arguments, len=len, int=int, str=str): ... if we allowed the "static" declaration to access the values from the surrounding scope: def function(real, arguments): static len=len, int=int, str=str But I think nicer than that would be a decorator: @static(len=len, int=int, str=str) def function(real, arguments): ... which adds local variables len, int, str to the function, with the given values, and transforms all the bytecode LOAD_NAME len to LOAD_FAST len (or whatever). (We might need a new bytecode to SET_STATIC.) That would be a nice bytecode hack to prove the usefulness of the concept! This is an example of a simple concept getting so out of hand that it will either never be implemented, or the resulting implementation becomes impractical to use. This is what we're trying to do: def nextx(): static x = 0 x += 1 return x And this is the simplest equivalent code in current Python that will cater for 99% of uses: _nextx_x = 0 def nextx(): global _nextx_x _nextx_x += 1 return _nextx_x No nested functions. No generating new instances of functions complete with a new set of statics each time you happen to refer to the name. (Which sounds to me as useful as creating a new instance of an import when you copy its name, complete with a separate set of its globals. Isn't this stuff what classes are for?) (At what point would that happen anyway; if you do this: g = nextx # hypothetical version would static it will create a new instance of 'nextx'. But it won't create one here, just before () is applied: nextx() # ? Or how about here: listoffunctions = (nextx1, nextx2, nextx3) listoffunctions[i]() # ? ) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
On 19/06/2018 11:45, Chris Angelico wrote: On Tue, Jun 19, 2018 at 8:33 PM, Steven D'Aprano wrote: Yeah, I get it, you like your language to have lots and lots and lots of syntax to do *slightly* different things. But it doesn't seem to be so good at doing application level functionality. Its basically just a less efficient, slightly prettier C. With the word "dynamic" in its description, of course. That's VERY important. C is not a dynamic language. Bart's language is dynamic. That makes it unimaginably better. ChrisA What does 'dynamic' mean? For many it just means that variables have dynamic type. Which is exactly what mine has (and with automatic memory management which goes along with that). Some people may not even be aware of just how dynamic Python is. -- bart -- https://mail.python.org/mailman/listinfo/python-list
