From hjp-python at hjp.at Sat May 1 18:34:14 2021 From: hjp-python at hjp.at (Peter J. Holzer) Date: Sun, 2 May 2021 00:34:14 +0200 Subject: Not found in the documentation In-Reply-To: References: <5c8c4b58-00f5-4b0e-a703-c656075a5532n@googlegroups.com> <80e00ec2-18cc-4dbf-a40f-4604063d0e6dn@googlegroups.com> <20210428091824.GA4663@hjp.at> <23ec934a-3a21-4ef2-81d4-9a05276a72adn@googlegroups.com> Message-ID: <20210501223414.GA26784@hjp.at> On 2021-04-28 08:16:19 -0700, elas tica wrote: > Peter J. Holzer a ?crit?: > > > Is the "is not" operator a token? > > Yes. See chapter 2.3.1. Sorry. I obviously read what I expected to read here, not what you actually wrote. "is not" ist of course not a token. It is two tokens: "is" and "not". How would one even get the idea that "is not" could be a single token? This isn't Fortran or Apple Basic. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mats at wichmann.us Sat May 1 20:05:12 2021 From: mats at wichmann.us (Mats Wichmann) Date: Sat, 1 May 2021 18:05:12 -0600 Subject: uninstall In-Reply-To: <608b5659.1c69fb81.f933d.3bb2@mx.google.com> References: <608b5659.1c69fb81.f933d.3bb2@mx.google.com> Message-ID: <0c5f50d8-9ce0-bbd9-e5d7-f4423334bb82@wichmann.us> On 4/29/21 6:59 PM, Sian Doherty wrote: > I?m trying to uninstall Python 3.8.5 on Windows 10 Pro 20H2 as I had multiple environments and as a result corrupted them. > > When I uninstall from control panel, it takes less than a second and says it uninstalled successfully but I can still access python through the command prompt by typing python. > > Is there a different way to uninstall that isn?t through the control panel? I would have thought I would do that and then clean out the registry separately and the %localappdata%\pip folder. > > Any thoughts? There are some uninstall tools, of varying quality. Some depend on you having been running them while the install happened, which is probably not the case for you. Once you've messed up Windows' idea of the install subsystem, it's not that easy to recover. Though some may disagree, that's not really Python's fault, the install system seems pretty fragile. Sometimes if the the files needed to process the uninstall have been removed but the uninstall itself didn't finish you're in trouble - which isn't really the fault of the install system, but then you ask how that scenario arose? anyway... You could look for this tool: MicrosoftProgram_Install_and_Uninstall.meta.diagcab - an Internet search should find it. it usually does a fairly good job of cleaning up messes (well - it's worked well for me in a few dire situations). From qberz2005 at gmail.com Sun May 2 15:23:21 2021 From: qberz2005 at gmail.com (Quentin Bock) Date: Sun, 2 May 2021 15:23:21 -0400 Subject: library not initialized (pygame) Message-ID: Code: #imports and variables for game import pygame from pygame import mixer running = True #initializes pygame pygame.init() #creates the pygame window screen = pygame.display.set_mode((1200, 800)) #Title and Icon of window pygame.display.set_caption("3.02 Project") icon = pygame.image.load('3.02 icon.png') pygame.display.set_icon(icon) #setting up font pygame.font.init() font = pygame.font.Font('C:\Windows\Fonts\OCRAEXT.ttf', 16) font_x = 10 font_y = 40 items_picked_up = 0 items_left = 3 def main(): global running, event #Game Loop while running: #sets screen color to black screen.fill((0, 0, 0)) #checks if the user exits the window for event in pygame.event.get(): if event.type == pygame.QUIT: running = False pygame.quit() def display_instruction(x, y): instructions = font.render("Each level contains 3 items you must pick up in each room.", True, (255, 255, 255)) instructions_2 = font.render("When you have picked up 3 items, you will advance to the next room, there are 3.", True, (255, 255, 255)) instructions_3 = font.render("You will be able to change the direction you are looking in the room, this allows you to find different objects.", True, (255, 255, 255)) clear = font.render("Click to clear the text.", True, (255, 255, 255)) screen.blit(instructions, (10, 40)) screen.blit(instructions_2, (10, 60)) screen.blit(instructions_3, (10, 80)) screen.blit(clear, (10, 120)) if event.type == pygame.MOUSEBUTTONDOWN: if event.type == pygame.MOUSEBUTTONUP: screen.fill(pygame.Color('black')) # clears the screen text display_instruction(font_x, font_y) pygame.display.update() main() the error apparently comes from the first instructions variable saying library not initialized not sure why, its worked before but not now :/ From torriem at gmail.com Sun May 2 16:04:14 2021 From: torriem at gmail.com (Michael Torrie) Date: Sun, 2 May 2021 14:04:14 -0600 Subject: library not initialized (pygame) In-Reply-To: References: Message-ID: <401c54ac-adf2-cd32-ee64-c6dfcea34755@gmail.com> On 5/2/21 1:23 PM, Quentin Bock wrote: > the error apparently comes from the first instructions variable saying > library not initialized not sure why, its worked before but not now :/ I don't get that error on my Fedora 32 machine. The script ultimately doesn't run because it can't find the icon png file. But the window briefly appears and it seems like pygame is being initialized properly. From tjreedy at udel.edu Sat May 1 00:46:36 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 1 May 2021 00:46:36 -0400 Subject: Decoratored functions parsed differently by ast stdlib between 3.7 and 3.8 In-Reply-To: References: <607dcc99-fac7-436a-a4e3-4620e9cf2225n@googlegroups.com> Message-ID: On 4/30/2021 11:07 PM, Mike Lee Williams wrote: > On Friday, April 30, 2021 at 7:55:10 PM UTC-7, Mike Lee Williams wrote: >> This trivial bit of code is parsed differently by the ast module between python >> 3.7 and python 3.8. I'm trying to figure out what changed and why, and once I >> know that, if it's possible and desirable to retain the 3.7 behavior for my use >> case (which needs to give the same result for this input on 3.7 and 3.8). > > Answering my own question: the behavior was changed by https://github.com/python/cpython/pull/9731. Since this patch, Mark Shannon has revised line numbering and tracing and replaced the internal lineno data structure. Your example code still outputs 2. So Mark either missed this case or considers it correct. -- Terry Jan Reedy From mishrasamir2004 at gmail.com Sat May 1 04:53:52 2021 From: mishrasamir2004 at gmail.com (mishrasamir2004 at gmail.com) Date: Sat, 1 May 2021 14:23:52 +0530 Subject: for the requirement of pygames Message-ID: Sir/madam , I'm a user of python, and I'm requesting you to provide me pygames . Samir Mishra Phone no. = +91 7044421272 Sent from [1]Mail for Windows 10 References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 From martinp.dipaola at gmail.com Sat May 1 10:41:30 2021 From: martinp.dipaola at gmail.com (Martin Di Paola) Date: Sat, 1 May 2021 14:41:30 +0000 Subject: byexample: free, open source tool to find snippets of code in your docs and execute them as regression tests Message-ID: <20210501144130.nu5hxpan6c6uvpnq@gmail.com> Hi everyone, I would like to share a free, open source tool with you that I've been developing in the last few years. You'll be probably familiar with things like this in the Python documentation: ``` >>> 1 + 3 4 ``` byexample will find those snippets, it will execute "1 + 3" and the output will be compared with the expected one (the "4") so you can know that your docs are in sync with your code. If you are familiar with Python's doctest module, it is the same idea but after a few years of using it I found some limitations that I tried to break. That's how byexample was born: it allows you find and execute the snippets/examples written in different languages in different files. You could run Ruby and C++ code written in the docstrings of your Python source code or in a fenced code block of a Markdown file. You could "capture" the output of one example and "paste" it into another as a way to share data between examples. ``` $ cat somefile # a Shell example ( will capture a word) Lorem ipsum sit amet. >>> "" == "dolor" # Python example # byexample: +paste True ``` You could even "type" text when your example is interactive and requires some input: ``` >>> name = input("your name please: ") # byexample: +type your name please: [john] >>> print(name) john ``` There are a few more features but this email is long enough. The full set of features and tutorials are in https://byexamples.github.io (by the way, the examples in that web page are the tests of byexample!) Repo: https://github.com/byexamples/byexample (feel free to submit any issue or question) You can install it with pip: pip install byexample And if you are a fan of Python's doctest (as I am), there is a compatibility mode that you may want to check: https://byexamples.github.io/byexample/recipes/python-doctest I would like to receive your feedback. Thanks for your time! Martin. From korn.moffle at hotmail.com Sat May 1 19:14:00 2021 From: korn.moffle at hotmail.com (Korn Moffle) Date: Sat, 1 May 2021 23:14:00 +0000 Subject: Removing For-Loop Message-ID: Hi, I have been banging my head against the wall - I know I can get rid of for-loop here, but can't figure out how. Please help! I suspect I can do np.sum on the whole adGroup but I am lacking the imagination to visualize it. for ind in range(adGroup.shape[0]): row = adGroup.iloc[ind, :] current_hashes, current_cf_id = adArrayHashes[row['hash_seq_array'].astype(int)], [row['cf_id']] # calculaton hashes_diff = np.array(list(map(lambda x: np.sum(np.not_equal(start_hashes[x:x + len(current_hashes)], current_hashes), axis=1), range(58) ))) hashes_diff_scores = np.sum(hashes_diff <= IMG_DIFFER, axis=1) hashes_diff_mask = hashes_diff_scores >= SEQ_THRESHOLD if any(hashes_diff_mask): presumptive_cf_ids.append(current_cf_id[0]) presumptive_scores.append(max(hashes_diff_scores)) if queue != 0: queue.put((presumptive_cf_ids, presumptive_scores)) # return presumptive_cf_ids, presumptive_scores return Sent from Outlook From osmanysalsero at gmail.com Mon May 3 10:16:22 2021 From: osmanysalsero at gmail.com (Osmany Guerra) Date: Mon, 3 May 2021 10:16:22 -0400 Subject: Python language packages isn't working in Visual Studio Code Message-ID: Hi, I have problem with the python interpreter in the Visual Studio Code. It was running ok, but now isn't working. I have downloaded, installed and unistalled several times without having results. How could I fix that? I'm using windows 10 64-bit, VSCode x64-1.55.2, and Python 3.9.4. I'm sending you a picture of my laptop screen too. Waiting for your reply Regards Osmany From mjwilliams at gmail.com Mon May 3 13:45:22 2021 From: mjwilliams at gmail.com (Mike Lee Williams) Date: Mon, 3 May 2021 10:45:22 -0700 (PDT) Subject: Decoratored functions parsed differently by ast stdlib between 3.7 and 3.8 In-Reply-To: References: <607dcc99-fac7-436a-a4e3-4620e9cf2225n@googlegroups.com> Message-ID: On Monday, May 3, 2021 at 10:41:14 AM UTC-7, Terry Reedy wrote: > > Answering my own question: the behavior was changed by https://github.com/python/cpython/pull/9731. > Since this patch, Mark Shannon has revised line numbering and tracing > and replaced the internal lineno data structure. Your example code still > outputs 2. So Mark either missed this case or considers it correct. Yes, reading through the correspondence it's clear that the view is that the old behavior was a bug and this change is a bugfix. I can work around this for my use case. From inhahe at gmail.com Mon May 3 13:59:08 2021 From: inhahe at gmail.com (inhahe) Date: Mon, 3 May 2021 13:59:08 -0400 Subject: Python language packages isn't working in Visual Studio Code In-Reply-To: References: Message-ID: I don't think attaching images works on this kind of list. Maybe send a link to it.. On Mon, May 3, 2021 at 1:51 PM Osmany Guerra wrote: > Hi, I have problem with the python interpreter in the Visual Studio Code. > It was running ok, but now isn't working. I have downloaded, installed and > unistalled several times without having results. How could I fix that? > I'm using windows 10 64-bit, VSCode x64-1.55.2, and Python 3.9.4. > I'm sending you a picture of my laptop screen too. > Waiting for your reply > Regards Osmany > -- > https://mail.python.org/mailman/listinfo/python-list > From joel.goldstick at gmail.com Mon May 3 15:22:55 2021 From: joel.goldstick at gmail.com (Joel Goldstick) Date: Mon, 3 May 2021 15:22:55 -0400 Subject: Python language packages isn't working in Visual Studio Code In-Reply-To: References: Message-ID: On Mon, May 3, 2021 at 2:00 PM inhahe wrote: > > I don't think attaching images works on this kind of list. Maybe send a > link to it.. > > On Mon, May 3, 2021 at 1:51 PM Osmany Guerra > wrote: > > > Hi, I have problem with the python interpreter in the Visual Studio Code. > > It was running ok, but now isn't working. I have downloaded, installed and > > unistalled several times without having results. How could I fix that? > > I'm using windows 10 64-bit, VSCode x64-1.55.2, and Python 3.9.4. > > I'm sending you a picture of my laptop screen too. > > Waiting for your reply > > Regards Osmany > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > -- > https://mail.python.org/mailman/listinfo/python-list Better yet, cut and paste your relevant text in your email message here -- Joel Goldstick http://joelgoldstick.com/blog http://cc-baseballstats.info/stats/birthdays From lukasz at langa.pl Mon May 3 19:26:39 2021 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Tue, 4 May 2021 01:26:39 +0200 Subject: [RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available Message-ID: This has been a very busy day for releases and on behalf of the Python development community we?re happy to announce the availability of three new Python releases. Python 3.10 is now in Beta Get it here: Python 3.10.0b1 Python 3.10 is still in development. 3.10.0b1 is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.10 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is have no ABI changes after beta 4 and as few code changes as possible after 3.10.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.10 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next pre-release, the second beta release of Python 3.10, will be 3.10.0b2. It is currently scheduled for 2021-05-25. Please see PEP 619 for details. Development Begins on Python 3.11 With Python 3.10 moving to beta, it received its own 3.10 branch in the repository . All new features are now targeting Python 3.11, to be released in October 2022. Using the opportunity with the creation of the 3.10 branch, we renamed the master branch of the repository to main. It?s been a bit rocky but looks like we?re open for business. Please rename the main branch of your personal fork using the guide GitHub will give you when you go to your fork?s main page. In case of any outstanding issues, please contact the 3.11 RM . Python 3.9.5 Get it here: Python 3.9.5 Python 3.9.5 is the newest major stable release of the Python programming language, and it contains many new features and optimizations. There?s been 111 commits since 3.9.4 which is a similar amount compared to 3.8 at the same stage of the release cycle. See the change log for details. On macOS, we encourage you to use the universal2 variant whenever possible. The legacy 10.9+ Intel-only variant will not be provided for Python 3.10 and the universal2 variant will become the default download for future 3.9.x releases. You may need to upgrade third-party components, like pip, to later versions once they are released. You may experience differences in behavior in IDLE and other Tk-based applications due to using the newer version of Tk. As always, if you encounter problems when using this installer variant, please check https://bugs.python.org for existing reports and for opening new issues. The next Python 3.9 maintenance release will be 3.9.6, currently scheduled for 2021-06-28. The Last Regular Bugfix Release of Python 3.8 Get it here: Python 3.8.10 According to the release calendar specified in PEP 569 , Python 3.8.10 is the final regular maintenance release. Starting now, the 3.8 branch will only accept security fixes and releases of those will be made in source-only form until October 2024. To keep receiving regular bug fixes, please upgrade to Python 3.9. Compared to the 3.7 series, this last regular bugfix release is relatively dormant at 92 commits since 3.8.9. Version 3.7.8, the final regular bugfix release of Python 3.7, included 187 commits. But there?s a bunch of important updates here regardless, the biggest being macOS Big Sur and Apple Silicon build support. This work would not have been possible without the effort of Ronald Oussoren, Ned Deily, Maxime B?langer, and Lawrence D?Anna from Apple. Thank you! Take a look at the change log for details. We hope you enjoy the new releases Your friendly release team, Ned Deily @nad Steve Dower @steve.dower Pablo Galindo Salgado @pablogsal ?ukasz Langa @ambv From sdoherty82 at gmail.com Tue May 4 02:08:04 2021 From: sdoherty82 at gmail.com (Sian Doherty) Date: Tue, 4 May 2021 16:08:04 +1000 Subject: uninstall In-Reply-To: <0c5f50d8-9ce0-bbd9-e5d7-f4423334bb82@wichmann.us> References: <608b5659.1c69fb81.f933d.3bb2@mx.google.com> <0c5f50d8-9ce0-bbd9-e5d7-f4423334bb82@wichmann.us> Message-ID: Thanks for the advice. I found a stack overflow post that suggested just removing manually and cleaning out the registry too. I think I have it under control but I haven't gotten around to reinstalling it yet. On Sun, 2 May 2021, 10:05 Mats Wichmann, wrote: > On 4/29/21 6:59 PM, Sian Doherty wrote: > > I?m trying to uninstall Python 3.8.5 on Windows 10 Pro 20H2 as I had > multiple environments and as a result corrupted them. > > > > When I uninstall from control panel, it takes less than a second and > says it uninstalled successfully but I can still access python through the > command prompt by typing python. > > > > Is there a different way to uninstall that isn?t through the control > panel? I would have thought I would do that and then clean out the registry > separately and the %localappdata%\pip folder. > > > > Any thoughts? > > There are some uninstall tools, of varying quality. Some depend on you > having been running them while the install happened, which is probably > not the case for you. Once you've messed up Windows' idea of the install > subsystem, it's not that easy to recover. Though some may disagree, > that's not really Python's fault, the install system seems pretty > fragile. Sometimes if the the files needed to process the uninstall > have been removed but the uninstall itself didn't finish you're in > trouble - which isn't really the fault of the install system, but then > you ask how that scenario arose? anyway... > > You could look for this tool: > MicrosoftProgram_Install_and_Uninstall.meta.diagcab - an Internet search > should find it. it usually does a fairly good job of cleaning up messes > (well - it's worked well for me in a few dire situations). > From killet at killetsoft.de Tue May 4 04:08:36 2021 From: killet at killetsoft.de (Fred Killet) Date: Tue, 4 May 2021 01:08:36 -0700 (PDT) Subject: Geodetic Development Kit Message-ID: <06c84c24-eb4a-4048-92cc-d264bc56d16fn@googlegroups.com> Dear software developers, here I post a hint for people who develop programs with geodetic functionality like coordinate transformations, datum shifts or distance calculations. For this you can easily include ready for use geodetic functions from my Geodetic Development Kit GeoDLL. The Dynamic Link Library can be used with almost all modern programming languages like C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office and so on. Examples and interfaces are available for many programming languages. GeoDLL is a professional Geodetic Development Kit or Geodetic Function Library for worldwide 2D and 3D coordinate transformations and datum shifts with highest accuracy. Also: Helmert and Molodensky parameters, NTv2, HARN, INSPIRE, EPSG, elevation model (DEM), distance and time zone calculation, meridian convergence and much more. GeoDLL is available as 32bit and 64bit DLL and as C / C++ source code. The DLL is very fast, secure and compact thanks to the consistent development in C / C++ with Microsoft Visual Studio. The geodetic functions are available in 32bit and 64bit architecture. All functions are prepared for multithreading and server operating. You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm Notes about the NTv2 support can be found here: https://www.killetsoft.de/t_ntv2_e.htm Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm Best regards and stay healthy! Fred Email: https://www.killetsoft.de/email.htm?lan=e&btr=News From qberz2005 at gmail.com Tue May 4 10:45:29 2021 From: qberz2005 at gmail.com (Quentin Bock) Date: Tue, 4 May 2021 10:45:29 -0400 Subject: library not initialized pygame Message-ID: code: #imports and variable for loop import pygame running = True #initializes pygame pygame.init() pygame.mixer.init() pygame.font.init() #creates the pygame window screen = pygame.display.set_mode((1200, 800)) #Title and Icon of window pygame.display.set_caption("3.02 Project") icon = pygame.image.load('3.02 icon.png') pygame.display.set_icon(icon) #setting up font pygame.font.init() font = pygame.font.Font('C:\Windows\Fonts\OCRAEXT.ttf', 16) font_x = 10 font_y = 40 items_picked_up = 0 items_left = 3 def main(): global running, event #Game Loop while running: #sets screen color to black screen.fill((0, 0, 0)) #checks if the user exits the window for event in pygame.event.get(): if event.type == pygame.QUIT: running = False pygame.quit() def music(): pygame.mixer.init() pygame.font.init() pygame.mixer.music.load('onoken - load.mp3') #places song into queue pygame.mixer.music.play(10, 0, 3) #fist number indicates the loop amount, second is the offset of the song, third is fading the song in song_text = font.render("Song: onoken - load", True, (255, 255, 255)) screen.blit(song_text, (10, 750)) music() def display_instruction(x, y): pygame.font.init() pygame.mixer.init() instructions = font.render("Each level contains 3 items you must pick up in each room.", True, (255, 255, 255)) instructions_2 = font.render("When you have picked up 3 items, you will advance to the next room, there are 3.", True, (255, 255, 255)) instructions_3 = font.render("You will be able to change the direction you are looking in the room, this allows you to find different objects.", True, (255, 255, 255)) screen.blit(instructions, (10, 40)) screen.blit(instructions_2, (10, 60)) screen.blit(instructions_3, (10, 80)) display_instruction(font_x, font_y) pygame.display.update() main() if you try to run this, I'm aware that the icon and music file will not load because you don't have the file on your device, but if it somehow works for you please let me know, and if you think there's any difference between my code and when you ran it I need this figured out. Thanks From menyland at gmail.com Tue May 4 22:20:32 2021 From: menyland at gmail.com (Chris Nyland) Date: Tue, 4 May 2021 22:20:32 -0400 Subject: Transistion from module to package and __init__.py Message-ID: Hello, I have a design question that for me primarily occurs when I have a module that needs to transition to a package. Lets assume I have module that services a database. Initially the module just has some functions to pull data out of the database format them etc. As the project grows I add tables some of the tables have static data or initialization data that are stored in CSVs. I build functions that initialize the database a schema file is now used. Now my module is still the only Python code file I have but I have these other data files the module needs, time to make a package. So naturally I make a package folder called database, put and empty __init__.py, in goes my database module and all resource files. Here is where I my primary design question comes in. As organized now as described to import and use the package I need from database import database or I have to put in the init file from database import * Either of these still leaves a database.database namespace laying about and to me it just seems untidy. So for a while now I have taken to converting my module, in this example database.py, to the __init__.py of the package. I remember reading years back that having code in the __init__.py was bad practice but I can't remember reading for any specific reason. So then I ask is there anything in fact wrong with this practice? I have probably a dozen packages now that are used internal to my organization that follow this pattern and I haven't encountered any issues. So I was hoping to get feed back from a wider audience about if there are any issues with this type of design that I just haven't encounter yet or find out what other people do with this same problem. Thanks Chris From menyland at gmail.com Tue May 4 22:43:02 2021 From: menyland at gmail.com (Chris Nyland) Date: Tue, 4 May 2021 22:43:02 -0400 Subject: uninstall In-Reply-To: References: <608b5659.1c69fb81.f933d.3bb2@mx.google.com> <0c5f50d8-9ce0-bbd9-e5d7-f4423334bb82@wichmann.us> Message-ID: So it seems counter intuitive but you might also have luck just reinstalling Python3.8 back over top. If the uninstall was botch then that should put everything back in place and then you can just run the uninstall again and see if it clears out this time. Otherwise I agree with stack overflow you can just go in and do it manually. If you have multiple Python installs I would recommend make sure to use the py launcher instead of adding any of the Pythons to the Windows path. I also don't like the new default install location in the program folders for development machines and find that it can sometimes cause conflicts so for those machines where I need multiple versions I still install Python on the root of the the C drive or and additional hard drive and name the folders PythonXX_32 or 64 depending on the type of install where XX is of course the major and minor version 36, 37, 38 etc. Then I use py -3.6 and so on to execute the different installs from the command line. On Tue, May 4, 2021 at 2:10 AM Sian Doherty wrote: > Thanks for the advice. I found a stack overflow post that suggested just > removing manually and cleaning out the registry too. I think I have it > under control but I haven't gotten around to reinstalling it yet. > > On Sun, 2 May 2021, 10:05 Mats Wichmann, wrote: > > > On 4/29/21 6:59 PM, Sian Doherty wrote: > > > I?m trying to uninstall Python 3.8.5 on Windows 10 Pro 20H2 as I had > > multiple environments and as a result corrupted them. > > > > > > When I uninstall from control panel, it takes less than a second and > > says it uninstalled successfully but I can still access python through > the > > command prompt by typing python. > > > > > > Is there a different way to uninstall that isn?t through the control > > panel? I would have thought I would do that and then clean out the > registry > > separately and the %localappdata%\pip folder. > > > > > > Any thoughts? > > > > There are some uninstall tools, of varying quality. Some depend on you > > having been running them while the install happened, which is probably > > not the case for you. Once you've messed up Windows' idea of the install > > subsystem, it's not that easy to recover. Though some may disagree, > > that's not really Python's fault, the install system seems pretty > > fragile. Sometimes if the the files needed to process the uninstall > > have been removed but the uninstall itself didn't finish you're in > > trouble - which isn't really the fault of the install system, but then > > you ask how that scenario arose? anyway... > > > > You could look for this tool: > > MicrosoftProgram_Install_and_Uninstall.meta.diagcab - an Internet search > > should find it. it usually does a fairly good job of cleaning up messes > > (well - it's worked well for me in a few dire situations). > > > -- > https://mail.python.org/mailman/listinfo/python-list > From rasigkoson at gmail.com Tue May 4 23:55:26 2021 From: rasigkoson at gmail.com (Rasig Kosonmontri) Date: Wed, 5 May 2021 10:55:26 +0700 Subject: Unsubscribe/can't login Message-ID: Hi I wanted to unsubscribe from the python mailing list because I has been sending me countless mails over the months but when I try to login on my browser it doesn't recognize this email as a user even though the mails that are coming it are to this email address If there's anything thing to fix or anyway to do this manually please let me know Thanks From gheskett at shentel.net Wed May 5 05:34:55 2021 From: gheskett at shentel.net (Gene Heskett) Date: Wed, 5 May 2021 05:34:55 -0400 Subject: Unsubscribe/can't login In-Reply-To: References: Message-ID: <202105050534.55755.gheskett@shentel.net> On Tuesday 04 May 2021 23:55:26 Rasig Kosonmontri wrote: > Hi I wanted to unsubscribe from the python mailing list because I has > been sending me countless mails over the months but when I try to > login on my browser it doesn't recognize this email as a user even > though the mails that are coming it are to this email address > If there's anything thing to fix or anyway to do this manually please > let me know > Thanks That is usually the security feature of the mailing list software, in that often the header info is used to verify that you are not maliciously unsubscribiing someone else. Said in plainer english, if you have moved ISP's or changed browsers, you aren't you and you cannot unsub from a new ISP even if the mailing address is the same. Occasionally, you may be able to fix it by way of the password recovery facility, which will send you a one time pad access to change the pw, which may update that and allow you to unsub. In extremis, write a procmail recipe to send it to /dev/null. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page From __peter__ at web.de Wed May 5 06:42:55 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 12:42:55 +0200 Subject: Unsubscribe/can't login In-Reply-To: References: Message-ID: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> On 05/05/2021 05:55, Rasig Kosonmontri wrote: > Hi I wanted to unsubscribe from the python mailing list because I has been > sending me countless mails over the months but when I try to login on my > browser it doesn't recognize this email as a user even though the mails > that are coming it are to this email address > If there's anything thing to fix or anyway to do this manually please let > me know > Thanks Double-check that you are using the correct email address, then enter it in the last input field on https://mail.python.org/mailman/listinfo/python-list Hit the [Unsubscribe or edit options] button, and on the page that is now shown hit the [Unsubscribe] button. You should receive an email with a link that you can open in the browser to complete the process of unsubscribing. If that doesn't work try contacting python-list-owner at python.org for assistance. From __peter__ at web.de Wed May 5 06:42:55 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 12:42:55 +0200 Subject: Unsubscribe/can't login In-Reply-To: References: Message-ID: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> On 05/05/2021 05:55, Rasig Kosonmontri wrote: > Hi I wanted to unsubscribe from the python mailing list because I has been > sending me countless mails over the months but when I try to login on my > browser it doesn't recognize this email as a user even though the mails > that are coming it are to this email address > If there's anything thing to fix or anyway to do this manually please let > me know > Thanks Double-check that you are using the correct email address, then enter it in the last input field on https://mail.python.org/mailman/listinfo/python-list Hit the [Unsubscribe or edit options] button, and on the page that is now shown hit the [Unsubscribe] button. You should receive an email with a link that you can open in the browser to complete the process of unsubscribing. If that doesn't work try contacting python-list-owner at python.org for assistance. From balglaas at dds.nl Wed May 5 07:03:58 2021 From: balglaas at dds.nl (Jan van den Broek) Date: Wed, 5 May 2021 11:03:58 +0000 (UTC) Subject: Unsubscribe/can't login References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: Perhaps there's something wrong on my side, but I'm seeing this message twice: Msg-ID: mailman.145.1620211376.3087.python-list at python.org Return-Path: __peter__ at web.de and Msg-ID: mailman.146.1620211381.3087.python-list at python.org Return-Path: python-python-list at m.gmane-mx.org -- Jan v/d Broek balglaas at dds.nl From __peter__ at web.de Wed May 5 08:58:11 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 14:58:11 +0200 Subject: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 05/05/2021 13:03, Jan van den Broek wrote: > On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: > > Perhaps there's something wrong on my side, but I'm > seeing this message twice: > > Msg-ID: mailman.145.1620211376.3087.python-list at python.org > Return-Path: __peter__ at web.de > > and > > Msg-ID: mailman.146.1620211381.3087.python-list at python.org > Return-Path: python-python-list at m.gmane-mx.org Sorry for the inconvenience. Does that happen with all my messages? I'm reading the mailing list via news.gmaneio. When I had a private complaint about duplicate messages some time ago I switched from "Reply to All" to "Reply to List" in Thunderbird and was hoping that this would avoid the problem. If it is only this message I may have hit "Reply to All" accidentally. If it happens with all my messages, maybe there is a Thunderbird/gmane user who can tell me how to fix my setup. From __peter__ at web.de Wed May 5 08:58:11 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 14:58:11 +0200 Subject: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 05/05/2021 13:03, Jan van den Broek wrote: > On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: > > Perhaps there's something wrong on my side, but I'm > seeing this message twice: > > Msg-ID: mailman.145.1620211376.3087.python-list at python.org > Return-Path: __peter__ at web.de > > and > > Msg-ID: mailman.146.1620211381.3087.python-list at python.org > Return-Path: python-python-list at m.gmane-mx.org Sorry for the inconvenience. Does that happen with all my messages? I'm reading the mailing list via news.gmaneio. When I had a private complaint about duplicate messages some time ago I switched from "Reply to All" to "Reply to List" in Thunderbird and was hoping that this would avoid the problem. If it is only this message I may have hit "Reply to All" accidentally. If it happens with all my messages, maybe there is a Thunderbird/gmane user who can tell me how to fix my setup. From balglaas at dds.nl Wed May 5 10:04:38 2021 From: balglaas at dds.nl (Jan van den Broek) Date: Wed, 5 May 2021 14:04:38 +0000 (UTC) Subject: Unsubscribe/can't login References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: > On 05/05/2021 13:03, Jan van den Broek wrote: >> On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: >> >> Perhaps there's something wrong on my side, but I'm >> seeing this message twice: [Schnipp] > Sorry for the inconvenience. > > Does that happen with all my messages? I'm reading the mailing list via > news.gmaneio. I can't tell if this happens with _all_ your messages, but it happened with this reply. Message-ID: Return-Path: and Message-ID: Return-Path: <__peter__ at web.de> -- Jan v/d Broek balglaas at dds.nl From ethan at stoneleaf.us Wed May 5 10:10:25 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 5 May 2021 07:10:25 -0700 Subject: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 5/5/21 5:58 AM, Peter Otten wrote: > On 05/05/2021 13:03, Jan van den Broek wrote: >> On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: >> Perhaps there's something wrong on my side, but I'm >> seeing this message twice: >> >> Msg-ID: mailman.145.1620211376.3087.python-list at python.org >> Return-Path: __peter__ at web.de >> >> and >> >> Msg-ID: mailman.146.1620211381.3087.python-list at python.org >> Return-Path: python-python-list at m.gmane-mx.org > > Sorry for the inconvenience. > > Does that happen with all my messages? I'm reading the mailing list via > news.gmaneio. I see your messages twice (occasionally with other posters as well). I have no idea how to fix it. :( -- ~Ethan~ From __peter__ at web.de Wed May 5 10:39:51 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 16:39:51 +0200 Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 05/05/2021 16:10, Ethan Furman wrote: > I see your messages twice (occasionally with other posters as well).? I > have no idea how to fix it.? :( OK, I'll try another option from Thunderbird's context menu: Followup to Newsgroup. Does that appear once or twice? In theory it should go to the newsgroup only which would mirror it to the list. From ethan at stoneleaf.us Wed May 5 11:53:22 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 5 May 2021 08:53:22 -0700 Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: <087eccea-a051-b83f-f9e4-76fd822d8901@stoneleaf.us> On 5/5/21 7:39 AM, Peter Otten wrote: > On 05/05/2021 16:10, Ethan Furman wrote: >> I see your messages twice (occasionally with other posters as well). I have no idea how to fix it. :( > > OK, I'll try another option from Thunderbird's context menu: Followup to Newsgroup. > > Does that appear once or twice? > > In theory it should go to the newsgroup only which would mirror it to the list. Only once. -- ~Ethan~ From flibble at i42.invalidwibblegrok.co.uk Wed May 5 11:56:56 2021 From: flibble at i42.invalidwibblegrok.co.uk (Mr Flibble) Date: Wed, 5 May 2021 16:56:56 +0100 Subject: neoPython : Fastest Python Implementation: Coming Soon Message-ID: neoPython : Fastest Python Implementation: Coming Soon Message ends. /Flibble -- ? From jf_byrnes at comcast.net Wed May 5 11:57:04 2021 From: jf_byrnes at comcast.net (Jim Byrnes) Date: Wed, 5 May 2021 10:57:04 -0500 Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 5/5/21 9:39 AM, Peter Otten wrote: > On 05/05/2021 16:10, Ethan Furman wrote: > >> I see your messages twice (occasionally with other posters as well). >> I have no idea how to fix it.? :( > > OK, I'll try another option from Thunderbird's context menu: Followup to > Newsgroup. > > Does that appear once or twice? > > In theory it should go to the newsgroup only which would mirror it to > the list. > FWIW, none of the messages in this this thread are dupes for me and I can't remember the last time I saw a dupe from you. Regards, Jim From rosuav at gmail.com Wed May 5 12:02:02 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 May 2021 02:02:02 +1000 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: On Thu, May 6, 2021 at 2:01 AM Mr Flibble wrote: > > neoPython : Fastest Python Implementation: Coming Soon > > Message ends. > > /Flibble > My breath: not being held. Message ends. ChrisA From flibble at i42.invalidwibblegrok.co.uk Wed May 5 12:10:37 2021 From: flibble at i42.invalidwibblegrok.co.uk (Mr Flibble) Date: Wed, 5 May 2021 17:10:37 +0100 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: <0szkI.195451$i669.143154@fx02.ams4> On 05/05/2021 17:02, Chris Angelico wrote: > On Thu, May 6, 2021 at 2:01 AM Mr Flibble > wrote: >> >> neoPython : Fastest Python Implementation: Coming Soon >> >> Message ends. >> >> /Flibble >> > > My breath: not being held. > > Message ends. Why? The currently extant Python implementations contribute to climate change as they are so inefficient; CPython is so egregious it is best called a bag of shite. Making a faster implementation isn't in the least bit a stretch. Message ends. /Flibble -- ? From flibble at i42.invalidwibblegrok.co.uk Wed May 5 12:21:46 2021 From: flibble at i42.invalidwibblegrok.co.uk (Mr Flibble) Date: Wed, 5 May 2021 17:21:46 +0100 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: On 05/05/2021 17:02, Chris Angelico wrote: > On Thu, May 6, 2021 at 2:01 AM Mr Flibble > wrote: >> >> neoPython : Fastest Python Implementation: Coming Soon >> >> Message ends. >> >> /Flibble >> > > My breath: not being held. > > Message ends. Why? The currently extant Python implementations are so inefficient they contribute to climate change; CPython is particularly egregious. Making a faster implementation isn't in the least bit a stretch. Message ends. /Flibble -- ? From ikorot01 at gmail.com Wed May 5 12:36:40 2021 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 5 May 2021 11:36:40 -0500 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: Hi, On Wed, May 5, 2021 at 11:27 AM Mr Flibble < flibble at i42.invalidwibblegrok.co.uk> wrote: > On 05/05/2021 17:02, Chris Angelico wrote: > > On Thu, May 6, 2021 at 2:01 AM Mr Flibble > > wrote: > >> > >> neoPython : Fastest Python Implementation: Coming Soon > >> > >> Message ends. > >> > >> /Flibble > >> > > > > My breath: not being held. > > > > Message ends. > > Why? The currently extant Python implementations are so inefficient they > contribute to climate change; CPython is particularly egregious. Making a > faster > implementation isn't in the least bit a stretch. > > Message ends. > Why do you use {C}Python in the first place if its so inefficient? Why not use C or even Assembly? And "coming soon" - is a little weird. Why not say "coming 10 May 2021 at 23:59:59"? /Message ends. Thank you. > /Flibble > > -- > ? > -- > https://mail.python.org/mailman/listinfo/python-list > From flibble at i42.invalidwibblegrok.co.uk Wed May 5 12:38:24 2021 From: flibble at i42.invalidwibblegrok.co.uk (Mr Flibble) Date: Wed, 5 May 2021 17:38:24 +0100 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: <5e6c327d-ee80-4e88-8c9e-bc739cb4e356n@googlegroups.com> References: <5e6c327d-ee80-4e88-8c9e-bc739cb4e356n@googlegroups.com> Message-ID: <3SzkI.198724$i669.178635@fx02.ams4> On 05/05/2021 17:33, Mark Lawrence wrote: > On Wednesday, May 5, 2021 at 4:57:13 PM UTC+1, Mr Flibble wrote: >> neoPython : Fastest Python Implementation: Coming Soon >> >> Message ends. >> >> /Flibble >> >> -- >> ? > Dedicated to you and all like you https://www.youtube.com/watch?v=X15PsqN0DHc ORLY? If anyone is thick around here it is the typical Python user such as yourself. /Flibble -- ? From flibble at i42.invalidwibblegrok.co.uk Wed May 5 12:40:34 2021 From: flibble at i42.invalidwibblegrok.co.uk (Mr Flibble) Date: Wed, 5 May 2021 17:40:34 +0100 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: <5UzkI.199148$i669.126718@fx02.ams4> On 05/05/2021 17:36, Igor Korot wrote: > Hi, > > On Wed, May 5, 2021 at 11:27 AM Mr Flibble < > flibble at i42.invalidwibblegrok.co.uk> wrote: > >> On 05/05/2021 17:02, Chris Angelico wrote: >>> On Thu, May 6, 2021 at 2:01 AM Mr Flibble >>> wrote: >>>> >>>> neoPython : Fastest Python Implementation: Coming Soon >>>> >>>> Message ends. >>>> >>>> /Flibble >>>> >>> >>> My breath: not being held. >>> >>> Message ends. >> >> Why? The currently extant Python implementations are so inefficient they >> contribute to climate change; CPython is particularly egregious. Making a >> faster >> implementation isn't in the least bit a stretch. >> >> Message ends. >> > > Why do you use {C}Python in the first place if its so inefficient? > Why not use C or even Assembly? > > And "coming soon" - is a little weird. > Why not say "coming 10 May 2021 at 23:59:59"? > > /Message ends. > > Thank you. But I don't use Python, I use C++ (probably the best programming language in the world). /Flibble -- ? From ikorot01 at gmail.com Wed May 5 13:02:43 2021 From: ikorot01 at gmail.com (Igor Korot) Date: Wed, 5 May 2021 12:02:43 -0500 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: <5UzkI.199148$i669.126718@fx02.ams4> References: <5UzkI.199148$i669.126718@fx02.ams4> Message-ID: Hi, On Wed, May 5, 2021 at 11:47 AM Mr Flibble < flibble at i42.invalidwibblegrok.co.uk> wrote: > On 05/05/2021 17:36, Igor Korot wrote: > > Hi, > > > > On Wed, May 5, 2021 at 11:27 AM Mr Flibble < > > flibble at i42.invalidwibblegrok.co.uk> wrote: > > > >> On 05/05/2021 17:02, Chris Angelico wrote: > >>> On Thu, May 6, 2021 at 2:01 AM Mr Flibble > >>> wrote: > >>>> > >>>> neoPython : Fastest Python Implementation: Coming Soon > >>>> > >>>> Message ends. > >>>> > >>>> /Flibble > >>>> > >>> > >>> My breath: not being held. > >>> > >>> Message ends. > >> > >> Why? The currently extant Python implementations are so inefficient they > >> contribute to climate change; CPython is particularly egregious. Making > a > >> faster > >> implementation isn't in the least bit a stretch. > >> > >> Message ends. > >> > > > > Why do you use {C}Python in the first place if its so inefficient? > > Why not use C or even Assembly? > > > > And "coming soon" - is a little weird. > > Why not say "coming 10 May 2021 at 23:59:59"? > > > > /Message ends. > > > > Thank you. > > But I don't use Python, I use C++ (probably the best programming language > in the > world). > Posting in the python community implies that you are using {c}python. Otherwise you will not be posting here. And definitely would be waiting until you can show the "best python implementation ever". And C++ is also bad - Assembly is so much better and so much more efficient. /Message ends. Thank you. > /Flibble > > -- > ? > -- > https://mail.python.org/mailman/listinfo/python-list > From ethan at stoneleaf.us Wed May 5 14:02:35 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 5 May 2021 11:02:35 -0700 Subject: Transistion from module to package and __init__.py In-Reply-To: References: Message-ID: <2a47540c-c9b0-cf84-a177-879d0b642afd@stoneleaf.us> On 5/4/21 7:20 PM, Chris Nyland wrote: > Here is > where I my primary design question comes in. As organized now as described > to import and use the package I need > > from database import database > > or I have to put in the init file > > from database import * > > Either of these still leaves a database.database namespace laying about and > to me it just seems untidy. So for a while now I have taken to converting > my module, in this example database.py, to the __init__.py of the package. > So I was hoping to get > feed back from a wider audience about if there are any issues with this > type of design that I just haven't encounter yet or find out what other > people do with this same problem. This is the same method I use, and it works fine for smaller packages. I do have one package, dbf, that I am in the process of converting to multiple files simply because there is so much (10k lines for me, YMMV). -- ~Ethan~ From balglaas at dds.nl Wed May 5 14:07:16 2021 From: balglaas at dds.nl (Jan van den Broek) Date: Wed, 5 May 2021 18:07:16 +0000 (UTC) Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 2021-05-05, Jim Byrnes wrote: > On 5/5/21 9:39 AM, Peter Otten wrote: >> On 05/05/2021 16:10, Ethan Furman wrote: >> >>> I see your messages twice (occasionally with other posters as well). >>> I have no idea how to fix it.?? :( >> >> OK, I'll try another option from Thunderbird's context menu: Followup to >> Newsgroup. >> >> Does that appear once or twice? >> >> In theory it should go to the newsgroup only which would mirror it to >> the list. >> > > FWIW, none of the messages in this this thread are dupes for me and I > can't remember the last time I saw a dupe from you. Are you reading this via the mailinglist or Usenet? -- Jan v/d Broek balglaas at dds.nl From balglaas at dds.nl Wed May 5 14:08:02 2021 From: balglaas at dds.nl (Jan van den Broek) Date: Wed, 5 May 2021 18:08:02 +0000 (UTC) Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: > On 05/05/2021 16:10, Ethan Furman wrote: > >> I see your messages twice (occasionally with other posters as well).?? I >> have no idea how to fix it.?? :( > > OK, I'll try another option from Thunderbird's context menu: Followup to > Newsgroup. > > Does that appear once or twice? Here, once. -- Jan v/d Broek balglaas at dds.nl From bschollnick at schollnick.net Wed May 5 14:17:23 2021 From: bschollnick at schollnick.net (Benjamin Schollnick) Date: Wed, 5 May 2021 14:17:23 -0400 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: <0szkI.195451$i669.143154@fx02.ams4> References: <0szkI.195451$i669.143154@fx02.ams4> Message-ID: > Why? The currently extant Python implementations contribute to climate change as they are so inefficient; That same argument can be made for every triple-AAA video game, game console, etc. Python is more efficient for some problem sets, and Python is less efficient for other problem sets. Please feel free to come out with NeoPython. When you are done, and it is backward compatible with existing Python code, I?ll be happy to benchmark it against Native python. But don?t blame Python for global climate change. There are plenty of bigger ?causations? to Global climate change, then a freakin? computer programming language. - Benjamin From ianhclark510 at gmail.com Wed May 5 14:27:38 2021 From: ianhclark510 at gmail.com (Ian Clark) Date: Wed, 5 May 2021 11:27:38 -0700 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: <0szkI.195451$i669.143154@fx02.ams4> Message-ID: I wish you best of luck, on top of everything else it looks like the neopython namespace has already been eaten up by some crypto project On Wed, May 5, 2021 at 11:18 AM Benjamin Schollnick < bschollnick at schollnick.net> wrote: > > Why? The currently extant Python implementations contribute to climate > change as they are so inefficient; > > That same argument can be made for every triple-AAA video game, game > console, etc. > > Python is more efficient for some problem sets, and Python is less > efficient for other problem sets. > > Please feel free to come out with NeoPython. When you are done, and it is > backward compatible with existing Python code, I?ll be happy to benchmark > it against Native python. But don?t blame Python for global climate > change. There are plenty of bigger ?causations? to Global climate change, > then a freakin? computer programming language. > > - Benjamin > > > -- > https://mail.python.org/mailman/listinfo/python-list > From dieter at handshake.de Wed May 5 14:30:47 2021 From: dieter at handshake.de (Dieter Maurer) Date: Wed, 5 May 2021 20:30:47 +0200 Subject: Transistion from module to package and __init__.py In-Reply-To: References: Message-ID: <24722.58455.530149.82644@ixdm.fritz.box> Chris Nyland wrote at 2021-5-4 22:20 -0400: > ... >So for a while now I have taken to converting >my module, in this example database.py, to the __init__.py of the package. >I remember reading years back that having code in the __init__.py was bad >practice but I can't remember reading for any specific reason. If your package is not a so called "namespace package" (this is a package components of which are stored in different places and can be installed independent from one another), then I see no reason not to put code into `__init__.py`. When I transform a module into a package, I start by using the former module as the new package's `__init__.py`. Later refactoring steps may move things out into separate modules/subpackages. From __peter__ at web.de Wed May 5 16:35:56 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 5 May 2021 22:35:56 +0200 Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 05/05/2021 20:08, Jan van den Broek wrote: > On 2021-05-05, Peter Otten <__peter__ at web.de> wrote: >> On 05/05/2021 16:10, Ethan Furman wrote: >> >>> I see your messages twice (occasionally with other posters as well).?? I >>> have no idea how to fix it.?? :( >> >> OK, I'll try another option from Thunderbird's context menu: Followup to >> Newsgroup. >> >> Does that appear once or twice? > > Here, once. OK, thanks Jan for bringing this up. From now on I'll try to use the "followup" option consistently. All, if you see duplicate posts more than once in a while you may inform me -- private mail is probably preferred by those who don't ;). From greg.ewing at canterbury.ac.nz Wed May 5 18:23:23 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 6 May 2021 10:23:23 +1200 Subject: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 6/05/21 12:58 am, Peter Otten wrote: > Does that happen with all my messages? I've seen two pairs of duplicate messages from you in this thread so far, with the same content but slightly different line wrapping. Looks like a gateway somewhere isn't recognising them as the same message. Reading comp.lang.python with Thunderbird. -- Greg From pbryan at anode.ca Wed May 5 20:31:02 2021 From: pbryan at anode.ca (Paul Bryan) Date: Wed, 05 May 2021 17:31:02 -0700 Subject: Proposal: Disconnect comp.lang.python from python-list Message-ID: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Given the ease of spoofing sender addresses, and its propensity for use in anonymous spamming and trolling (thanks python-list-owner for staying on top of that!), I propose to disconnect comp.lang.python from the python-list mailing list. Both would then operate independently. Paul From rosuav at gmail.com Wed May 5 20:36:44 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 May 2021 10:36:44 +1000 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: On Thu, May 6, 2021 at 10:32 AM Paul Bryan wrote: > > Given the ease of spoofing sender addresses, and its propensity for use > in anonymous spamming and trolling (thanks python-list-owner for > staying on top of that!), I propose to disconnect comp.lang.python from > the python-list mailing list. Both would then operate independently. > As someone who exclusively follows the mailing list, I selfishly want to support this, as it would notably improve the signal-to-noise ratio. But I'm aware that there are a number of good people who currently use the newsgroup, and those people would then be abandoned in the cess-pool. ChrisA From avigross at verizon.net Wed May 5 20:42:08 2021 From: avigross at verizon.net (Avi Gross) Date: Wed, 5 May 2021 20:42:08 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Chris, Given some notice, what stops anyone from joining the mailing list before there is a divorce between the forums? Everybody has trivial access to an email account these days and many mailers allow incoming messages that fit a pattern to be placed in some names folder to be read as a group if one wishes. The difference would include less spoofing but also the ability to remove and that are causing annoyance here. Avi -----Original Message----- From: Python-list On Behalf Of Chris Angelico Sent: Wednesday, May 5, 2021 8:37 PM To: Python Subject: Re: Proposal: Disconnect comp.lang.python from python-list On Thu, May 6, 2021 at 10:32 AM Paul Bryan wrote: > > Given the ease of spoofing sender addresses, and its propensity for > use in anonymous spamming and trolling (thanks python-list-owner for > staying on top of that!), I propose to disconnect comp.lang.python > from the python-list mailing list. Both would then operate independently. > As someone who exclusively follows the mailing list, I selfishly want to support this, as it would notably improve the signal-to-noise ratio. But I'm aware that there are a number of good people who currently use the newsgroup, and those people would then be abandoned in the cess-pool. ChrisA -- https://mail.python.org/mailman/listinfo/python-list From jon+usenet at unequivocal.eu Wed May 5 20:43:00 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 00:43:00 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: On 2021-05-06, Chris Angelico wrote: > On Thu, May 6, 2021 at 10:32 AM Paul Bryan wrote: >> >> Given the ease of spoofing sender addresses, and its propensity for use >> in anonymous spamming and trolling (thanks python-list-owner for >> staying on top of that!), I propose to disconnect comp.lang.python from >> the python-list mailing list. Both would then operate independently. >> > > As someone who exclusively follows the mailing list, I selfishly want > to support this, as it would notably improve the signal-to-noise > ratio. But I'm aware that there are a number of good people who > currently use the newsgroup, and those people would then be abandoned > in the cess-pool. Counter-proposal that I have suggested several times before that would solve both these problems: make the newsgroup moderated. (Or, I suppose, create comp.lang.python.moderated and gateway it to the mailing list, and disconnect comp.lang.python from the list.) From rosuav at gmail.com Wed May 5 20:46:07 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 May 2021 10:46:07 +1000 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: On Thu, May 6, 2021 at 10:43 AM Avi Gross via Python-list wrote: > > Chris, > > Given some notice, what stops anyone from joining the mailing list before > there is a divorce between the forums? Nothing! Nothing at all. That is, if you're talking about *people*. People are absolutely welcome to join. The reason the S/N would improve is all the non-people who post to the newsgroup. But there are some people who simply don't want to use the mailing list, and that's currently a fully-welcomed option. I won't name names, but there definitely are people who would prefer a newsreader, so the gateway is serving them very well. ChrisA From pbryan at anode.ca Wed May 5 21:23:36 2021 From: pbryan at anode.ca (Paul Bryan) Date: Wed, 05 May 2021 18:23:36 -0700 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> What's involved in moderating c.l.p? Would there be volunteers willing to do so? On Thu, 2021-05-06 at 00:43 +0000, Jon Ribbens via Python-list wrote: > On 2021-05-06, Chris Angelico wrote: > > On Thu, May 6, 2021 at 10:32 AM Paul Bryan wrote: > > > > > > Given the ease of spoofing sender addresses, and its propensity > > > for use > > > in anonymous spamming and trolling (thanks python-list-owner for > > > staying on top of that!), I propose to disconnect > > > comp.lang.python from > > > the python-list mailing list. Both would then operate > > > independently. > > > > > > > As someone who exclusively follows the mailing list, I selfishly > > want > > to support this, as it would notably improve the signal-to-noise > > ratio. But I'm aware that there are a number of good people who > > currently use the newsgroup, and those people would then be > > abandoned > > in the cess-pool. > > Counter-proposal that I have suggested several times before that > would > solve both these problems: make the newsgroup moderated. > > (Or, I suppose, create comp.lang.python.moderated and gateway it > to the mailing list, and disconnect comp.lang.python from the list.) From jon+usenet at unequivocal.eu Wed May 5 21:40:55 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 01:40:55 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> Message-ID: On 2021-05-06, Paul Bryan wrote: > What's involved in moderating c.l.p? Would there be volunteers willing > to do so? Nothing at all is involved, apart from changing the status of the group. The moderation would be done by the same people, in the same way, as the moderation of the list is done now. They wouldn't need to do any work they don't already do. From avigross at verizon.net Wed May 5 22:07:45 2021 From: avigross at verizon.net (Avi Gross) Date: Wed, 5 May 2021 22:07:45 -0400 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: References: Message-ID: <045f01d7421c$9b569820$d203c860$@verizon.net> Chris, I got the fastest python yesterday as it was so fast that it beat the one coming tomorrow. The trick is adding back the legs that evolution allowed to lapse. Without bated breath, Regardless, Avi -----Original Message----- From: Python-list On Behalf Of Chris Angelico Sent: Wednesday, May 5, 2021 12:02 PM To: Python Subject: Re: neoPython : Fastest Python Implementation: Coming Soon On Thu, May 6, 2021 at 2:01 AM Mr Flibble wrote: > > neoPython : Fastest Python Implementation: Coming Soon > > Message ends. > > /Flibble > My breath: not being held. Message ends. ChrisA -- https://mail.python.org/mailman/listinfo/python-list From Richard at Damon-Family.org Wed May 5 22:30:14 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Wed, 5 May 2021 22:30:14 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> Message-ID: <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Paul Bryan wrote: >> What's involved in moderating c.l.p? Would there be volunteers willing >> to do so? > Nothing at all is involved, apart from changing the status of the group. > The moderation would be done by the same people, in the same way, as the > moderation of the list is done now. They wouldn't need to do any work > they don't already do. As someone with a long usenet background, converting the existing group to moderated would be practically impossible. It just isn't done. It would need to be a new group created with the .moderated tag. The problem is that some servers won't change and getting things mixed like that just creates propagation problems, so it just isn't done. Basically, some machine would need to be designated to get all the submissions to the group, emailed to it, and people would need to log into the email account on that computer to approve all the posts, or a robot could perhaps be setup to auto-approve most based on some rules. -- Richard Damon From jon+usenet at unequivocal.eu Wed May 5 22:44:37 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 02:44:37 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote: >> On 2021-05-06, Paul Bryan wrote: >>> What's involved in moderating c.l.p? Would there be volunteers willing >>> to do so? >> Nothing at all is involved, apart from changing the status of the group. >> The moderation would be done by the same people, in the same way, as the >> moderation of the list is done now. They wouldn't need to do any work >> they don't already do. > > As someone with a long usenet background, converting the existing group > to moderated would be practically impossible. It just isn't done. It > would need to be a new group created with the .moderated tag. The > problem is that some servers won't change and getting things mixed like > that just creates propagation problems, so it just isn't done. As someone with a longer usenet background, it can be done, and there isn't any great reason not to do so in this case. But I did already suggest creating a new moderated group instead if people feel that's better. > Basically, some machine would need to be designated to get all the > submissions to the group, emailed to it, and people would need to log > into the email account on that computer to approve all the posts, or a > robot could perhaps be setup to auto-approve most based on some rules. Are you unaware that the group is already gatewayed to a moderated mailing list for which all of that work is already done? The only difference is that currently that good work is then wasted and thrown away from the point of view of the group participants. From pfeiffer at cs.nmsu.edu Wed May 5 22:58:38 2021 From: pfeiffer at cs.nmsu.edu (Joe Pfeiffer) Date: Wed, 05 May 2021 20:58:38 -0600 Subject: Bloody rubbish References: Message-ID: <1bfsz01sbl.fsf@pfeifferfamily.net> Mr Flibble writes: > Python is slow and significant whitespace is patently absurd. Why am I not surprised to learn your "fast" implementation turns out to be something other than python? From avigross at verizon.net Wed May 5 23:36:11 2021 From: avigross at verizon.net (Avi Gross) Date: Wed, 5 May 2021 23:36:11 -0400 Subject: Programmed energy use References: <04c501d74228$f5c28510$e1478f30$.ref@verizon.net> Message-ID: <04c501d74228$f5c28510$e1478f30$@verizon.net> Benjamin, The topic is being changed by me because I get amused by statistics. We can all agree that any form of energy use uses energy, duh! But that does not make it good or bad in isolation. If I had a job that had me wake up every day in the dark, drive for an hour to an airport, hop across the country (perhaps in a private plane) and drive a rental from there to work for another hour, find a few hours to do some work, then repeat and head home, that would indeed be wasteful as it happened several hundred times a year. If I opted to use a PC with ZOOM and a few other tools instead, including using resources in the cloud and especially programs running as PYTHON, would it be a net good thing for the environment? The reality is the success of Python as an environment that is used in many servers, often alongside others, simply means it is used MORE. If no other language was ever used, it would get all the blame. If it was rarely used, it might hardly matter if it was efficient or not. As it happens, I doubt it is anywhere as inefficient as some suggest. Some of the other alternatives arguably are much worse. Think how fast programs run that are written as humungous shell scripts that start a new full-process for each minor task, for example. One potential set of solutions is fairly clear. Some programs, in ANY language, perform differently depending on which algorithms are used and many other such factors. So sure, a substantial number of programs of any type that are run frequently probably could be evaluated to make them more efficient. A dumb example is languages that allow you to keep adding entries to something like a vector or list or data.frame and do so by making a new data structure each time of one length longer and COPYING all the items over and then allowing the previous one to be garbage collected. Boy can that become expensive for longer input or calculations. But if you KNOW how many items you may need, you can reserve enough space in advance and fill it as you go along, or other such variants. In my reality, many languages are now hybrids with some parts implemented using libraries already written carefully for efficiency and often in languages like C or C++ or FORTRAN or perhaps even lower-level languages that are machine-specific. Proper use of these routines gives a nice boost. And, sure, if you run some programs that never use many language features on a server, I suspect you could make a customized version of something like Python built that does not incorporate much of what will never be used so the core loaded is smaller and perhaps in many ways faster. I know that has been done for example for some smaller processors. Having said all that, if someone really made a truly compliant improvement on python that ran everything and was compatible with future additions, great. Would it be public domain and open-code? Would it be handed over to the groups currently responsible for python so parts or the whole could be used if people were interested? Would it be maintained? Free? ... My impression from the past is that what is being offered will NOT be a python interpreter at all but rather a file or files that define the language and an engine that takes programs in any language that has been defined that way and combining the two to compile some kind of executable. Some of that has sort of been done, albeit just for one language at a time. Adding features to the language though, or even fixing any errors, might become a bit weirder. But none of this really has to do with the environment really. The goal for many people is to make our computing CHEAPER and more reliable and so on. Obviously faster processors or peripherals may deliver more bang for the buck and reducing the heat generated or energy used (somewhat related) are other such facets. But if we improved our computers (including software like python) and simply found lots more uses for them so we kept adding more farms of servers such as to mine new bitcoin or whatever, we would not have progress. Heck, we can cut back on wasting energy by not allowing children to play video games or look at social media for more than an hour a day and limit people from getting their email more than once a day like in the old days! For adults, we could remove most pornography which apparently is one of the biggest uses for the internet. Does anyone have even a guess on what globally is contributing most to such energy usage even within the computer realm? I mean can we blame Apple and Microsoft and Google and such for their operating systems which run all the time and often consume all available CPU when nothing else is happening and it just keeps looking for something to do? How much time is spent by SQL queries whether called from python or any other languages, or google searches that may trigger a parallel search in thousands or more places then telling us the first 10, plus some ads, and saying there are umpteen million more if we are interested! Should we strive for more efficiency? Sure. Should I spend 3 years developing something to perfection that I could otherwise produce and debug and make available in weeks or months? Well, some do, and it is not unheard of to prototype in a language like python and later rewrite it in part or whole. Various languages have a role to play and niches they fit better than others. Python is no different and as noted if someone likes C++, great. Parenthetically, I have not had any reason to use C++ since the nineties and just ordered a few recent books to see how it has evolved since, perhaps in reaction to all the other languages spun off it or off C. My programmed energy use for today is just about exhausted. Luckily, my Day starts at midnight, in about half an hour ? Avi -----Original Message----- From: Python-list On Behalf Of Benjamin Schollnick Sent: Wednesday, May 5, 2021 2:17 PM To: Mr Flibble Cc: python-list at python.org Subject: Re: neoPython : Fastest Python Implementation: Coming Soon > Why? The currently extant Python implementations contribute to climate change as they are so inefficient; That same argument can be made for every triple-AAA video game, game console, etc. Python is more efficient for some problem sets, and Python is less efficient for other problem sets. Please feel free to come out with NeoPython. When you are done, and it is backward compatible with existing Python code, I?ll be happy to benchmark it against Native python. But don?t blame Python for global climate change. There are plenty of bigger ?causations? to Global climate change, then a freakin? computer programming language. - Benjamin -- https://mail.python.org/mailman/listinfo/python-list From Richard at Damon-Family.org Wed May 5 23:56:24 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Wed, 5 May 2021 23:56:24 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote: >>> On 2021-05-06, Paul Bryan wrote: >>>> What's involved in moderating c.l.p? Would there be volunteers willing >>>> to do so? >>> Nothing at all is involved, apart from changing the status of the group. >>> The moderation would be done by the same people, in the same way, as the >>> moderation of the list is done now. They wouldn't need to do any work >>> they don't already do. >> As someone with a long usenet background, converting the existing group >> to moderated would be practically impossible. It just isn't done. It >> would need to be a new group created with the .moderated tag. The >> problem is that some servers won't change and getting things mixed like >> that just creates propagation problems, so it just isn't done. > As someone with a longer usenet background, it can be done, and there > isn't any great reason not to do so in this case. But I did already > suggest creating a new moderated group instead if people feel that's > better. Not so sure you are longer than me, I started on usenet is the late 80s with dial up. Yes, there have been a few successful conversions, but it is a lot of work, and there may be too many servers that don't really care that might get it wrong (google groups is one that could easily not care if they break things, they have already broken comp.lang.c++ > >> Basically, some machine would need to be designated to get all the >> submissions to the group, emailed to it, and people would need to log >> into the email account on that computer to approve all the posts, or a >> robot could perhaps be setup to auto-approve most based on some rules. > Are you unaware that the group is already gatewayed to a moderated > mailing list for which all of that work is already done? The only > difference is that currently that good work is then wasted and thrown > away from the point of view of the group participants. The big difference is that the mailing list directly gets its email from the senders, and that was totally over SMTP so some From: verification is possible, thus it make sense to let email addresses be validated for whitelisting. Submissions from the moderated group have lost all traceability to the original sender when it get forwarded via the NNTP transportation link, so such a white list might not be as viable, and on usenet many people intentionally post without valid From addresses, so a LOT more messages will end up in the moderation queue, so more work for the moderators. -- Richard Damon From cl at isbd.net Thu May 6 03:32:04 2021 From: cl at isbd.net (Chris Green) Date: Thu, 6 May 2021 08:32:04 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> <871rakttbj.fsf@nightsong.com> Message-ID: Paul Rubin wrote: > "Avi Gross" writes: > > Given some notice, what stops anyone from joining the mailing list before > > there is a divorce between the forums? > > Some of us don't want to be on mailing lists, and prefer using news > client software. I am in agreement here, if a list/group is available both on Usenet and as a mailing list then I will always use the Usenet/NNTP access as it is simply better for discussion groups like this. I do have a 'proper' threaded mail reader (mutt) that I use for reading lists but a 'proper' newreader that uses that extra facilities of NNTP is always going to be better. So my vote is to keep comp.lang.python as it is in terms of content, whether that means changing it to a moderated group or something else I don't mind. The current level of 'noise' is IMHO acceptable, if the people who deal with it now are OK to continue then let's not change anything. -- Chris Green ? From mal at europython.eu Thu May 6 04:22:48 2021 From: mal at europython.eu (M.-A. Lemburg) Date: Thu, 6 May 2021 10:22:48 +0200 Subject: EuroPython 2021: Call for Sponsors Message-ID: <3e0477a7-76f7-fa88-dfad-fb774e835eea@europython.eu> We're happy to announce our call for sponsors. Reach out to enthusiastic Python developers, users and professionals worldwide by presenting your company at this year?s EuroPython 2021 Online conference, from July 26 - Aug 1, 2021! * EuroPython 2021 Call for Sponsors * https://ep2021.europython.eu/sponsor/ EuroPython 2021 Sponsor Packages -------------------------------- Sponsoring EuroPython guarantees you highly targeted visibility and the opportunity to present yourself and your company in a professional and innovative environment. We have adjusted our conference sponsor packages for the online format and lowered their prices, giving you an excellent opportunity to reach out to attendees from all around the world. You can run your own virtual rooms, text channels, run competitions, tutorials or give product presentations throughout the conference days. Want to know more? ------------------ We have just published our sponsorship brochure for EuroPython 2021, with full details and demographics: * EuroPython 2021 Sponsor Brochure * https://ep2021.europython.eu/sponsor/brochure/ For a quick overview, you can also head over to our sponsor packages page. Feel free to contact us with any questions at sponsoring at europython.eu. * EuroPython 2021 Sponsor Packages * https://ep2021.europython.eu/sponsor/packages/ Special offer for early bird sponsors ------------------------------------- Sponsors who sign up before or on May 7, will receive a * special 10% discount * on the sponsor package price. Become a sponsor and support EuroPython 2021 today! You can sign up on the sponsor packages page. Quick Summary ------------- EuroPython 2021 will be run online from July 26 - August 1: - Two workshop/training days (July 26 - 27) - Three conference days (July 28 - 30) - Two sprint days (July 31 - August 1) The sessions will be scheduled to ensure they are also accessible for those in the Asian and Americas time zones. Help spread the word -------------------- Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/europython-2021-speaker-mentorship-program/ Tweet: https://twitter.com/europython/status/1387004298211602433 Enjoy, -- EuroPython 2021 Team https://ep2021.europython.eu/ https://www.europython-society.org/ From jon+usenet at unequivocal.eu Thu May 6 06:12:39 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 10:12:39 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote: >> On 2021-05-06, Richard Damon wrote: >>> As someone with a long usenet background, converting the existing group >>> to moderated would be practically impossible. It just isn't done. It >>> would need to be a new group created with the .moderated tag. The >>> problem is that some servers won't change and getting things mixed like >>> that just creates propagation problems, so it just isn't done. >> As someone with a longer usenet background, it can be done, and there >> isn't any great reason not to do so in this case. But I did already >> suggest creating a new moderated group instead if people feel that's >> better. > > Not so sure you are longer than me, I started on usenet is the late 80s > with dial up. Yes, me too ;-) >> Are you unaware that the group is already gatewayed to a moderated >> mailing list for which all of that work is already done? The only >> difference is that currently that good work is then wasted and thrown >> away from the point of view of the group participants. > > The big difference is that the mailing list directly gets its email from > the senders, and that was totally over SMTP so some From: verification > is possible, thus it make sense to let email addresses be validated for > whitelisting. Submissions from the moderated group have lost all > traceability to the original sender when it get forwarded via the NNTP > transportation link, so such a white list might not be as viable, and on > usenet many people intentionally post without valid From addresses, so a > LOT more messages will end up in the moderation queue, so more work for > the moderators. I think you're fundamentally missing the point that the newsgroup is *already gatewayed to the mailing list*. Marking the group moderated will not result in any more work for the moderators. In fact what you say above is the opposite of the truth, as it will result in the link between the poster and the moderators becoming more direct, not less direct. From skip.montanaro at gmail.com Thu May 6 08:57:04 2021 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Thu, 6 May 2021 07:57:04 -0500 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: > Are you unaware that the group is already gatewayed to a moderated > mailing list for which all of that work is already done? What is this moderation of which you speak? I'm one of the Python postmasters (I maintain the SpamBayes setup) and am aware of a multi-part tool chain (black hole lists, SpamBayes, greylisting, etc), but not of human moderation on a grand scale, just of the relatively few posts which are held for the admins/moderators by SpamBayes. My definition of "moderation" is that a human vets every post. That's certainly not the case for python-list at python.org. Posts gated from comp.lang.python to the mailing list only get passed through SpamBayes. All other elements of the tool chain occur ahead of the gateway. If we are using two different definitions of "moderation" I think it is important to be clear what we mean. Skip From jon+usenet at unequivocal.eu Thu May 6 09:12:07 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 13:12:07 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: On 2021-05-06, Skip Montanaro wrote: >> Are you unaware that the group is already gatewayed to a moderated >> mailing list for which all of that work is already done? > > What is this moderation of which you speak? I'm one of the Python > postmasters (I maintain the SpamBayes setup) and am aware of a > multi-part tool chain (black hole lists, SpamBayes, greylisting, etc), > but not of human moderation on a grand scale, just of the relatively > few posts which are held for the admins/moderators by SpamBayes. My > definition of "moderation" is that a human vets every post. That's not a definition that anyone else would use, I think, and I say that as a moderator of a Usenet group.. > That's certainly not the case for python-list at python.org. Posts gated > from comp.lang.python to the mailing list only get passed through > SpamBayes. All other elements of the tool chain occur ahead of the > gateway. > > If we are using two different definitions of "moderation" I think it > is important to be clear what we mean. Are you saying that the messages that appear occasionally from people such as Ethan Furman claiming to be moderators and alleging that particular people have been banned or suspended are lies? And that the message I received once saying that my comp.lang.python post had been rejected from the list was also a lie? From user at example.net Thu May 6 09:13:00 2021 From: user at example.net (Orvar) Date: Thu, 6 May 2021 15:13:00 +0200 Subject: Bloody rubbish In-Reply-To: References: Message-ID: On 06/05/2021 14.11, Mr Flibble wrote: > Python is slow Maybe it's for your OS is slow by nature From Richard at Damon-Family.org Thu May 6 09:34:18 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 6 May 2021 09:34:18 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> Message-ID: <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> On 5/6/21 6:12 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote: >>> On 2021-05-06, Richard Damon wrote: >>>> As someone with a long usenet background, converting the existing group >>>> to moderated would be practically impossible. It just isn't done. It >>>> would need to be a new group created with the .moderated tag. The >>>> problem is that some servers won't change and getting things mixed like >>>> that just creates propagation problems, so it just isn't done. >>> As someone with a longer usenet background, it can be done, and there >>> isn't any great reason not to do so in this case. But I did already >>> suggest creating a new moderated group instead if people feel that's >>> better. >> Not so sure you are longer than me, I started on usenet is the late 80s >> with dial up. > Yes, me too ;-) > >>> Are you unaware that the group is already gatewayed to a moderated >>> mailing list for which all of that work is already done? The only >>> difference is that currently that good work is then wasted and thrown >>> away from the point of view of the group participants. >> The big difference is that the mailing list directly gets its email from >> the senders, and that was totally over SMTP so some From: verification >> is possible, thus it make sense to let email addresses be validated for >> whitelisting. Submissions from the moderated group have lost all >> traceability to the original sender when it get forwarded via the NNTP >> transportation link, so such a white list might not be as viable, and on >> usenet many people intentionally post without valid From addresses, so a >> LOT more messages will end up in the moderation queue, so more work for >> the moderators. > I think you're fundamentally missing the point that the newsgroup is > *already gatewayed to the mailing list*. Marking the group moderated > will not result in any more work for the moderators. In fact what you > say above is the opposite of the truth, as it will result in the link > between the poster and the moderators becoming more direct, not less > direct. It will. First, python-list at python.org is NOT a "Moderated" mailing list by the standard definition of such. Maybe you could call it Moderatable, but most messages make it to the list without any intervention by a moderator. The Mailman software that runs the list allows the administrators of the list to put select filters on posts, or to make certain posters moderated and need their posts reviewed, but most posts go through automatically and immediately. This works because the SMTP Email system have a must better presumption of the From address in the message actually being who the sender is then under NNTP rules. Forging it is detectable in many cases and generally a violation of the TOS for most providers (and the ones that don't can easily be blocked). While you could setup a robo-moderator to do a similar thing, Usenet posters will not have 'pre-subscribed' before posting, and the From address is no where near as relaible as invalid From addresses ARE allowed, and since the message comes via a NNTP injection source relay, non-verifiable. This make the job a LOT harder. The current setup does put rules at the gateway that controls what gets onto the mailing list, and because it IS a gateway, there are easier grounds to establish that some posts just won't be gated over from usenet to the mailing list. Putting those same limits onto the moderated group itself would be against Usenet norms. This would mean that the Usenet moderation queue WILL require significant additional work over what is currently being done for the mailing list. If the idea is just to provide a NNTP accessible version of the mailing list, than perhaps rather than a comp.* group, putting it on gmane would be a viable option, that avoids some of the Usenet issues. -- Richard Damon From Richard at Damon-Family.org Thu May 6 09:41:53 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 6 May 2021 09:41:53 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: <928550e9-9b15-4d5e-72c6-14927ff34ba6@Damon-Family.org> On 5/6/21 9:12 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Skip Montanaro wrote: >>> Are you unaware that the group is already gatewayed to a moderated >>> mailing list for which all of that work is already done? >> What is this moderation of which you speak? I'm one of the Python >> postmasters (I maintain the SpamBayes setup) and am aware of a >> multi-part tool chain (black hole lists, SpamBayes, greylisting, etc), >> but not of human moderation on a grand scale, just of the relatively >> few posts which are held for the admins/moderators by SpamBayes. My >> definition of "moderation" is that a human vets every post. > That's not a definition that anyone else would use, I think, > and I say that as a moderator of a Usenet group.. > >> That's certainly not the case for python-list at python.org. Posts gated >> from comp.lang.python to the mailing list only get passed through >> SpamBayes. All other elements of the tool chain occur ahead of the >> gateway. >> >> If we are using two different definitions of "moderation" I think it >> is important to be clear what we mean. > Are you saying that the messages that appear occasionally from people > such as Ethan Furman claiming to be moderators and alleging that > particular people have been banned or suspended are lies? And that the > message I received once saying that my comp.lang.python post had been > rejected from the list was also a lie? No, as I mentioned in my other post. a "Moderated Mailing List" is generally described as one which EVERY message is hand reviewed by a person, and alloweed onto the list. python-list is NOT such a list. One advantage of mediums like mailing lists, is that it is quite easy to setup methods where all the mail goes through a gatekeeper, and it automatically approves most messages, but a limited number of messages get held to be reviewed. This is generally NOT described as a Moderated List. Usenet being a distributed system, doesn't support this model. Either anybody can inject a message from wherever they are, no all messages are sent to be reviewed, the unmoderated and moderated is a VERY sharp line. In Usenet terms, lists like this would be described as loosely robo-moderated. And it works a lot better for mailing lists than for Usenet groups due to different rules about From: identification of messages. -- Richard Damon From skip.montanaro at gmail.com Thu May 6 09:43:53 2021 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Thu, 6 May 2021 08:43:53 -0500 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: > Are you saying that the messages that appear occasionally from people > such as Ethan Furman claiming to be moderators and alleging that > particular people have been banned or suspended are lies? And that the > message I received once saying that my comp.lang.python post had been > rejected from the list was also a lie? I'm sorry, but I don't recall accusing you of lying, neither in my words nor in my thoughts. If you think I was doing that, you must be reading everything with a very jaundiced eye. My issue was that we seem to disagree with the definition of "moderation." Earlier in this thread it was suggested that comp.lang.python.moderated be created and that some as-yet-unnamed moderators would vet every single message to that group. I think of moderation as things which humans do, not tool chains. I suppose the python.org postmasters could disable all elements of that tool chain and let the admins/moderators do it all manually. Still, I don't think of the mailing list as moderated. Yes, Ethan is one of three listed admins of the list. I wouldn't have mentioned him by name, but you did. (I suppose his role common knowledge anyway.) I see three held messages in the queue right now with received times between 00:33 to 08:15 today (timezone isn't mentioned). I seriously doubt Ethan or the other admins approved all the other messages which have reached the list in that interval. Despite the existing tool chain, a number of messages which shouldn't probably leak through without being vetted by Ethan or the other admins. I will offer one other bit of information. As I understand it, the only reason python-list at python.org can't be migrated to Mailman 3 is because it doesn't support the gateway between Usenet and mail. It's worth considering for people thinking about whether or not to disconnect the two. (I have no opinion on that subject. Clearly others do.) Skip From jon+usenet at unequivocal.eu Thu May 6 09:44:52 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 13:44:52 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > On 5/6/21 6:12 AM, Jon Ribbens via Python-list wrote: >> I think you're fundamentally missing the point that the newsgroup is >> *already gatewayed to the mailing list*. Marking the group moderated >> will not result in any more work for the moderators. In fact what you >> say above is the opposite of the truth, as it will result in the link >> between the poster and the moderators becoming more direct, not less >> direct. > > It will. How? How would switching from a bi-directional gateway to a moderated group make any more work for anyone than the existing bi-directional gateway to an unmoderated group? > First, python-list at python.org is NOT a "Moderated" mailing list by the > standard definition of such. Maybe you could call it Moderatable, but > most messages make it to the list without any intervention by a > moderator. Sounds like nearly all moderated lists/forums then. > The Mailman software that runs the list allows the administrators of > the list to put select filters on posts, or to make certain posters > moderated and need their posts reviewed, but most posts go through > automatically and immediately. This works because the SMTP Email > system have a must better presumption of the From address in the > message actually being who the sender is then under NNTP rules. The SMTP mail system makes no such assumption whatsoever. > Forging it is detectable in many cases and generally a violation of > the TOS for most providers (and the ones that don't can easily be > blocked). Sounds a lot like Usenet then. > While you could setup a robo-moderator to do a similar thing, Usenet > posters will not have 'pre-subscribed' before posting, and the From > address is no where near as relaible as invalid From addresses ARE > allowed, and since the message comes via a NNTP injection source relay, > non-verifiable. This make the job a LOT harder. It makes essentially no difference at all. > The current setup does put rules at the gateway that controls what gets > onto the mailing list, and because it IS a gateway, there are easier > grounds to establish that some posts just won't be gated over from > usenet to the mailing list. Putting those same limits onto the moderated > group itself would be against Usenet norms. This would mean that the > Usenet moderation queue WILL require significant additional work over > what is currently being done for the mailing list. Could you explain what on earth you are on about here please? > If the idea is just to provide a NNTP accessible version of the mailing > list, than perhaps rather than a comp.* group, putting it on gmane would > be a viable option, that avoids some of the Usenet issues. How would that make any difference? From jon+usenet at unequivocal.eu Thu May 6 10:07:24 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 14:07:24 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> Message-ID: On 2021-05-06, Skip Montanaro wrote: >> Are you saying that the messages that appear occasionally from people >> such as Ethan Furman claiming to be moderators and alleging that >> particular people have been banned or suspended are lies? And that the >> message I received once saying that my comp.lang.python post had been >> rejected from the list was also a lie? > > I'm sorry, but I don't recall accusing you of lying, Neither do I. Nor do I remember accusing you of accusing me of lying. Try reading the quoted paragraph above again, since you apparently misread it the first time. > My issue was that we seem to disagree with the definition of > "moderation." Earlier in this thread it was suggested that > comp.lang.python.moderated be created and that some as-yet-unnamed > moderators would vet every single message to that group. I am not aware that anyone has suggested anything remotely like that. > Yes, Ethan is one of three listed admins of the list. I wouldn't have > mentioned him by name, but you did. (I suppose his role common > knowledge anyway.) Well, yes, if he wanted it to be secret he presumably would not have made formal announcements describing himself as a moderator in public on the list. From jon+usenet at unequivocal.eu Thu May 6 10:23:34 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 14:23:34 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <928550e9-9b15-4d5e-72c6-14927ff34ba6@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > On 5/6/21 9:12 AM, Jon Ribbens via Python-list wrote: >> Are you saying that the messages that appear occasionally from people >> such as Ethan Furman claiming to be moderators and alleging that >> particular people have been banned or suspended are lies? And that the >> message I received once saying that my comp.lang.python post had been >> rejected from the list was also a lie? > > No, as I mentioned in my other post. a "Moderated Mailing List" is > generally described as one which EVERY message is hand reviewed by a > person, and alloweed onto the list. python-list is NOT such a list. It's a list. It has people who describe themselves as "moderators", who moderate it. If you want to say that a list with moderators who moderate it is not a moderated list then feel free to go right ahead, it's a free planet. > One advantage of mediums like mailing lists, is that it is quite easy to > setup methods where all the mail goes through a gatekeeper, and it > automatically approves most messages, but a limited number of messages > get held to be reviewed. This is generally NOT described as a Moderated > List. > > Usenet being a distributed system, doesn't support this model. You are mistaken, that is exactly how a moderated newsgroup works. From Joseph.Schachner at Teledyne.com Thu May 6 10:47:23 2021 From: Joseph.Schachner at Teledyne.com (Schachner, Joseph) Date: Thu, 6 May 2021 14:47:23 +0000 Subject: neoPython : Fastest Python Implementation: Coming Soon In-Reply-To: <0szkI.195451$i669.143154@fx02.ams4> References: <0szkI.195451$i669.143154@fx02.ams4> Message-ID: "Slow" is in the eye of the beholder and depends on the job the needs to be done. Where I work, we write scripts in Python that control our measuring instruments, make them acquire data and compute results, the Python script reads the results, compares results to limits, and eventually produces a lovely report. In some scripts, we make the instrument acquire and save data and our Python script launches another program on the instrument that will read in the data and perform specified analysis. That program can take a couple of minutes to complete. If we have to do this for multiple runs we launch them at the same time and they finish at the same time, the time of one run. So we are doing easy multiprocessing using Python. Now let's consider, if our controlling Python script were instead written in a highly optimized blazingly fast compiled language, how much faster could this script be? It would still have to wait for the instrument to compute results; if running a separate analysis program it would still have to launch it (perhaps several of them) and wait for until they finished. I doubt the compiled script would finish even a second faster. I think this kind of application is just perfect for Python. We considered other (commercially supported) languages before we went with Python. I'm very happy that we did. We can find people who want to program in Python and already know Python. I haven't yet seen an employee complaint about our scripts being written in Python, and I don't expect to. -- Joseph S. Teledyne Confidential; Commercially Sensitive Business Data From grant.b.edwards at gmail.com Thu May 6 10:36:31 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 14:36:31 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: On 2021-05-06, Chris Angelico wrote: > On Thu, May 6, 2021 at 10:43 AM Avi Gross via Python-list > wrote: >> >> Chris, >> >> Given some notice, what stops anyone from joining the mailing list before >> there is a divorce between the forums? > > Nothing! Nothing at all. That is, if you're talking about *people*. > People are absolutely welcome to join. The reason the S/N would > improve is all the non-people who post to the newsgroup. > > But there are some people who simply don't want to use the mailing > list, and that's currently a fully-welcomed option. I won't name > names, but there definitely are people who would prefer a newsreader, Pointing a newsreader at news.gmane.io allows one to participate in the mailing list just fine without using Usenet. Not that I support shutting down the Usenet/email gateway -- the signal/noise ration seems fine to me. -- Grant From grant.b.edwards at gmail.com Thu May 6 10:39:25 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 14:39:25 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > If the idea is just to provide a NNTP accessible version of the mailing > list, than perhaps rather than a comp.* group, putting it on gmane would > be a viable option, that avoids some of the Usenet issues. The list _is_ on gmane and has been since forever. It's gmane.comp.python.general. -- Grant From jf_byrnes at comcast.net Thu May 6 09:18:43 2021 From: jf_byrnes at comcast.net (Jim Byrnes) Date: Thu, 6 May 2021 08:18:43 -0500 Subject: [OT] Annoying message duplication, was Re: Unsubscribe/can't login In-Reply-To: References: <0db72c95-91e3-2b5a-3439-3254de1c3ede@web.de> Message-ID: On 5/5/21 1:07 PM, Jan van den Broek wrote: > On 2021-05-05, Jim Byrnes wrote: >> On 5/5/21 9:39 AM, Peter Otten wrote: >>> On 05/05/2021 16:10, Ethan Furman wrote: >>> >>>> I see your messages twice (occasionally with other posters as well). >>>> I have no idea how to fix it.?? :( >>> >>> OK, I'll try another option from Thunderbird's context menu: Followup to >>> Newsgroup. >>> >>> Does that appear once or twice? >>> >>> In theory it should go to the newsgroup only which would mirror it to >>> the list. >>> >> >> FWIW, none of the messages in this this thread are dupes for me and I >> can't remember the last time I saw a dupe from you. > > Are you reading this via the mailinglist or Usenet? > Reading it using Thunderbird via news.gmane.io Regards, Jim From arj.python at gmail.com Thu May 6 11:13:52 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Thu, 6 May 2021 19:13:52 +0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: It was high time ? a proposal like that came up We have seen from time to time some comp lang interruptions ~ From mats at wichmann.us Thu May 6 11:30:24 2021 From: mats at wichmann.us (Mats Wichmann) Date: Thu, 6 May 2021 09:30:24 -0600 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: <6ad7c823-1b58-089b-1309-fac932255c05@wichmann.us> On 5/5/21 10:33 PM, Dennis Lee Bieber wrote: > I, for one, wish more mailing lists did have newsgroup access (I also > wish for the demise of Google Groups, but short of a large explosive in > Mountain View, doubt that will come to pass). Instead everything is being > splintered into smaller and smaller forums which many won't keep following. > And if it web-based, that is even worse -- having to refresh pages for each > message read, limited to their editors which tend not to preserve > formatting, etc. Splintering is a real problem that a lot of projects face. Of course you want to have a presence on forums that are comfortable for people, but these days it's typical to have, like Python does, mailing lists, newsgroup, forum software (discuss.python.org), chat channels, bug trackers, github, change proposals on a website (PEPs), and so on, as well as busy "external" sites like the Python DIscord server. I'm struggling with that for a much smaller project, ain't easy to keep collective knowledge like this organized and findable without asking everybody to participate in everything, which (a) is impossible and (b) the reason for multiple approaches in the first place - some won't do mailing lists, some won't do forums, etc. From cl at isbd.net Thu May 6 11:29:18 2021 From: cl at isbd.net (Chris Green) Date: Thu, 6 May 2021 16:29:18 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: Grant Edwards wrote: > On 2021-05-06, Chris Angelico wrote: > > On Thu, May 6, 2021 at 10:43 AM Avi Gross via Python-list > > wrote: > >> > >> Chris, > >> > >> Given some notice, what stops anyone from joining the mailing list before > >> there is a divorce between the forums? > > > > Nothing! Nothing at all. That is, if you're talking about *people*. > > People are absolutely welcome to join. The reason the S/N would > > improve is all the non-people who post to the newsgroup. > > > > But there are some people who simply don't want to use the mailing > > list, and that's currently a fully-welcomed option. I won't name > > names, but there definitely are people who would prefer a newsreader, > > Pointing a newsreader at news.gmane.io allows one to participate in > the mailing list just fine without using Usenet. > ??? Surely that *is* using Usenet, at least you're using NNTP which is the Usenet protocol. What's "not Usenet" about it? > Not that I support shutting down the Usenet/email gateway -- the > signal/noise ration seems fine to me. > On that I quite agree. :-) -- Chris Green ? From pbryan at anode.ca Thu May 6 11:41:14 2021 From: pbryan at anode.ca (Paul Bryan) Date: Thu, 06 May 2021 08:41:14 -0700 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: I will also add that it can get confusing when someone replies to a newsgroup posting that was originally suppressed to the mailing list. This has happened as recently as today. On Thu, 2021-05-06 at 14:36 +0000, Grant Edwards wrote: > On 2021-05-06, Chris Angelico wrote: > > On Thu, May 6, 2021 at 10:43 AM Avi Gross via Python-list > > wrote: > > > > > > Chris, > > > > > > Given some notice, what stops anyone from joining the mailing > > > list before > > > there is a divorce between the forums? > > > > Nothing! Nothing at all. That is, if you're talking about *people*. > > People are absolutely welcome to join. The reason the S/N would > > improve is all the non-people who post to the newsgroup. > > > > But there are some people who simply don't want to use the mailing > > list, and that's currently a fully-welcomed option. I won't name > > names, but there definitely are people who would prefer a > > newsreader, > > Pointing a newsreader at news.gmane.io allows one to participate in > the mailing list just fine without using Usenet. > > Not that I support shutting down the Usenet/email gateway -- the > signal/noise ration seems fine to me. > > -- > Grant > > From grant.b.edwards at gmail.com Thu May 6 11:28:53 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 15:28:53 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: On 2021-05-06, Dennis Lee Bieber wrote: > Granted, I did move from pure comp.lang.python to > gmane.comp.python.general when the spam became too much to keep > track of. (Now if I could only figure out why the beaglebone group > stopped accepting replies via gmane -- I keep having to remember to > reply by email in that forum). Years ago one of the lists I read on gmane required actual e-mailed posts and I configured slrn to do that without me having to remember it. I don't remember exactly how... -- Grant From skip.montanaro at gmail.com Thu May 6 12:03:18 2021 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Thu, 6 May 2021 11:03:18 -0500 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: > > Not that I support shutting down the Usenet/email gateway -- the > > signal/noise ration seems fine to me. > > > On that I quite agree. :-) I remind people that the existing Usenet<->Mail gateway keeps the mailing list software on mail.python.org from migrating to Mailman 3. I'm sure Mark Sapiro and other Mailman maintainers would like to keep moving away from Mailman 2. If the gateway (easier anonymity) and Mailman 3 (maybe better list archives) are of interest to you, you might check in with the Mailman dev list and see what would be involved in porting the gateway code to MM3. Skip From grant.b.edwards at gmail.com Thu May 6 12:00:59 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 16:00:59 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: On 2021-05-06, Chris Green wrote: > Grant Edwards wrote: > >> Pointing a newsreader at news.gmane.io allows one to participate in >> the mailing list just fine without using Usenet. >> > ??? Surely that *is* using Usenet, at least you're using NNTP which > is the Usenet protocol. What's "not Usenet" about it? Usenet was a distributed network of computers that transferred articles amongst themselves using various protocols, and provided access to readers in various ways (NNTP being one of them). Gmane was not and is not part of that network. It is a single, stand-alone machine operating as an email list archiver/gateway that provides access to read/post via NTTP. -- Grant From treetaxi at pobox.com Thu May 6 12:53:47 2021 From: treetaxi at pobox.com (Wayne Lodahl) Date: Thu, 6 May 2021 10:53:47 -0600 Subject: Bloody rubbish In-Reply-To: References: Message-ID: On 5/6/21 6:11 AM, Mr Flibble wrote: > Python is slow and significant whitespace is patently absurd. > > Bloody rubbish, it's all bloody rubbish. > > Message ends. > > /Flibble > Machine language is so much simpler, and you can code with just a hexpad. From torriem at gmail.com Thu May 6 12:56:10 2021 From: torriem at gmail.com (Michael Torrie) Date: Thu, 6 May 2021 10:56:10 -0600 Subject: Bloody rubbish In-Reply-To: <1bfsz01sbl.fsf@pfeifferfamily.net> References: <1bfsz01sbl.fsf@pfeifferfamily.net> Message-ID: <4e9cbae0-728c-6787-708b-9badfde15706@gmail.com> On 5/5/21 8:58 PM, Joe Pfeiffer wrote: > Mr Flibble writes: > >> Python is slow and significant whitespace is patently absurd. > > Why am I not surprised to learn your "fast" implementation turns out to > be something other than python? And it's bizarre that the OP, since he despises Python so much, and finds its syntax absurd, would even bother to make any sort of implementation of it. From Richard at Damon-Family.org Thu May 6 13:30:15 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 6 May 2021 13:30:15 -0400 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> Message-ID: <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> On 5/6/21 9:44 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Richard Damon wrote: >> On 5/6/21 6:12 AM, Jon Ribbens via Python-list wrote: >>> I think you're fundamentally missing the point that the newsgroup is >>> *already gatewayed to the mailing list*. Marking the group moderated >>> will not result in any more work for the moderators. In fact what you >>> say above is the opposite of the truth, as it will result in the link >>> between the poster and the moderators becoming more direct, not less >>> direct. >> It will. > How? How would switching from a bi-directional gateway to a moderated > group make any more work for anyone than the existing bi-directional > gateway to an unmoderated group? > >> First, python-list at python.org is NOT a "Moderated" mailing list by the >> standard definition of such. Maybe you could call it Moderatable, but >> most messages make it to the list without any intervention by a >> moderator. > Sounds like nearly all moderated lists/forums then. Then perhaps you have never been on a real Moderated mailing list or Forum. Lists/Forum when described as moderated normally means that a human eyeball looks at EVERY (or almost every) message before it goes public. >> The Mailman software that runs the list allows the administrators of >> the list to put select filters on posts, or to make certain posters >> moderated and need their posts reviewed, but most posts go through >> automatically and immediately. This works because the SMTP Email >> system have a must better presumption of the From address in the >> message actually being who the sender is then under NNTP rules. > The SMTP mail system makes no such assumption whatsoever. Maybe not be the absolute letter of the rules, but it does in practice. Especially if a person intends for their messages to be able to be delivered to most mail servers. At the very least, the email envelope will have an apparently valid email address, or most email systems will refuse it. Protocols like SPF will verify that the message does come from who it says, or at least there is a responsible party that will deal with things, or that whole domain get put into block lists. Email from 'known senders' tends to be reliably marked, and you need to subscribe to the list and become a 'known sender'. Once you have gone through the NNTP gateway, you lose all of that. >> Forging it is detectable in many cases and generally a violation of >> the TOS for most providers (and the ones that don't can easily be >> blocked). > Sounds a lot like Usenet then. Many Usenet providers do NOT require users to use valid email address as their From (You can't subscribe such an address to the mailing list to be able to post from it). They might prohibit explicitly forging someone else's email address, but Nym Shifiting is common and accepted on Usenet (SOME providers might limit it, but not all) >> While you could setup a robo-moderator to do a similar thing, Usenet >> posters will not have 'pre-subscribed' before posting, and the From >> address is no where near as relaible as invalid From addresses ARE >> allowed, and since the message comes via a NNTP injection source relay, >> non-verifiable. This make the job a LOT harder. > It makes essentially no difference at all. It sure does. Have you every actually TRIED to run a moderated Usenet group, or know anyone who has, especially a somewhat busy group? >> The current setup does put rules at the gateway that controls what gets >> onto the mailing list, and because it IS a gateway, there are easier >> grounds to establish that some posts just won't be gated over from >> usenet to the mailing list. Putting those same limits onto the moderated >> group itself would be against Usenet norms. This would mean that the >> Usenet moderation queue WILL require significant additional work over >> what is currently being done for the mailing list. > Could you explain what on earth you are on about here please? I am presuming that the current gateway isn't bringing all the messages from Usenet into the mailing list. This is obvious as we don't see the noise here. The Cabal that runs the 'Big-8' doesn't really care what sort of filters are added at such a gateway. To setup a moderated group that defines similar filters in place for messages getting to Usenet, particularly for a group intended to replace a 'reasonably' working unmoderated group, is likely not going to be viewed well. In the old days of actual voting for new groups, just saying you intended to do such got you a lot of negative votes. Not sayng you are going to do it, and then doing it, might get the Big-8 > >> If the idea is just to provide a NNTP accessible version of the mailing >> list, than perhaps rather than a comp.* group, putting it on gmane would >> be a viable option, that avoids some of the Usenet issues. > How would that make any difference? gmane is not Usenet. If you just want NNTP access, but not the problems of general Usenet, it is an alternative. -- Richard Damon From cl at isbd.net Thu May 6 13:26:00 2021 From: cl at isbd.net (Chris Green) Date: Thu, 6 May 2021 18:26:00 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> Message-ID: <8eldmh-pp261.ln1@esprimo.zbmc.eu> Grant Edwards wrote: > On 2021-05-06, Chris Green wrote: > > Grant Edwards wrote: > > > >> Pointing a newsreader at news.gmane.io allows one to participate in > >> the mailing list just fine without using Usenet. > >> > > ??? Surely that *is* using Usenet, at least you're using NNTP which > > is the Usenet protocol. What's "not Usenet" about it? > > Usenet was a distributed network of computers that transferred > articles amongst themselves using various protocols, and provided > access to readers in various ways (NNTP being one of them). > Usenet *is* still this > Gmane was not and is not part of that network. It is a single, > stand-alone machine operating as an email list archiver/gateway that > provides access to read/post via NTTP. > It is effectively part of Usenet because the mailing lists it hosts and gateways to its newserver are peered with Usenet. I read several gmane 'lists' via usenet, I most certainly don't get them directly from gmane, I get them from other usenet servers. -- Chris Green ? From jon+usenet at unequivocal.eu Thu May 6 13:41:39 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 17:41:39 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: On 2021-05-06, Richard Damon wrote: > On 5/6/21 9:44 AM, Jon Ribbens via Python-list wrote: >> Sounds like nearly all moderated lists/forums then. > > Then perhaps you have never been on a real Moderated mailing list or > Forum. Ah, the "no true scotsforum" argument ;-) >>> While you could setup a robo-moderator to do a similar thing, Usenet >>> posters will not have 'pre-subscribed' before posting, and the From >>> address is no where near as relaible as invalid From addresses ARE >>> allowed, and since the message comes via a NNTP injection source relay, >>> non-verifiable. This make the job a LOT harder. >> It makes essentially no difference at all. > It sure does. Have you every actually TRIED to run a moderated Usenet > group, or know anyone who has, especially a somewhat busy group? As I already mentioned, I am a moderator of a Usenet group. > I am presuming that the current gateway isn't bringing all the messages > from Usenet into the mailing list. This is obvious as we don't see the > noise here. The Cabal that runs the 'Big-8' doesn't really care what > sort of filters are added at such a gateway. > > To setup a moderated group that defines similar filters in place for > messages getting to Usenet, particularly for a group intended to replace > a 'reasonably' working unmoderated group, is likely not going to be > viewed well. Have you every actually TRIED to run a moderated Usenet group, or know anyone who has, especially a somewhat busy group? Of *course* moderated groups put filters on what they receive, what do you think group moderation is *for* if not to block things? From stestagg at gmail.com Thu May 6 13:49:25 2021 From: stestagg at gmail.com (Stestagg) Date: Thu, 6 May 2021 18:49:25 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: Where's this discussion going? Let's not get too caught up on definitions or the sizes of everyone's respective .. newsgroups. Which of the practically possible options are best for this list <-> newsgroup setup? Thanks Steve On Thu, May 6, 2021 at 6:47 PM Jon Ribbens via Python-list < python-list at python.org> wrote: > On 2021-05-06, Richard Damon wrote: > > On 5/6/21 9:44 AM, Jon Ribbens via Python-list wrote: > >> Sounds like nearly all moderated lists/forums then. > > > > Then perhaps you have never been on a real Moderated mailing list or > > Forum. > > Ah, the "no true scotsforum" argument ;-) > > >>> While you could setup a robo-moderator to do a similar thing, Usenet > >>> posters will not have 'pre-subscribed' before posting, and the From > >>> address is no where near as relaible as invalid From addresses ARE > >>> allowed, and since the message comes via a NNTP injection source relay, > >>> non-verifiable. This make the job a LOT harder. > >> It makes essentially no difference at all. > > It sure does. Have you every actually TRIED to run a moderated Usenet > > group, or know anyone who has, especially a somewhat busy group? > > As I already mentioned, I am a moderator of a Usenet group. > > > I am presuming that the current gateway isn't bringing all the messages > > from Usenet into the mailing list. This is obvious as we don't see the > > noise here. The Cabal that runs the 'Big-8' doesn't really care what > > sort of filters are added at such a gateway. > > > > To setup a moderated group that defines similar filters in place for > > messages getting to Usenet, particularly for a group intended to replace > > a 'reasonably' working unmoderated group, is likely not going to be > > viewed well. > > Have you every actually TRIED to run a moderated Usenet group, or know > anyone who has, especially a somewhat busy group? Of *course* moderated > groups put filters on what they receive, what do you think group > moderation is *for* if not to block things? > -- > https://mail.python.org/mailman/listinfo/python-list > From skip.montanaro at gmail.com Thu May 6 13:54:23 2021 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Thu, 6 May 2021 12:54:23 -0500 Subject: Bloody rubbish In-Reply-To: References: Message-ID: > > Machine language is so much simpler, and you can code with just a hexpad. > Pshaa... All you need are front panel switches. ;-) (Yes, I had a professor who required is to 'key' in our programs on the front panel, of a rack mounted PDP-11 as I recall. Needless to say, we didn't use an assembler either. We just wrote raw opcodes and their arguments on paper. This was in the late 70s.) Skip > From jon+usenet at unequivocal.eu Thu May 6 14:05:44 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Thu, 6 May 2021 18:05:44 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: On 2021-05-06, Stestagg wrote: > Where's this discussion going? > > Let's not get too caught up on definitions or the sizes of everyone's > respective .. newsgroups. > > Which of the practically possible options are best for this list <-> > newsgroup setup? As before I'd suggest that changing the group to be moderated, or switching to a parallel moderated group, is at the very least worth trying. There's no obvious downside and it requires very little work from anyone (indeed no work at all after the initial setup). None of the objections raised so far have any basis whatsoever in reality. And it appears even the suggestion that Mailman 3 cannot be used while a gateway is involved is untrue: https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/nntp.html From pbryan at anode.ca Thu May 6 14:14:36 2021 From: pbryan at anode.ca (Paul Bryan) Date: Thu, 06 May 2021 11:14:36 -0700 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <8c69b9a920c5710857e0f015e5cf20d188c1e8cb.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: I do not believe my proposal has reached?or will reach?consensus. It seems there are some who still value the linkage between the two, and the S/N ratio is indeed low enough it doesn't warrant changing from the status quo. Thanks everyone for the consideration and discussion.? Paul On Thu, 2021-05-06 at 18:49 +0100, Stestagg wrote: > Where's this discussion going? > > Let's not get too caught up on definitions or the sizes of everyone's > respective .. newsgroups. > > Which of the practically possible options are best for this list <-> > newsgroup setup? > > Thanks > > Steve > > On Thu, May 6, 2021 at 6:47 PM Jon Ribbens via Python-list < > python-list at python.org> wrote: > > > On 2021-05-06, Richard Damon wrote: > > > On 5/6/21 9:44 AM, Jon Ribbens via Python-list wrote: > > > > Sounds like nearly all moderated lists/forums then. > > > > > > Then perhaps you have never been on a real Moderated mailing list > > > or > > > Forum. > > > > Ah, the "no true scotsforum" argument ;-) > > > > > > > While you could setup a robo-moderator to do a similar thing, > > > > > Usenet > > > > > posters will not have 'pre-subscribed' before posting, and > > > > > the From > > > > > address is no where near as relaible as invalid From > > > > > addresses ARE > > > > > allowed, and since the message comes via a NNTP injection > > > > > source relay, > > > > > non-verifiable. This make the job a LOT harder. > > > > It makes essentially no difference at all. > > > It sure does. Have you every actually TRIED to run a moderated > > > Usenet > > > group, or know anyone who has, especially a somewhat busy group? > > > > As I already mentioned, I am a moderator of a Usenet group. > > > > > I am presuming that the current gateway isn't bringing all the > > > messages > > > from Usenet into the mailing list. This is obvious as we don't > > > see the > > > noise here. The Cabal that runs the 'Big-8' doesn't really care > > > what > > > sort of filters are added at such a gateway. > > > > > > To setup a moderated group that defines similar filters in place > > > for > > > messages getting to Usenet, particularly for a group intended to > > > replace > > > a 'reasonably' working unmoderated group, is likely not going to > > > be > > > viewed well. > > > > Have you every actually TRIED to run a moderated Usenet group, or > > know > > anyone who has, especially a somewhat busy group? Of *course* > > moderated > > groups put filters on what they receive, what do you think group > > moderation is *for* if not to block things? > > -- > > https://mail.python.org/mailman/listinfo/python-list > > From auriocus at gmx.de Thu May 6 14:19:40 2021 From: auriocus at gmx.de (Christian Gollwitzer) Date: Thu, 6 May 2021 20:19:40 +0200 Subject: Bloody rubbish In-Reply-To: References: Message-ID: Am 06.05.21 um 19:54 schrieb Skip Montanaro: >> >> Machine language is so much simpler, and you can code with just a hexpad. >> > > Pshaa... All you need are front panel switches. ;-) (Yes, I had a professor > who required is to 'key' in our programs on the front panel, of a rack > mounted PDP-11 as I recall. Needless to say, we didn't use an assembler > either. We just wrote raw opcodes and their arguments on paper. This was in > the late 70s.) Pure luxury! https://xkcd.com/378/ Christian From pfeiffer at cs.nmsu.edu Thu May 6 15:02:58 2021 From: pfeiffer at cs.nmsu.edu (Joe Pfeiffer) Date: Thu, 06 May 2021 13:02:58 -0600 Subject: Bloody rubbish References: Message-ID: <1bbl9n1y8t.fsf@pfeifferfamily.net> Skip Montanaro writes: >> >> Machine language is so much simpler, and you can code with just a hexpad. >> > > Pshaa... All you need are front panel switches. ;-) (Yes, I had a professor > who required is to 'key' in our programs on the front panel, of a rack > mounted PDP-11 as I recall. Needless to say, we didn't use an assembler > either. We just wrote raw opcodes and their arguments on paper. This was in > the late 70s.) That's right about whn I had to do that for one assignment (on a Nova). Hand-assembling, toggling in, and debugging a program on the front panel was a valuable learning exercise. Doing it a second time wouldn't have been helpful... One nice thing was the computer had core memory, and the students made an agreement as to who got which part. You could work for a while, shut the machine down, come back the next day, power it up, and your program would still be there. From avigross at verizon.net Thu May 6 15:37:51 2021 From: avigross at verizon.net (Avi Gross) Date: Thu, 6 May 2021 15:37:51 -0400 Subject: Bloody rubbish In-Reply-To: <1bbl9n1y8t.fsf@pfeifferfamily.net> References: <1bbl9n1y8t.fsf@pfeifferfamily.net> Message-ID: <024b01d742af$4dd90fe0$e98b2fa0$@verizon.net> Actually, Joe, putting in any serious program using toggle switches without anything like a BACKSPACE was very hard as I often had to abort and start again. Doing it twice the same way, Argh!!!!!!!!!!!! Luckily, I only had to do it a few times to learn just like I had to write assembler programs or feed in programs from paper tape or from punch cards. Most of us have moved on stage by stage and now tools like Python or libraries and modules often at higher levels are more the norm. Can you imagine taking any modern program in digital form as zeroes and ones and entering it by hand? Some are huge and especially if anything like shared libraries also has to be keyed in. But reminiscing is getting away from the point of expressing our sarcasm about one of the people that makes us want to segregate this forum as one way to not get into silly discussions like this! -----Original Message----- From: Python-list On Behalf Of Joe Pfeiffer Sent: Thursday, May 6, 2021 3:03 PM To: python-list at python.org Subject: Re: Bloody rubbish Skip Montanaro writes: >> >> Machine language is so much simpler, and you can code with just a hexpad. >> > > Pshaa... All you need are front panel switches. ;-) (Yes, I had a > professor who required is to 'key' in our programs on the front panel, > of a rack mounted PDP-11 as I recall. Needless to say, we didn't use > an assembler either. We just wrote raw opcodes and their arguments on > paper. This was in the late 70s.) That's right about whn I had to do that for one assignment (on a Nova). Hand-assembling, toggling in, and debugging a program on the front panel was a valuable learning exercise. Doing it a second time wouldn't have been helpful... One nice thing was the computer had core memory, and the students made an agreement as to who got which part. You could work for a while, shut the machine down, come back the next day, power it up, and your program would still be there. -- https://mail.python.org/mailman/listinfo/python-list From mstemper at gmail.com Thu May 6 16:10:54 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Thu, 6 May 2021 15:10:54 -0500 Subject: Bloody rubbish In-Reply-To: References: Message-ID: On 06/05/2021 11.53, Wayne Lodahl wrote: > On 5/6/21 6:11 AM, Mr Flibble wrote: >> Python is slow and significant whitespace is patently absurd. >> >> Bloody rubbish, it's all bloody rubbish. >> >> Message ends. >> >> /Flibble >> > Machine language is so much simpler, and you can code with just a hexpad. That's what the sixteen toggle switches are for. -- Michael F. Stemper Life's too important to take seriously. From gheskett at shentel.net Thu May 6 16:35:35 2021 From: gheskett at shentel.net (Gene Heskett) Date: Thu, 6 May 2021 16:35:35 -0400 Subject: Bloody rubbish In-Reply-To: References: Message-ID: <202105061635.35347.gheskett@shentel.net> On Thursday 06 May 2021 13:54:23 Skip Montanaro wrote: > > Machine language is so much simpler, and you can code with just a > > hexpad. > > Pshaa... All you need are front panel switches. ;-) (Yes, I had a > professor who required is to 'key' in our programs on the front panel, > of a rack mounted PDP-11 as I recall. Needless to say, we didn't use > an assembler either. We just wrote raw opcodes and their arguments on > paper. This was in the late 70s.) > > Skip That brings back memories. I was the ACE at KRCR in Redding CA, and I saw a huge quality destroying bottleneck in producing our own commercials and proposed to the GM that I wanted to learn something about computers, and I thought it would be a way around it, by having it installi the cue tones that made an autmatic station break sequencer work, as opposed to copying a blank tape from a poor master, then dub copying the finished commercial to the bad copy. Sounded like a good idea, so I ordered a quest super elf board which only had a hex keypad and hex monitor, along with a copy of RCA's programming the 1802. This was in 1978 IIRC. That grew an s-100 backplane and a $400 4k of static ram kit. And I built the rest of the interfaceing including the video to lay a new, digital academy leader countdown out of whole cloth. Then I eventually went down the road in search of taller grass. I left instructions as to how to patch it for for the ballistics of newer tape machines and forgot about it, eventually landing for good in WV as the CE at a CBS affiliate in '84. In '94, I took my then fairly new wife who has now passed on from COPD, to meet an aunt of mine, in her 80's as I figured I was running out of time to do that, so we booked a flight to Portland and she would meet us there and take us to her place in Salem. While there, I called that tv station and found out they were still using my gismo. 16+ years in a tv stations control room is unheard of but they said it was working fine and was one heck of a labor saver. With memory of only 4k, I used a lot of self-modifying code, but was very carefull to re-init it at the top of the loop. It didn't crash, ever. I shanghied an old cart deck that was off speed for power failure recovery storage since the thing had only a 256 byte boot eprom. When I left I took a cart with 3 copy's on it, and a paper copy of the hex codes and assembly nemonics if it ever grew an assembler, which it didn't. I can reach it by standing up to reach the shelf it is on above me. And if I had to fix it today, I could "get my head" back into "my head" easier than I can make python work when it doesn't. I'm lurking here, trying to learn about python, but TBT, most of you are talking above my pay grade. Way too afraid you are doing some students homework rather than dropping into teacher mode, a fault of this list. Take care and stay well, all of you. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page From grant.b.edwards at gmail.com Thu May 6 13:10:00 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 17:10:00 -0000 (UTC) Subject: Bloody rubbish References: <1bfsz01sbl.fsf@pfeifferfamily.net> <4e9cbae0-728c-6787-708b-9badfde15706@gmail.com> Message-ID: On 2021-05-06, Michael Torrie wrote: > On 5/5/21 8:58 PM, Joe Pfeiffer wrote: >> Mr Flibble writes: >> >>> Python is slow and significant whitespace is patently absurd. >> >> Why am I not surprised to learn your "fast" implementation turns out to >> be something other than python? > > And it's bizarre that the OP, since he despises Python so much, and > finds its syntax absurd, would even bother to make any sort of > implementation of it. It would be bizarre, except he's trolling -- so it's just boring and predictable. From grant.b.edwards at gmail.com Thu May 6 13:47:00 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 6 May 2021 17:47:00 -0000 (UTC) Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> <8eldmh-pp261.ln1@esprimo.zbmc.eu> Message-ID: On 2021-05-06, Chris Green wrote: > Grant Edwards wrote: >> On 2021-05-06, Chris Green wrote: >> > Grant Edwards wrote: >> > >> >> Pointing a newsreader at news.gmane.io allows one to participate in >> >> the mailing list just fine without using Usenet. >> >> >> > ??? Surely that *is* using Usenet, at least you're using NNTP which >> > is the Usenet protocol. What's "not Usenet" about it? >> >> Usenet was a distributed network of computers that transferred >> articles amongst themselves using various protocols, and provided >> access to readers in various ways (NNTP being one of them). >> > Usenet *is* still this Good point. >> Gmane was not and is not part of that network. It is a single, >> stand-alone machine operating as an email list archiver/gateway that >> provides access to read/post via NTTP. > > It is effectively part of Usenet because the mailing lists it hosts > and gateways to its newserver are peered with Usenet. I don't consider that as "being part of Usenet". Being part of Usenet means that you peer with other the news hosts within Usenet, provide the same group hiearchary (or some defined subset) and obey the normal newsgroup control messages. > I read several gmane 'lists' via usenet, I most certainly don't get > them directly from gmane, I get them from other usenet servers. Are you saying that the gmane news server is peered with other news servers? And that you can read gmane.comp.python.general on other news servers? That didn't used to be the case... From arj.python at gmail.com Thu May 6 16:47:13 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Fri, 7 May 2021 00:47:13 +0400 Subject: Bloody rubbish In-Reply-To: <202105061635.35347.gheskett@shentel.net> References: <202105061635.35347.gheskett@shentel.net> Message-ID: @Gene Heskett That ran deep. I was going to ask you were doing in PythonLand but you answered it at the end. Maybe i should ask what made you interested in Python in the first place? From ethan at stoneleaf.us Thu May 6 17:19:13 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 6 May 2021 14:19:13 -0700 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: On 5/6/21 11:05 AM, Jon Ribbens via Python-list wrote: > On 2021-05-06, Stestagg wrote: >> Where's this discussion going? >> >> Which of the practically possible options are best for this list <-> >> newsgroup setup? > > And it appears even the suggestion that > Mailman 3 cannot be used while a gateway is involved is untrue: > https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/nntp.html Interesting. I know the NNTP gateway wasn't there a couple years ago, and I do not see a date as to when that became possible. -- ~Ethan~ From python at mrabarnett.plus.com Thu May 6 20:23:12 2021 From: python at mrabarnett.plus.com (MRAB) Date: Fri, 7 May 2021 01:23:12 +0100 Subject: Bloody rubbish In-Reply-To: <202105061635.35347.gheskett@shentel.net> References: <202105061635.35347.gheskett@shentel.net> Message-ID: <68655631-f555-67d9-4336-98cf4497d245@mrabarnett.plus.com> On 2021-05-06 21:35, Gene Heskett wrote: > On Thursday 06 May 2021 13:54:23 Skip Montanaro wrote: > >> > Machine language is so much simpler, and you can code with just a >> > hexpad. >> >> Pshaa... All you need are front panel switches. ;-) (Yes, I had a >> professor who required is to 'key' in our programs on the front panel, >> of a rack mounted PDP-11 as I recall. Needless to say, we didn't use >> an assembler either. We just wrote raw opcodes and their arguments on >> paper. This was in the late 70s.) >> [snip] > Sounded like a good idea, so I ordered a quest super elf board which only > had a hex keypad and hex monitor, along with a copy of RCA's programming > the 1802. This was in 1978 IIRC. That grew an s-100 backplane and a > $400 4k of static ram kit. And I built the rest of the interfaceing > including the video to lay a new, digital academy leader countdown out > of whole cloth. > 4K? Luxury! My first machine was a Mk14 from Science of Cambridge. I had the extra RAM and the I/O chip, giving a total of 768 bytes (256 + 256 + 128, non-contiguous, of course). And one of the bits in the second block was faulty. From greg.ewing at canterbury.ac.nz Thu May 6 20:41:44 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 7 May 2021 12:41:44 +1200 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <1a32020c-d326-c23f-7aea-c72dccea20b1@Damon-Family.org> <6967141d-f743-4970-937f-d959eccca14c@Damon-Family.org> <0a153811-47b5-3dde-b62e-15345114b672@Damon-Family.org> <5b84721e-4547-9c42-b997-2262696b5db2@Damon-Family.org> Message-ID: My opinion on all this: The volume in this newsgroup is nowhere near high enough to be worth changing anything. This thread itself now contains more messages than the recent neopython trollage that prompted it. -- Greg From cl at isbd.net Fri May 7 04:24:48 2021 From: cl at isbd.net (Chris Green) Date: Fri, 7 May 2021 09:24:48 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <02f901d74210$a55d3ce0$f017b6a0$@verizon.net> <8eldmh-pp261.ln1@esprimo.zbmc.eu> Message-ID: Grant Edwards wrote: > On 2021-05-06, Chris Green wrote: > > Grant Edwards wrote: > >> On 2021-05-06, Chris Green wrote: > >> > Grant Edwards wrote: > >> > > >> >> Pointing a newsreader at news.gmane.io allows one to participate in > >> >> the mailing list just fine without using Usenet. > >> >> > >> > ??? Surely that *is* using Usenet, at least you're using NNTP which > >> > is the Usenet protocol. What's "not Usenet" about it? > >> > >> Usenet was a distributed network of computers that transferred > >> articles amongst themselves using various protocols, and provided > >> access to readers in various ways (NNTP being one of them). > >> > > Usenet *is* still this > > Good point. > > >> Gmane was not and is not part of that network. It is a single, > >> stand-alone machine operating as an email list archiver/gateway that > >> provides access to read/post via NTTP. > > > > It is effectively part of Usenet because the mailing lists it hosts > > and gateways to its newserver are peered with Usenet. > > I don't consider that as "being part of Usenet". Being part of Usenet > means that you peer with other the news hosts within Usenet, provide > the same group hiearchary (or some defined subset) and obey the normal > newsgroup control messages. > > > I read several gmane 'lists' via usenet, I most certainly don't get > > them directly from gmane, I get them from other usenet servers. > > Are you saying that the gmane news server is peered with other news > servers? And that you can read gmane.comp.python.general on other news > servers? That didn't used to be the case... > Yes, that's exactly what I'm saying. ... ah, but, you're probably right! Sorry. I've just looked at my leafnode configuration and I *have* got news.gmane.io in there. I must have done it so long ago that I'd forgotten all about it. -- Chris Green ? From arj.python at gmail.com Fri May 7 05:55:36 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Fri, 7 May 2021 13:55:36 +0400 Subject: Understanding PyPi download stats Message-ID: Greetings list, See these two links below providing download stats for a package: 1) https://pypistats.org/packages/shopyo 2) https://pepy.tech/project/shopyo Particularly for 2) Are the data accurate? Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From mishrasamir2004 at gmail.com Fri May 7 07:09:07 2021 From: mishrasamir2004 at gmail.com (mishrasamir2004 at gmail.com) Date: Fri, 7 May 2021 16:39:07 +0530 Subject: for installation of pygames. Message-ID: <6078A1D8-B1B2-4AA0-A874-40EC5F974C49@hxcore.ol> Sir/madam, I'm a user of python , so I'm requesting you to give me permission to run pygames . Thankyou Samir Mishra Sent from [1]Mail for Windows References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 From rsstinnett at gmail.com Fri May 7 12:51:24 2021 From: rsstinnett at gmail.com (Russell) Date: Fri, 7 May 2021 16:51:24 +0000 (UTC) Subject: for installation of pygames. References: <6078A1D8-B1B2-4AA0-A874-40EC5F974C49@hxcore.ol> Message-ID: mishrasamir2004 at gmail.com wrote: > Sir/madam, > > I'm a user of python , so I'm requesting you to give me permission to run > pygames . > > Thankyou > > Samir Mishra > > > > > > Sent from [1]Mail for Windows > > References > > Visible links > 1. https://go.microsoft.com/fwlink/?LinkId=550986 You have my permission. -- rust 0x68caecc97f6a90122e51c0692c88d9cb6b58a3dc From garyfallidis at gmail.com Fri May 7 13:14:30 2021 From: garyfallidis at gmail.com (Eleftherios Garyfallidis) Date: Fri, 7 May 2021 13:14:30 -0400 Subject: ANN: DIPY 1.4.1 Released! Message-ID: Hello all, We are happy to announce two new releases of DIPY: DIPY 1.4.0 and 1.4.1 are out! Please support us by citing DIPY in your papers using the following DOI: 10.3389/fninf.2014.00008 DIPY 1.4.1 (Thursday, 6 May 2021) & 1.4.0 (Saturday, 13 March, 2021) - Release 1.4.1 received contributions from 11 developers (the full release notes are at: https://dipy.org/documentation/1.4.1./release_notes/release1.4.1/). - Release 1.4.0 received contributions from 8 developers (the full release notes are at: https://dipy.org/documentation/1.4.0./release_notes/release1.4/). Thank you all for your contributions and feedback! Please click here to check 1.4.1 API changes. Please click here to check 1.4.0 API changes. Highlights of 1.4.1 release include: - New surface seeding module for tractography named mesh. - Patch2Self and its documentation updated. - BUAN and RecoBundles documentation updated. - Standardization and improvement of the multiprocessing / multithreading rules. - Community and governance information added. - Large update of Cython code in compliance with the last standard. - Large documentation update. - Closed 61 issues and merged 28 pull requests. Highlights of 1.4.0 release include: - New self-supervised denoising algorithm Patch2Self added. - Response function refactored and clarified. - B-tensor allowed with response functions. - Large Command Line Interface (CLI) documentation updated. - Public API for Registration added. - Large documentation update. - Closed 47 issues and merged 19 pull requests. To upgrade or install DIPY Run the following command in your terminal: pip install --upgrade dipy or conda install -c conda-forge dipy This version of DIPY depends on nibabel (3.0.0+). For visualization you need FURY (0.7.0+). Questions or suggestions? For any questions go to https://dipy.org, or send an e-mail to dipy at python.org We also have an instant messaging service and chat room available at https://gitter.im/dipy/dipy Finally, a new forum is available at https://github.com/dipy/dipy/discussions Have a wonderful time using the latest release. On behalf of the DIPY developers, Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro https://dipy.org/contributors From soyeomul at doraji.xyz Fri May 7 21:48:39 2021 From: soyeomul at doraji.xyz (=?utf-8?B?7Zmp67OR7Z2s?=) Date: Sat, 08 May 2021 10:48:39 +0900 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: Paul Bryan writes: > Given the ease of spoofing sender addresses, and its propensity for use > in anonymous spamming and trolling (thanks python-list-owner for > staying on top of that!), I propose to disconnect comp.lang.python from > the python-list mailing list. Both would then operate independently. Hellow Paul, So now, i think that Evolution should be support for NNTP. Sincerely, Python and Gnus fan Byung-Hee -- ^????? _????_ ?????_^))// From toaster at reddwarf.jmc Sat May 8 08:09:47 2021 From: toaster at reddwarf.jmc (Talkie Toaster) Date: Sat, 8 May 2021 13:09:47 +0100 Subject: Proposal: Disconnect comp.lang.python from python-list In-Reply-To: <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> Message-ID: On 06/05/2021 18:56, Mark Lawrence wrote: > On Thursday, May 6, 2021 at 1:31:28 AM UTC+1, Paul Bryan wrote: >> Given the ease of spoofing sender addresses, and its propensity for use >> in anonymous spamming and trolling (thanks python-list-owner for >> staying on top of that!), I propose to disconnect comp.lang.python from >> the python-list mailing list. Both would then operate independently. >> >> Paul > Quite frankly I don't care how this discussion goes as the Python community discriminates against Asperger's suffers such as myself. > I believe I am also on the spectrum and feel the same way about the fluffy cloud echo chamber for fluffy clouds that is the Python "community". This "code of conduct" bullsh1t is getting out of hand. Message ends. /Toaster From grant.b.edwards at gmail.com Fri May 7 16:55:33 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Fri, 7 May 2021 20:55:33 -0000 (UTC) Subject: for installation of pygames. References: <6078A1D8-B1B2-4AA0-A874-40EC5F974C49@hxcore.ol> Message-ID: On 2021-05-07, wrote: > I'm a user of python , so I'm requesting you to give me permission to run > pygames. I hereby grant you prermistion to run pygames. Are you asking about pygame? You don't need anybody's permission to install and use pygame: https://www.pygame.org/ https://www.pygame.org/wiki/about https://www.pygame.org/wiki/GettingStarted From mishrasamir2004 at gmail.com Sat May 8 10:49:12 2021 From: mishrasamir2004 at gmail.com (mishrasamir2004 at gmail.com) Date: Sat, 8 May 2021 20:19:12 +0530 Subject: for the installation of pycharm Message-ID: <0AE59C6E-2E82-4113-AF3E-6B702EEE2529@hxcore.ol> Sir/madam, Please provide me the latest version of pycharm quickly. Samir Mishra Sent from [1]Mail for Windows 10 References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 From Richard at Damon-Family.org Sat May 8 11:36:48 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Sat, 8 May 2021 11:36:48 -0400 Subject: for the installation of pycharm In-Reply-To: <0AE59C6E-2E82-4113-AF3E-6B702EEE2529@hxcore.ol> References: <0AE59C6E-2E82-4113-AF3E-6B702EEE2529@hxcore.ol> Message-ID: <6db7c884-2506-bd61-2c6c-d0919e784132@Damon-Family.org> On 5/8/21 10:49 AM, mishrasamir2004 at gmail.com wrote: > Sir/madam, > > Please provide me the latest version of pycharm quickly. > > Samir Mishra You just need to go to the jetbrains web site and it is available there. They even have a free version there. -- Richard Damon From codemouse92 at outlook.com Sat May 8 10:48:42 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sat, 8 May 2021 14:48:42 -0000 (UTC) Subject: Bloody rubbish References: <1bfsz01sbl.fsf@pfeifferfamily.net> <4e9cbae0-728c-6787-708b-9badfde15706@gmail.com> Message-ID: Haha, I've encountered this guy several times around USENET and IRC. Among his other claims, he's building a compiler that compiles every language, and he invented smartphones. That's what we call "all hat and no cattle". ;) I mostly haven't plonked him for the entertainment value. On 2021-05-06, Michael Torrie wrote: > On 5/5/21 8:58 PM, Joe Pfeiffer wrote: >> Mr Flibble writes: >> >>> Python is slow and significant whitespace is patently absurd. >> >> Why am I not surprised to learn your "fast" implementation turns out to >> be something other than python? > > And it's bizarre that the OP, since he despises Python so much, and > finds its syntax absurd, would even bother to make any sort of > implementation of it. > -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From codemouse92 at outlook.com Sat May 8 10:54:14 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sat, 8 May 2021 14:54:14 -0000 (UTC) Subject: for the installation of pycharm References: <0AE59C6E-2E82-4113-AF3E-6B702EEE2529@hxcore.ol> Message-ID: You might try their official website. A casual web search will bring it up for you. Just type "pycharm" into your favorite search engine. On 2021-05-08, wrote: > Sir/madam, > > Please provide me the latest version of pycharm quickly. > > Samir Mishra > > > > > > Sent from [1]Mail for Windows 10 > > > > References > > Visible links > 1. https://go.microsoft.com/fwlink/?LinkId=550986 -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From codemouse92 at outlook.com Sat May 8 11:29:15 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sat, 8 May 2021 15:29:15 -0000 (UTC) Subject: Bloody rubbish References: <1bfsz01sbl.fsf@pfeifferfamily.net> <4e9cbae0-728c-6787-708b-9badfde15706@gmail.com> Message-ID: He also uses sockpuppets as a hobby, clearly. That project has been "under construction" in its early phases for quite a long time. It's certainly not at the state where "he" can brag about it like he does. And being part of a team that built a smartphone is not the same as inventing smartphones. That's just braggery. And another one bites the plonk. :)) On 2021-05-08, Talkie Toaster wrote: > Claim #1, "he's building a compiler that compiles every language": > > Yes, he is, the project website is https://neos.dev and the project is open > source on github. > > Claim #2, "he invented smartphones": > > Yes, he did (as part of a team) create the first smartphone, > the Ericsson R380: > > https://en.wikipedia.org/wiki/Ericsson_R380 > > /Toaster -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From mirkok.lists at googlemail.com Sat May 8 17:28:40 2021 From: mirkok.lists at googlemail.com (Mirko) Date: Sat, 8 May 2021 23:28:40 +0200 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> Message-ID: <60970288.1070209@googlemail.com> I apologize for this OT post, especially because it's in reply to an at least partly troll post, but I just can't resist. Sorry. Am 08.05.2021 um 14:09 schrieb Talkie Toaster: > On 06/05/2021 18:56, Mark Lawrence wrote: >> Quite frankly I don't care how this discussion goes as the Python >> community discriminates against Asperger's suffers such as myself. >> > > I believe I am also on the spectrum and feel the same way about the > fluffy cloud echo chamber for fluffy clouds that is the Python > "community". I'm also on the autism spectrum but I do *NOT* appreciate how you both instrumentalize our condition and use it as a self-righteous self-defense and how you politicized it. One of the core aspects of ASS is that we have difficulties understanding and following common and accepted social norms. But that is not a carte blanche for every kind of misbehavior. I don't call myself Aspie for no reason. I believe that we have a right to be what we are and to live according to our needs, situations, conditions and specialties. But that doesn't mean that the rest of the world has to unilaterally adapt to us. It's both sides! The world needs to understand that our behavior is a little different we need to understand that our behavior is sometimes off the limits. We need to learn -- both sides -- how to live together and we need to learn to *RESPECT* each other. > This "code of conduct" bullsh1t is getting out of hand. Unless the CoD includes ASS of course! Isn't it?! ;-) You complain about a "fluffy cloud echo chamber", but you are *calling* for the *same*. A fluffy cloud echo chamber where no ASS person is ever called for any possibly disrespecting words or behavior. A fluffy cloud echo chamber where everybody just accepts and respects you for what you are. Does the concept sound familiar? P.S.: *NOT* among the core symptoms of (the high-functioning levels) of ASS is the inability to learn. Mind that! (And that includes social norms.) From codemouse92 at outlook.com Sat May 8 20:23:34 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sun, 9 May 2021 00:23:34 -0000 (UTC) Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> Message-ID: Very well said! It's quite easy to use one's disadvantages as an excuse for anti-social behavior. The Code of Conduct certainly isn't perfect, but it has proven to be one of the most effective tools in keeping a community healthy. Usually, I find when people dump on CoCs, they're just angry at accountability. I haven't known anyone yet who was a productive member of Python and opposed to the CoC, at least in principle and aim. On 2021-05-08, Mirko wrote: > > I apologize for this OT post, especially because it's in reply to an > at least partly troll post, but I just can't resist. Sorry. > > > Am 08.05.2021 um 14:09 schrieb Talkie Toaster: >> On 06/05/2021 18:56, Mark Lawrence wrote: > >>> Quite frankly I don't care how this discussion goes as the Python >>> community discriminates against Asperger's suffers such as myself. >>> >> >> I believe I am also on the spectrum and feel the same way about the >> fluffy cloud echo chamber for fluffy clouds that is the Python >> "community". > > I'm also on the autism spectrum but I do *NOT* appreciate how you > both instrumentalize our condition and use it as a self-righteous > self-defense and how you politicized it. > > One of the core aspects of ASS is that we have difficulties > understanding and following common and accepted social norms. But > that is not a carte blanche for every kind of misbehavior. I don't > call myself Aspie for no reason. I believe that we have a right to > be what we are and to live according to our needs, situations, > conditions and specialties. But that doesn't mean that the rest of > the world has to unilaterally adapt to us. It's both sides! The > world needs to understand that our behavior is a little different we > need to understand that our behavior is sometimes off the limits. We > need to learn -- both sides -- how to live together and we need to > learn to *RESPECT* each other. > >> This "code of conduct" bullsh1t is getting out of hand. > > Unless the CoD includes ASS of course! Isn't it?! ;-) > > You complain about a "fluffy cloud echo chamber", but you are > *calling* for the *same*. A fluffy cloud echo chamber where no ASS > person is ever called for any possibly disrespecting words or > behavior. A fluffy cloud echo chamber where everybody just accepts > and respects you for what you are. Does the concept sound familiar? > > > P.S.: *NOT* among the core symptoms of (the high-functioning levels) > of ASS is the inability to learn. Mind that! (And that includes > social norms.) -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From torriem at gmail.com Sat May 8 20:34:23 2021 From: torriem at gmail.com (Michael Torrie) Date: Sat, 8 May 2021 18:34:23 -0600 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: <60970288.1070209@googlemail.com> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> Message-ID: On 5/8/21 3:28 PM, Mirko via Python-list wrote: > > I apologize for this OT post, especially because it's in reply to an > at least partly troll post, but I just can't resist. Sorry. > > P.S.: *NOT* among the core symptoms of (the high-functioning levels) > of ASS is the inability to learn. Mind that! (And that includes > social norms.) Thank you for posting such an insightful comment. No need to apologize. I really appreciate it. I think you are exactly correct. From torriem at gmail.com Sat May 8 21:08:51 2021 From: torriem at gmail.com (Michael Torrie) Date: Sat, 8 May 2021 19:08:51 -0600 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> Message-ID: <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> On 5/8/21 6:23 PM, Jason C. McDonald wrote: > Usually, I find when people dump on CoCs, they're just angry at > accountability. I haven't known anyone yet who was a productive > member of Python and opposed to the CoC, at least in principle > and aim. I disagree. Many people are opposed to CoCs for a variety of reasons including the fact that many CoCs are political in nature. Others oppose them for legal liability reasons. On his radio show Ask Noah (a radio show about Linux), Noah has interviewed several people who oppose CoCs for political and legal reasons. The Southeast Linux Fest in particular explicitly decided not to have a CoC for mostly legal reasons (which he described in episode 80). I do agree asking people to simply not be stupid doesn't seem to work these days for whatever reason. From rosuav at gmail.com Sat May 8 21:26:45 2021 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 9 May 2021 11:26:45 +1000 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: On Sun, May 9, 2021 at 11:10 AM Michael Torrie wrote: > > On 5/8/21 6:23 PM, Jason C. McDonald wrote: > > Usually, I find when people dump on CoCs, they're just angry at > > accountability. I haven't known anyone yet who was a productive > > member of Python and opposed to the CoC, at least in principle > > and aim. > > I disagree. Many people are opposed to CoCs for a variety of reasons > including the fact that many CoCs are political in nature. Others > oppose them for legal liability reasons. On his radio show Ask Noah (a > radio show about Linux), Noah has interviewed several people who oppose > CoCs for political and legal reasons. The Southeast Linux Fest in > particular explicitly decided not to have a CoC for mostly legal reasons > (which he described in episode 80). > > I do agree asking people to simply not be stupid doesn't seem to work > these days for whatever reason. Probably the same reason it has never worked. The only thing that's changed is the social acceptability of vilifying those you don't like. Once upon a time, there were those in the community who had all the power, and those on the fringes that had none, and if someone on the fringe misbehaved, everyone inside just shunned them and they left. Now, if someone on the fringe misbehaves and everyone treats them badly, there's a massive political kerfuffle and everyone gets hurt. I'm not saying that the previous situation was GOOD, but I'm far from sure that the current situation is any better - look at the arguments regarding branch naming, which completely sidelined all technical considerations in favour of one single political motivation based heavily on the decisions of people from one specific country. ChrisA From arj.python at gmail.com Sun May 9 04:31:49 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Sun, 9 May 2021 12:31:49 +0400 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: On Sun, May 9, 2021 at 5:29 AM Chris Angelico wrote: > > Probably the same reason it has never worked. The only thing that's > changed is the social acceptability of vilifying those you don't like. > Once upon a time, there were those in the community who had all the > power, and those on the fringes that had none, and if someone on the > fringe misbehaved, everyone inside just shunned them and they left. > Now, if someone on the fringe misbehaves and everyone treats them > badly, there's a massive political kerfuffle and everyone gets hurt. Just a note here, though not in relation to CoC but as someone speaking English far away from a country called America, sometimes i wonder at some changes introduced just because it does not ring well within the country. I agree that the US pushed many many changes used around the world but English is not the property of the people of a specific country. The English community is the sum of people speaking English over the world. Though i am very far from CPython contributions but once changes no longer occur on the basis of technical reasons it raises eyebrows far beyond CPython contributors. Now in the Python community we must verify not only grammatical and structural errors but also US-based nuances in the language. This requires community folks to be in tune with American current affairs and ideological tendencies. This might be a bit too much work as the bridge of union of the community is the Python language, usage and tools. Though English is a core-part of the programming language, this is going too deep. A practical effect of this is that each and every event posters, flyers and websites have to be double checked against US nuances and phrasing. And the PSF must make sure that events sponsored by it or affiliated must follow the same standards. This post is in no way a US-bashing one, or intended to be hurtful in any way. It's an observation that some changes appear totally ok to english speakers until you understand that this and that sounds wrong in a particular country. This poses the question of the legitimacy of the influence of a certain nation over the PSF. Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From arj.python at gmail.com Sun May 9 04:33:38 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Sun, 9 May 2021 12:33:38 +0400 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: I meant to quote this part actually: I'm not saying that the previous situation was GOOD, but I'm far from sure that the current situation is any better - look at the arguments regarding branch naming, which completely sidelined all technical considerations in favour of one single political motivation based heavily on the decisions of people from one specific country. Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From PythonList at DancesWithMice.info Sun May 9 05:55:28 2021 From: PythonList at DancesWithMice.info (dn) Date: Sun, 9 May 2021 21:55:28 +1200 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: <4f0047ed-6254-413b-55fa-b23ea7190f6a@DancesWithMice.info> On 09/05/2021 20.31, Abdur-Rahmaan Janhangeer wrote: > On Sun, May 9, 2021 at 5:29 AM Chris Angelico wrote: > >> >> Probably the same reason it has never worked. The only thing that's >> changed is the social acceptability of vilifying those you don't like. >> Once upon a time, there were those in the community who had all the >> power, and those on the fringes that had none, and if someone on the >> fringe misbehaved, everyone inside just shunned them and they left. >> Now, if someone on the fringe misbehaves and everyone treats them >> badly, there's a massive political kerfuffle and everyone gets hurt. > > > Just a note here, though not in relation to CoC but > as someone speaking English far away from a country > called America, sometimes i wonder at some changes > introduced just because it does not ring well within the > country. I agree that the US pushed many many changes > used around the world but English is not the property of > the people of a specific country. The English community > is the sum of people speaking English over the world. > Though i am very far from CPython contributions but once > changes no longer occur on the basis of technical reasons > it raises eyebrows far beyond CPython contributors. > > Now in the Python community we must verify not only > grammatical and structural errors but also US-based > nuances in the language. This requires community > folks to be in tune with American current affairs and > ideological tendencies. This might be a bit too much > work as the bridge of union of the community is the Python > language, usage and tools. Though English is a core-part > of the programming language, this is going too deep. > > A practical effect of this is that each and every event > posters, flyers and websites have to be double checked > against US nuances and phrasing. And the PSF must > make sure that events sponsored by it or affiliated must > follow the same standards. > > This post is in no way a US-bashing one, or intended to be > hurtful in any way. It's an observation that some changes > appear totally ok to english speakers until you understand > that this and that sounds wrong in a particular country. This > poses the question of the legitimacy of the influence of a certain > nation over the PSF. +1 The inherent problem however, is that an author can only write from his/her own position. Few have lived in multiple cultures. Even fewer have taken the trouble to understand such differences. It is often difficult-enough to write what needs to be said in a cogent fashion, without having to double-guess how multiple cultures might prefer things be done. That said, there is nothing to be gained by upsetting people... Nevertheless, when the Linux Foundation announced a discussion looking into such (largely) US-concerning terms as Master/Slave in computing contexts, the same newsletter blatantly localised events which were publicised, and intended to draw, world-wide participation. (and has yet to respond to my observation of same) The ISO 8601 International Standard recommends usage of UTC "Universal Time" as a means for communicating times and dates in an international or multinational context, ie "interchange". (So the LF's advert of a Rust seminar commencing at a time listed in "CEST" is unfriendly and somewhat inconsiderate to people outside Europe) - example to prove we're not 'US-bashing', even though similar US-based examples would be very easy to quote. ISO 8601 was updated with 'Part 2' in 2019. It deals with "common expressions". Many of which are meaningless, or even misleading to others. In this case, an invitation to "Spring Internships" seemed six months early to me. However, it is 'now' to anyone in the US. Such seasonal terms only apply to the temperate zones of this planet - neither the tropics nor the poles have such seasons, plus many cultures use other terms for specific times of year, eg "Monsoon Season". Thus, are not appropriate for use amongst an international audience. Web.Ref: Amusing discussion of ISO 8601:2019 (not the usual dry and turgid documentation one expects from a standards organisation) https://www.iso.org/news/2017/02/Ref2164.html -- Regards, =dn From arj.python at gmail.com Sun May 9 08:20:50 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Sun, 9 May 2021 16:20:50 +0400 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: <4f0047ed-6254-413b-55fa-b23ea7190f6a@DancesWithMice.info> References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> <4f0047ed-6254-413b-55fa-b23ea7190f6a@DancesWithMice.info> Message-ID: On Sun, May 9, 2021 at 1:58 PM dn via Python-list wrote: > That said, there is nothing to be gained by upsetting people... > I misquoted the relevant section from Chris' answer, i wanted to quote: *I'm not saying that the previous situation was GOOD, but I'm far fromsure that the current situation is any better - look at the argumentsregarding branch naming, which completely sidelined all technicalconsiderations in favour of one single political motivation basedheavily on the decisions of people from one specific country.* More about changes like the above. Nevertheless, when the Linux Foundation announced a discussion looking > into such (largely) US-concerning terms as Master/Slave in computing > contexts, the same newsletter blatantly localised events which were > publicised, and intended to draw, world-wide participation. > (and has yet to respond to my observation of same) > > The ISO 8601 International Standard recommends usage of UTC "Universal > Time" as a means for communicating times and dates in an international > or multinational context, ie "interchange". (So the LF's advert of a > Rust seminar commencing at a time listed in "CEST" is unfriendly and > somewhat inconsiderate to people outside Europe) > - example to prove we're not 'US-bashing', even though similar US-based > examples would be very easy to quote. > > ISO 8601 was updated with 'Part 2' in 2019. It deals with "common > expressions". Many of which are meaningless, or even misleading to > others. In this case, an invitation to "Spring Internships" seemed six > months early to me. However, it is 'now' to anyone in the US. Such > seasonal terms only apply to the temperate zones of this planet - > neither the tropics nor the poles have such seasons, plus many cultures > use other terms for specific times of year, eg "Monsoon Season". Thus, > are not appropriate for use amongst an international audience. > The examples you quote are very tangible, clearly defined and easily associated Master-slave has obvious meanings, CEST is associated with a particular area and preferring another timezone would put other people at disadvantages. The iso part 2 saute a l'oeil (triggers your sensors, litt. jumps at your eye), spring automatically spells confusions as spring goes in the same direction as timezones I was pointing out to politically related changes whose obviousness and correctness is not gauged from empirical analysis of elements in front of you but requires the further step of knowing what the American people deem as right or wrong not in the sense of morals directly but more of how the country and people live. Let's say the word mouse. A mouse is a mouse, the rodent. But now some bad people take the mouse as their symbol. They put the mouse on their bags, robes, curtains, laptops, pens thereby demonising the mouse. Now mouse lovers are also associated to these people as well as people who care for mouse wellness in laboratories. This happens in Fake Country X. Now some in a country studied English and learnt that a mouse is a four tiny- footed creature with a tail. Being a mouse lover the person decided to name a Python conference PyMouse. Now people start dramatising the situation and label the person as someone not to be collaborated with, someone to be banned from all Py affiliated enterprises. Well that is very bad to begin with. A mouse remains a mouse and the bad folks using the mouse as their symbol exists in majority only in Fake Country X. Someone outside Fake Country X never had the chance to study or imbibe himself with or come across the association of this with that. You presented some cases which are very valid and correct, but i was referring to changes which are not so blatant and obvious. Cases which are wrong for some people but right for others not because of moral correctness directly but more because of associations present in a particular country. Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From codemouse92 at outlook.com Sat May 8 21:15:38 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sun, 9 May 2021 01:15:38 -0000 (UTC) Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: > I disagree. Many people are opposed to CoCs for a variety of reasons > including the fact that many CoCs are political in nature. Others > oppose them for legal liability reasons. On his radio show Ask Noah (a > radio show about Linux), Noah has interviewed several people who oppose > CoCs for political and legal reasons. The Southeast Linux Fest in > particular explicitly decided not to have a CoC for mostly legal reasons > (which he described in episode 80). That may well be. However, further complicating it are the people who dislike accountability, as I first mentioned, but *reframe it* as a "policial" or "legal" issue. There's no shortage of that, especially in 2021. If only we had a way to clear that smoke away and find out what earnest objections remain. I, for one, haven't encountered any that didn't turn out to be the aforementioned on further inspection. (But I don't know all cases either.) > I do agree asking people to simply not be stupid doesn't seem to work > these days for whatever reason. I hadn't noticed. ;) -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From arj.python at gmail.com Sun May 9 13:26:04 2021 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Sun, 9 May 2021 21:26:04 +0400 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: Greetings, Out of curiosity, how do people without a Code of Conduct manage and prevent abuse in between people? I was about to organise something last year but did not find a better solution than a code of conduct to ensure smoothness. Well the idea was a before-hand signed code of conduct. It becomes more of an agreement, a pact of good conduct. But i wonder how you handle banning it altogether? Like what happens in the case of abuse. What if you ban and people ask why? How do organisers justify their actions? Even if a code of conduct rings not great with some people, at least it can serve as a hint and guiding principles. Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius From torriem at gmail.com Sun May 9 15:34:01 2021 From: torriem at gmail.com (Michael Torrie) Date: Sun, 9 May 2021 13:34:01 -0600 Subject: OT: Autism in discussion groups (was: Re: Proposal: Disconnect comp.lang.python from python-list) In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> <8b239d78-9cd3-48a7-a2b6-d8f46084df0a@gmail.com> Message-ID: <450f51e5-df7c-7a7d-8788-59a439ea2c47@gmail.com> On 5/9/21 11:26 AM, Abdur-Rahmaan Janhangeer wrote: > Out of curiosity, how do people without a Code of Conduct > manage and prevent abuse in between people? I was about > to organise something last year but did not find a better solution > than a code of conduct to ensure smoothness. Well the idea was a > before-hand signed code of conduct. It becomes more of an > agreement, a pact of good conduct. But i wonder how you > handle banning it altogether? Like what happens in the case of > abuse. What if you ban and people ask why? How do organisers > justify their actions? Even if a code of conduct rings not great with > some people, at least it can serve as a hint and guiding principles. An interesting perspective on codes of conduct and SELF: https://podcast.asknoahshow.com/80, partial transcript at http://techrights.org/2019/06/15/jeremy-sands-and-imposed-coc/ From mal at europython.eu Mon May 10 07:25:57 2021 From: mal at europython.eu (M.-A. Lemburg) Date: Mon, 10 May 2021 13:25:57 +0200 Subject: EuroPython 2021: Call for Proposals (CFP) extended until May 16 Message-ID: <63df5cc6-2817-05c2-6d95-b01324f5cda1@europython.eu> We've decided to extend the deadline for our Call for Proposals until Sunday, May 16, 23:59:59 CEST. We are still looking for a few more proposals, especially for posters, training sessions, and helpdesks. For more information about submitting a proposal, you can read the original blog post announcing the Call for Proposals: https://blog.europython.eu/europython-2021-call-for-proposals-open-cfp/ To submit a proposal directly, please log in to the site (or create an account first) and then proceed to the CFP page: * EuroPython 2021 Call for Proposals (CFP) * https://ep2021.europython.eu/events/call-for-proposals/ If you have questions, please write to program at europython.eu. Quick Summary ------------- EuroPython 2021 will be run online from July 26 - August 1: - Two workshop/training days (July 26 - 27) - Three conference days (July 28 - 30) - Two sprint days (July 31 - August 1) The sessions will be scheduled to ensure they are also accessible for those in the Asian and Americas time zones. Help spread the word -------------------- Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/europython-2021-cfp-extended-until-may-16/ Tweet: https://twitter.com/europython/status/1391714627315195906 Enjoy, -- EuroPython 2021 Team https://ep2021.europython.eu/ https://www.europython-society.org/ From aeros167 at gmail.com Mon May 10 09:16:54 2021 From: aeros167 at gmail.com (Kyle Stanley) Date: Mon, 10 May 2021 09:16:54 -0400 Subject: The importance of mental health Message-ID: Hey all, In these last few months, I have been in the process of healing from some pretty heavy past trauma. And now that I am on the road to recovery, I want to share my journey with the Python community in hopes that it may reach those that are struggling with their own mental health battles, as many of us are during these dark and difficult times. Trigger warning that it includes a decent amount of highly personal content, so only check it out if you are okay with that: https://discuss.python.org/t/break-from-open-source/6372/7?u=aeros. To anyone that would limit my employment opportunities as a result of having had these struggles, *that's perfectly okay*. I kept the post in the private section because I was originally in fear of discriminate. However, I have reached an important conclusion: *I would not want to work for your company if you discriminate against people who have overcome past struggles* . -- --Kyle R. Stanley, Python Core Developer (what is a core dev? ) *Pronouns: they/them **(why is my pronoun here?* ) From stephie at osohq.com Mon May 10 10:09:57 2021 From: stephie at osohq.com (Stephie Glaser) Date: Mon, 10 May 2021 10:09:57 -0400 Subject: Implementing role-based access control (RBAC) in Flask Message-ID: Many frameworks and libraries provide plug-ins for common authorization patterns like roles, but either don't provide enough of a model to be helpful or are so rigid that you need to migrate away from them down the line. We just released a library that provides a configuration-based approach to adding role-based access control (RBAC) to your application. The new Oso Roles library, with support for Python + Flask, speeds up the time it takes to build fine-grained permissions using roles and related patterns. The library includes: - Role configuration - Data management - Enforcement - End-user configuration - Last-mile customizations The library is in early access. Here are relevant links: - Documentation showing how to how to use the library to add roles to a Flask app with GitClub, our best practice example app: http://docs.osohq.com/python/guides/new-roles.html - GitClub source code: https://github.com/osohq/gitclub-sqlalchemy-flask-react Stephie Glaser Developer Relations, Oso From kliateni at gmail.com Mon May 10 11:16:48 2021 From: kliateni at gmail.com (The Walking Trade) Date: Mon, 10 May 2021 11:16:48 -0400 Subject: The importance of mental health In-Reply-To: References: Message-ID: Hello Kyle, I don't personally know you but I am glad you are on the recovery side. Regards Karim Le lun. 10 mai 2021 ? 09:20, Kyle Stanley a ?crit : > Hey all, > > In these last few months, I have been in the process of healing from some > pretty heavy past trauma. And now that I am on the road to recovery, I want > to share my journey with the Python community in hopes that it may reach > those that are struggling with their own mental health battles, as many of > us are during these dark and difficult times. > > Trigger warning that it includes a decent amount of highly personal > content, so only check it out if you are okay with that: > https://discuss.python.org/t/break-from-open-source/6372/7?u=aeros. > > To anyone that would limit my employment opportunities as a result of > having had these struggles, *that's perfectly okay*. I kept the post in the > private section because I was originally in fear of discriminate. However, > I have reached an important conclusion: *I would not want to work for your > company if you discriminate against people who have overcome past > struggles* > . > > -- > --Kyle R. Stanley, Python Core Developer (what is a core dev? > ) > *Pronouns: they/them **(why is my pronoun here?* > < > http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/ > > > ) > -- > https://mail.python.org/mailman/listinfo/python-list > From jfine2358 at gmail.com Mon May 10 10:37:56 2021 From: jfine2358 at gmail.com (Jonathan Fine) Date: Mon, 10 May 2021 07:37:56 -0700 (PDT) Subject: OT: Accessibility: Jana Schroeder's Holman Prize Application Message-ID: Perhaps Off Topic, but for a good cause. This year I met Jana Schroeder, a blind person forced to change jobs as part of the social cost of Covid. Her outsider experience of computer coding training became a wish to make things better. She has applied for a Holman Prize ($25,000 over a year) to fund this. She's also set up a survey to reach and know better those with similar wishes. One simple way to help open to many is to volunteer to be a sighted helper for a code and math variant of BeMyEyes.org. I encourage you to listen to Jana's pitch for a Holman prize, and if you want to help complete the survey (whether you're blind or sighted, code or math, young or old). I've learnt a lot about accessibility from Jana. Jana Schroeder's Holman pitch (90 seconds): https://www.youtube.com/watch?v=3ywl5d162vU Jana Schroeder's survey (15 minutes): https://tinyurl.com/blindcodersurvey Finally, The Holman Prize: https://holman.lighthouse-sf.org/ best regards Jonathan From mirkok.lists at googlemail.com Mon May 10 18:23:48 2021 From: mirkok.lists at googlemail.com (Mirko) Date: Tue, 11 May 2021 00:23:48 +0200 Subject: OT: Autism in discussion groups In-Reply-To: References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> <205d65ad-f712-4647-9f8b-ab1e0731586bn@googlegroups.com> <60970288.1070209@googlemail.com> Message-ID: <6099B274.10302@googlemail.com> Am 09.05.2021 um 02:34 schrieb Michael Torrie: > On 5/8/21 3:28 PM, Mirko via Python-list wrote: >> >> I apologize for this OT post, especially because it's in reply to an >> at least partly troll post, but I just can't resist. Sorry. >> >> P.S.: *NOT* among the core symptoms of (the high-functioning levels) >> of ASS is the inability to learn. Mind that! (And that includes >> social norms.) > > Thank you for posting such an insightful comment. No need to apologize. > I really appreciate it. I think you are exactly correct. > Thanks! :-) In case anybody wonders: When I was talking about ASS, I was referring to "Autismus-Spektrum-St?rung". That's German for "Autism Spectrum Disorder" or short ASD. Happens when it's lake evening, you have some beers down and talk about a topic in a foreign language. :) From mirkok.lists at googlemail.com Mon May 10 18:16:00 2021 From: mirkok.lists at googlemail.com (Mirko) Date: Tue, 11 May 2021 00:16:00 +0200 Subject: The importance of mental health In-Reply-To: References: Message-ID: <6099B0A0.7050800@googlemail.com> Am 10.05.2021 um 15:16 schrieb Kyle Stanley: > Hey all, > > In these last few months, I have been in the process of healing from some > pretty heavy past trauma. And now that I am on the road to recovery, I want > to share my journey with the Python community in hopes that it may reach > those that are struggling with their own mental health battles, as many of > us are during these dark and difficult times. > > Trigger warning that it includes a decent amount of highly personal > content, so only check it out if you are okay with that: > https://discuss.python.org/t/break-from-open-source/6372/7?u=aeros. > > To anyone that would limit my employment opportunities as a result of > having had these struggles, *that's perfectly okay*. I kept the post in the > private section because I was originally in fear of discriminate. However, > I have reached an important conclusion: *I would not want to work for your > company if you discriminate against people who have overcome past struggles* > . > Thank you for your courage! This is what we need. True, genuine and honest stories from people with mental health issues. To demystify and destigmatize the entire topic. Everybody happily runs to the doctors to get antibiotics/antivirals for their simple cold and everybody literally "loves* to complain about how bad they feel when having a cold. But even today in the year 2021, very few people dare to go public with their "mental cold" or their "mental cancer". The danger of mockery or discrimination is still far to high. All the best, Kyle and good luck! :-) From bluebox03 at gmail.com Wed May 12 08:29:26 2021 From: bluebox03 at gmail.com (tommy yama) Date: Wed, 12 May 2021 21:29:26 +0900 Subject: The importance of mental health In-Reply-To: <6099B0A0.7050800@googlemail.com> References: <6099B0A0.7050800@googlemail.com> Message-ID: I do not know you and your past but guess destigmatization of mental illnesses is an important agenda to people, On Tue, May 11, 2021 at 8:34 AM Mirko via Python-list < python-list at python.org> wrote: > Am 10.05.2021 um 15:16 schrieb Kyle Stanley: > > Hey all, > > > > In these last few months, I have been in the process of healing from some > > pretty heavy past trauma. And now that I am on the road to recovery, I > want > > to share my journey with the Python community in hopes that it may reach > > those that are struggling with their own mental health battles, as many > of > > us are during these dark and difficult times. > > > > Trigger warning that it includes a decent amount of highly personal > > content, so only check it out if you are okay with that: > > https://discuss.python.org/t/break-from-open-source/6372/7?u=aeros. > > > > To anyone that would limit my employment opportunities as a result of > > having had these struggles, *that's perfectly okay*. I kept the post in > the > > private section because I was originally in fear of discriminate. > However, > > I have reached an important conclusion: *I would not want to work for > your > > company if you discriminate against people who have overcome past > struggles* > > . > > > > > Thank you for your courage! This is what we need. True, genuine and > honest stories from people with mental health issues. To demystify > and destigmatize the entire topic. Everybody happily runs to the > doctors to get antibiotics/antivirals for their simple cold and > everybody literally "loves* to complain about how bad they feel when > having a cold. But even today in the year 2021, very few people dare > to go public with their "mental cold" or their "mental cancer". The > danger of mockery or discrimination is still far to high. > > > All the best, Kyle and good luck! :-) > -- > https://mail.python.org/mailman/listinfo/python-list > From mstemper at gmail.com Wed May 12 10:48:55 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Wed, 12 May 2021 09:48:55 -0500 Subject: Python script accessing own source code In-Reply-To: References: Message-ID: On 12/05/2021 08.26, Dino wrote: > Hi, here's my (probably unusual) problem. Can a Python (3.7+) script > access its own source code? Here is a fairly simple python program that reads itself: ================================================ #!/usr/bin/python import sys with open( sys.argv[0], "rt" ) as myself: for line in myself: junk = sys.stdout.write( "%s" % (line) ) sys.exit(0) ================================================ It's not bullet-proof. If you put it in a directory in your $PATH and run it from somewhere else, it won't work. -- Michael F. Stemper I feel more like I do now than I did when I came in. From python at mrabarnett.plus.com Wed May 12 12:49:15 2021 From: python at mrabarnett.plus.com (MRAB) Date: Wed, 12 May 2021 17:49:15 +0100 Subject: Python script accessing own source code In-Reply-To: References: Message-ID: On 2021-05-12 15:48, Michael F. Stemper wrote: > On 12/05/2021 08.26, Dino wrote: > >> Hi, here's my (probably unusual) problem. Can a Python (3.7+) script >> access its own source code? > > Here is a fairly simple python program that reads itself: > > ================================================ > #!/usr/bin/python > > import sys > > with open( sys.argv[0], "rt" ) as myself: > for line in myself: > junk = sys.stdout.write( "%s" % (line) ) > > sys.exit(0) > ================================================ > > It's not bullet-proof. If you put it in a directory in your $PATH and > run it from somewhere else, it won't work. > How about this: with open(__file__) as myself: print(myself.read(), end='') From stestagg at gmail.com Wed May 12 13:35:16 2021 From: stestagg at gmail.com (Stestagg) Date: Wed, 12 May 2021 18:35:16 +0100 Subject: Python script accessing own source code In-Reply-To: References: Message-ID: On 2021-05-12 15:48, Michael F. Stemper wrote: > > On 12/05/2021 08.26, Dino wrote: > > > >> Hi, here's my (probably unusual) problem. Can a Python (3.7+) script > >> access its own source code? > > > > Here is a fairly simple python program that reads itself: > > > > ================================================ > > #!/usr/bin/python > > > > import sys > > > > with open( sys.argv[0], "rt" ) as myself: > > for line in myself: > > junk = sys.stdout.write( "%s" % (line) ) > > > > sys.exit(0) > > ================================================ > > > > It's not bullet-proof. If you put it in a directory in your $PATH and > > run it from somewhere else, it won't work. > > > > Here's a fairly simple option: ========== import inspect import sys print(inspect.getsource(sys.modules[__name__])) ======== From robin at reportlab.com Wed May 12 14:41:19 2021 From: robin at reportlab.com (Robin Becker) Date: Wed, 12 May 2021 19:41:19 +0100 Subject: Python script accessing own source code In-Reply-To: References: Message-ID: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> ....... > > with open(__file__) as myself: > ??? print(myself.read(), end='') very nice, but accessing code that's already seems quite easy. I think the real problem is to get a python script name that creates and writes itself. So I would ask if any one has the solution to the self writing script python find-tomorrows-lotto-numbers.py since GvR has been shown to have time traveling abilities such a script could paradoxically appear acausally. -- yrs-not-too-seriously Robin Becker From robin at reportlab.com Wed May 12 14:41:19 2021 From: robin at reportlab.com (Robin Becker) Date: Wed, 12 May 2021 19:41:19 +0100 Subject: Python script accessing own source code In-Reply-To: References: Message-ID: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> ....... > > with open(__file__) as myself: > ??? print(myself.read(), end='') very nice, but accessing code that's already seems quite easy. I think the real problem is to get a python script name that creates and writes itself. So I would ask if any one has the solution to the self writing script python find-tomorrows-lotto-numbers.py since GvR has been shown to have time traveling abilities such a script could paradoxically appear acausally. -- yrs-not-too-seriously Robin Becker From mirkok.lists at googlemail.com Wed May 12 15:17:04 2021 From: mirkok.lists at googlemail.com (Mirko) Date: Wed, 12 May 2021 21:17:04 +0200 Subject: Python script accessing own source code In-Reply-To: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> References: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> Message-ID: <609C29B0.6020800@googlemail.com> Am 12.05.2021 um 20:41 schrieb Robin Becker: > ....... >> >> with open(__file__) as myself: >> print(myself.read(), end='') > > very nice, but accessing code that's already seems quite easy. I > think the real problem is to get a python script name that creates > and writes itself. So I would ask if any one has the solution to the > self writing script > > python find-tomorrows-lotto-numbers.py > > since GvR has been shown to have time traveling abilities such a > script could paradoxically appear acausally. > -- > yrs-not-too-seriously > Robin Becker Not sure, if that's what you mean, but writing a self-replicating script is easy too: import os import sys with open(os.path.abspath(__file__)) as myself: with open(sys.argv[1], "w") as yourself: yourself.write(myself.read()) Give it a filename as a command-line argument and it will write itself to that file. From robin at reportlab.com Thu May 13 03:25:41 2021 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 May 2021 08:25:41 +0100 Subject: Python script accessing own source code In-Reply-To: <609C29B0.6020800@googlemail.com> References: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> <609C29B0.6020800@googlemail.com> Message-ID: On 12/05/2021 20:17, Mirko via Python-list wrote: > Am 12.05.2021 um 20:41 schrieb Robin Becker: >> ....... >>> >........... >> since GvR has been shown to have time traveling abilities such a >> script could paradoxically appear acausally. >> -- >> yrs-not-too-seriously >> Robin Becker > > > Not sure, if that's what you mean, but writing a self-replicating > script is easy too: actually I was really joking about self creating scripts that do something useful like finding future lotto numbers. the artificial programmer servant is some way off > > import os > import sys > > with open(os.path.abspath(__file__)) as myself: > with open(sys.argv[1], "w") as yourself: > yourself.write(myself.read()) > > > Give it a filename as a command-line argument and it will write > itself to that file. > -- Robin Becker From rosuav at gmail.com Thu May 13 03:29:57 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 13 May 2021 17:29:57 +1000 Subject: Python script accessing own source code In-Reply-To: References: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> <609C29B0.6020800@googlemail.com> Message-ID: On Thu, May 13, 2021 at 5:27 PM Robin Becker wrote: > > On 12/05/2021 20:17, Mirko via Python-list wrote: > > Am 12.05.2021 um 20:41 schrieb Robin Becker: > >> ....... > >>> > >........... > >> since GvR has been shown to have time traveling abilities such a > >> script could paradoxically appear acausally. > >> -- > >> yrs-not-too-seriously > >> Robin Becker > > > > > > Not sure, if that's what you mean, but writing a self-replicating > > script is easy too: > > actually I was really joking about self creating scripts that do something useful like finding future lotto numbers. > > the artificial programmer servant is some way off > Perhaps not so far off as you might think. With import hooks, it's entirely possible to have a program that creates itself on demand - for instance, you might transpile your script from some variant form of the language (maybe you're trying out a proposed new syntax). It won't help you with the lotto, but it certainly is an AI assistant for a programmer that creates runnable code when called upon. ChrisA From robin at reportlab.com Thu May 13 03:25:41 2021 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 May 2021 08:25:41 +0100 Subject: Python script accessing own source code In-Reply-To: <609C29B0.6020800@googlemail.com> References: <5ee47805-3e06-5f57-d829-d1c35420c999@everest.reportlab.co.uk> <609C29B0.6020800@googlemail.com> Message-ID: On 12/05/2021 20:17, Mirko via Python-list wrote: > Am 12.05.2021 um 20:41 schrieb Robin Becker: >> ....... >>> >........... >> since GvR has been shown to have time traveling abilities such a >> script could paradoxically appear acausally. >> -- >> yrs-not-too-seriously >> Robin Becker > > > Not sure, if that's what you mean, but writing a self-replicating > script is easy too: actually I was really joking about self creating scripts that do something useful like finding future lotto numbers. the artificial programmer servant is some way off > > import os > import sys > > with open(os.path.abspath(__file__)) as myself: > with open(sys.argv[1], "w") as yourself: > yourself.write(myself.read()) > > > Give it a filename as a command-line argument and it will write > itself to that file. > -- Robin Becker From sumukh477 at gmail.com Thu May 13 09:49:46 2021 From: sumukh477 at gmail.com (Sumukh chakkirala) Date: Thu, 13 May 2021 19:19:46 +0530 Subject: STARTUP FAILURE Message-ID: Hello, I have been facing this " startup failure" for a while now, I can open the IDLE from the programs that I have saved but I'm not able to open the IDLE directly. Hope you can help me with this issue as soon as possible. From mats at wichmann.us Thu May 13 14:30:47 2021 From: mats at wichmann.us (Mats Wichmann) Date: Thu, 13 May 2021 12:30:47 -0600 Subject: STARTUP FAILURE In-Reply-To: References: Message-ID: <4f70a314-7dd1-41bf-0a59-7239182e7808@wichmann.us> On 5/13/21 7:49 AM, Sumukh chakkirala wrote: > Hello, I have been facing this " startup failure" for a while now, I can > open the IDLE from the programs that I have saved but I'm not able to open > the IDLE directly. Hope you can help me with this issue as soon as possible. > if it's the standard "IDLE's subprocess didn't make the connection" message, did you read the page pointed to by the link in the dialog box? if it's not that, please provide some more details of your problem. From nospam at please.ty Thu May 13 13:44:02 2021 From: nospam at please.ty (jak) Date: Thu, 13 May 2021 19:44:02 +0200 Subject: STARTUP FAILURE References: Message-ID: Il 13/05/2021 15:49, Sumukh chakkirala ha scritto: > Hello, I have been facing this " startup failure" for a while now, I can > open the IDLE from the programs that I have saved but I'm not able to open > the IDLE directly. Hope you can help me with this issue as soon as possible. > for Windows cmd: C:\Python\pythonw.exe "C:\Python\Lib\idlelib\idle.pyw From alan.gauld at yahoo.co.uk Thu May 13 13:48:20 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Thu, 13 May 2021 18:48:20 +0100 Subject: STARTUP FAILURE In-Reply-To: References: Message-ID: On 13/05/2021 14:49, Sumukh chakkirala wrote: > Hello, I have been facing this " startup failure" for a while now, I can > open the IDLE from the programs that I have saved but I'm not able to open > the IDLE directly. Hope you can help me with this issue as soon as possible. > Usual questions: Which OS? Which python version? How exactly are you trying to open IDLE? And what happens? Any errors? How are you opening it "from the programs that I have saved" What exactly does that meaN? Right click in a File explorer program maybe? Have you tried other ways, such as from the command line? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From david at kolovratnik.net Fri May 14 02:28:48 2021 From: david at kolovratnik.net (David =?iso-8859-1?Q?Kolovratn=EDk?=) Date: Fri, 14 May 2021 08:28:48 +0200 Subject: typing instance variable Message-ID: <20210514062848.GE14929@crfreenet.org> Greetings, This snippet of code raises ValueError during execution: class MyClass: __slots__ = 'foo' foo: int = 0 mypy does not complain: mypy myclass.py Success: no issues found in 1 source file But python3 does: python3 myclass.py Traceback (most recent call last): File "myclass.py", line 1, in class MyClass: ValueError: 'foo' in __slots__ conflicts with class variable This is where the way of type declaration of instance variable comes from: https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html class MyClass: # You can optionally declare instance variables in the class body attr: int # This is an instance variable with a default value charge_percent: int = 100 Why Python believes foo is class variable? python3 -V Python 3.6.8 Kind regards, David From payalsingh200404 at gmail.com Fri May 14 04:55:24 2021 From: payalsingh200404 at gmail.com (Payal Singh) Date: Fri, 14 May 2021 14:25:24 +0530 Subject: Hello! I was here to ask about pythonm actually I deleted the python 8 version and downloaded a new python 9 version but after deleting when I code something and after some days I want to open the file again with python it's not opening. I will always shows repair modify and uninstall coloumn what to do? Message-ID: From mats at wichmann.us Fri May 14 16:24:49 2021 From: mats at wichmann.us (Mats Wichmann) Date: Fri, 14 May 2021 14:24:49 -0600 Subject: Hello! I was here to ask about pythonm actually I deleted the python 8 version and downloaded a new python 9 version but after deleting when I code something and after some days I want to open the file again with python it's not opening. I will always shows repair modify and uninstall coloumn what to do? In-Reply-To: References: Message-ID: <49953bc5-a393-8e55-cd05-c11118ef1e2f@wichmann.us> On 5/14/21 2:55 AM, Payal Singh wrote: > it's easier if you put that in the message body, not the subject line. if you're getting the repair/modify/uninstall dialog, it means you're running the installer again (that's its job, if already installed, to somehow modify the installation). Don't do that - the installer isn't the Python interpreter Go find the actual Python executable instead. You can navigate to it through the start menu, or you can invoke it from a command shell (if you installed the Python Launcher, which is recommended, do so by typing "py"). From payalsingh200404 at gmail.com Sat May 15 01:06:54 2021 From: payalsingh200404 at gmail.com (Payal Singh) Date: Sat, 15 May 2021 10:36:54 +0530 Subject: Hello! I was here to ask about pythonm actually I deleted the python 8 version and downloaded a new python 9 version but after deleting when I code something and after some days I want to open the file again with python it's not opening. I will always shows repair modify and uninstall coloumn what to do? In-Reply-To: <49953bc5-a393-8e55-cd05-c11118ef1e2f@wichmann.us> References: <49953bc5-a393-8e55-cd05-c11118ef1e2f@wichmann.us> Message-ID: Thanks, I'll check it out. On Sat, May 15, 2021, 1:54 AM Mats Wichmann wrote: > On 5/14/21 2:55 AM, Payal Singh wrote: > > > > it's easier if you put that in the message body, not the subject line. > > if you're getting the repair/modify/uninstall dialog, it means you're > running the installer again (that's its job, if already installed, to > somehow modify the installation). Don't do that - the installer isn't > the Python interpreter Go find the actual Python executable instead. > You can navigate to it through the start menu, or you can invoke it from > a command shell (if you installed the Python Launcher, which is > recommended, do so by typing "py"). > > > From codemouse92 at outlook.com Sat May 15 18:39:03 2021 From: codemouse92 at outlook.com (Jason C. McDonald) Date: Sat, 15 May 2021 22:39:03 -0000 (UTC) Subject: Standarize TOML? Message-ID: During the Steering Committee presentation at PyCon, it was mentioned that no one has formally proposed TOML be added to the standard library (emphasis on formal). THe joke went forth that there would be a flood of proposals to that end. So, just to kick this off while the thought is still fresh in a bunch of people's minds: **should we add a TOML parser to the standard library**? The main reason this matters is to help encourage adoption of the now PEP-standardized pyproject.toml. A few projects have cited the lack of a standardized TOML implementation in the standard library as a reason not to adopt pyproject.toml...and the topic thus became weirdly political. I understand that Brett Cannon intends to bring this up at the next language summit, but, ah, might as well put the community two-cents in now, hey? I, for one, feel like this is obvious. -- Jason C. McDonald (CodeMouse92) Author | Speaker | Hacker | Time Lord From jon+usenet at unequivocal.eu Sat May 15 19:23:37 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Sat, 15 May 2021 23:23:37 -0000 (UTC) Subject: Standarize TOML? References: Message-ID: On 2021-05-15, Jason C. McDonald wrote: > During the Steering Committee presentation at PyCon, it was mentioned > that no one has formally proposed TOML be added to the standard library > (emphasis on formal). THe joke went forth that there would be a flood > of proposals to that end. > > So, just to kick this off while the thought is still fresh in a bunch of > people's minds: **should we add a TOML parser to the standard library**? > > The main reason this matters is to help encourage adoption of the now > PEP-standardized pyproject.toml. A few projects have cited the lack of > a standardized TOML implementation in the standard library as a reason > not to adopt pyproject.toml...and the topic thus became weirdly > political. > > I understand that Brett Cannon intends to bring this up at the next > language summit, but, ah, might as well put the community two-cents in > now, hey? > > I, for one, feel like this is obvious. How about replacing pyproject.toml with pyproject.json, problem solved. It's fairly hilarious that PEP 518 even provides a JSON schema specifying the file format, but then doesn't use JSON and instead selects a file format that doesn't even have a built-in Python parser. From chololennon at hotmail.com Sun May 16 02:00:08 2021 From: chololennon at hotmail.com (Cholo Lennon) Date: Sun, 16 May 2021 03:00:08 -0300 Subject: Proposal: Disconnect comp.lang.python from python-list References: <3091d9bc11516df9e4bef0fcdfb3faf11ac9783a.camel@anode.ca> Message-ID: On 5/5/21 9:31 PM, Paul Bryan wrote: > Given the ease of spoofing sender addresses, and its propensity for use > in anonymous spamming and trolling (thanks python-list-owner for > staying on top of that!), I propose to disconnect comp.lang.python from > the python-list mailing list. Both would then operate independently. > > Paul > No way, I have been using comp.lang.python for years, my spam filter works ok btw. Regards -- Cholo Lennon Bs.As. ARG From mal at europython.eu Mon May 17 08:33:32 2021 From: mal at europython.eu (Marc-Andre Lemburg) Date: Mon, 17 May 2021 14:33:32 +0200 Subject: EuroPython 2021: Talk Voting is Open Message-ID: <3cddcb11-8130-6b3c-809f-d5f8ff0423e6@europython.eu> Talk voting is your chance to tell us what you?d like to see at EuroPython 2021. We will leave talk voting open until: Sunday, May 23, 23:59:59 CEST In order to vote, please log in to the website and navigate to the talk voting page: * EuroPython 2021 Talk Voting * https://ep2021.europython.eu/events/talk-voting/ Who can participate? -------------------- Any registered attendee of EuroPython 2021 with a paid ticket, as well as attendees of one of the past EuroPython conferences (going back to 2015) can vote. If you have submitted a proposal this year, you are also eligible to vote. If you have not attended EuroPython before, but want to participate in talk voting, you have to buy a ticket before you can vote: https://ep2021.europython.eu/registration/buy-tickets/ How talk voting works --------------------- The talk voting interface lists all submitted proposals, including talks, helpdesks and posters. You can then vote on the proposal you'd like to see at the event. Details on the voting process are described on our talk voting page. Talk Selection -------------- After the talk voting phase, the EuroPython Program Workgroup (WG) will use the votes to select the talks and build a schedule. The talk voting is a good and strong indicator of what attendees are interested to see. Submissions are also selected based on editorial criteria, for example, to increase diversity, give a chance to less mainstream topics and make sure that topics don't overlap too much. In general, the Program WG will try to give as many speakers a chance to talk as possible. If speakers have submitted multiple talks, the one with the highest rating will most likely get selected. Quick Summary ------------- EuroPython 2021 will be run online from July 26 - August 1: - Two workshop/training days (July 26 - 27) - Three conference days (July 28 - 30) - Two sprint days (July 31 - August 1) The sessions will be scheduled to ensure they are also accessible for those in the Asian and Americas time zones. Help spread the word -------------------- Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/europython-2021-talk-voting-is-open/ Tweet: https://twitter.com/europython/status/1394245129083424768 Enjoy, -- EuroPython 2021 Team https://ep2021.europython.eu/ https://www.europython-society.org/ From mennoholscher at gmail.com Mon May 17 05:10:44 2021 From: mennoholscher at gmail.com (Menno Holscher) Date: Mon, 17 May 2021 11:10:44 +0200 Subject: Standarize TOML? In-Reply-To: References: Message-ID: Op 16-05-2021 om 00:39 schreef Jason C. McDonald: > During the Steering Committee presentation at PyCon, it was mentioned > that no one has formally proposed TOML be added to the standard library > (emphasis on formal). THe joke went forth that there would be a flood > of proposals to that end. > > So, just to kick this off while the thought is still fresh in a bunch of > people's minds: **should we add a TOML parser to the standard library**? > See here: https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068 > I, for one, feel like this is obvious. > You are not the only one. The game is already on for some time. -- Met vriendelijke groet / Kind regards Menno H?lscher From barry at barrys-emacs.org Mon May 17 16:29:47 2021 From: barry at barrys-emacs.org (Barry Scott) Date: Mon, 17 May 2021 21:29:47 +0100 Subject: Standarize TOML? In-Reply-To: References: Message-ID: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> > On 15 May 2021, at 23:39, Jason C. McDonald wrote: > > During the Steering Committee presentation at PyCon, it was mentioned > that no one has formally proposed TOML be added to the standard library > (emphasis on formal). THe joke went forth that there would be a flood > of proposals to that end. > > So, just to kick this off while the thought is still fresh in a bunch of > people's minds: **should we add a TOML parser to the standard library**? > > The main reason this matters is to help encourage adoption of the now > PEP-standardized pyproject.toml. A few projects have cited the lack of > a standardized TOML implementation in the standard library as a reason > not to adopt pyproject.toml...and the topic thus became weirdly > political. > > I understand that Brett Cannon intends to bring this up at the next > language summit, but, ah, might as well put the community two-cents in > now, hey? > > I, for one, feel like this is obvious. I think the python ideas list is a better place to have this discussion. Barry > > -- > Jason C. McDonald (CodeMouse92) > Author | Speaker | Hacker | Time Lord > -- > https://mail.python.org/mailman/listinfo/python-list > From tjreedy at udel.edu Mon May 17 19:48:12 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 17 May 2021 19:48:12 -0400 Subject: Standarize TOML? In-Reply-To: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> References: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> Message-ID: On 5/17/2021 4:29 PM, Barry Scott wrote: > > >> On 15 May 2021, at 23:39, Jason C. McDonald wrote: >> >> During the Steering Committee presentation at PyCon, it was mentioned >> that no one has formally proposed TOML be added to the standard library >> (emphasis on formal). THe joke went forth that there would be a flood >> of proposals to that end. >> >> So, just to kick this off while the thought is still fresh in a bunch of >> people's minds: **should we add a TOML parser to the standard library**? >> >> The main reason this matters is to help encourage adoption of the now >> PEP-standardized pyproject.toml. A few projects have cited the lack of >> a standardized TOML implementation in the standard library as a reason >> not to adopt pyproject.toml...and the topic thus became weirdly >> political. >> >> I understand that Brett Cannon intends to bring this up at the next >> language summit, but, ah, might as well put the community two-cents in >> now, hey? >> >> I, for one, feel like this is obvious. > > I think the python ideas list is a better place to have this discussion. I disagree. Rehashing *opinions* is pretty useless. The issues were already discussed on https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068 There are multiple packages. There is no consensus on which to pick, *if any*. Existing modules apparently include writers, which are necessarily opinionated (as is formatting of C, Python, html, ...). As I just noted in the discussion, the stdlib does not have an html writer. So if we want just a parser, maybe we should generate one from the grammar. Then there are broader 'What should be in the stdlib discussions. If anyone has *new information* about toml, post it there. -- Terry Jan Reedy From pjfarley3 at earthlink.net Mon May 17 21:53:49 2021 From: pjfarley3 at earthlink.net (pjfarley3 at earthlink.net) Date: Mon, 17 May 2021 21:53:49 -0400 Subject: How to build stable 3.9 branch from fork and clone of cpython Message-ID: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> I am following the "Getting Started" section of the Python Developers Guide, but when I build the first version to verify everything builds, it builds branch 3.11. If I want to build and contribute to branch 3.9, how do I set that up please? OS is Windows 10. I have, I believe, all the necessary tools for the build, since the 3.11 version did build and in a very minimal test does execute successfully after the build (responds to "-V" option with build information). TIA for your assistance. Peter From rosuav at gmail.com Tue May 18 03:00:32 2021 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 18 May 2021 17:00:32 +1000 Subject: How to build stable 3.9 branch from fork and clone of cpython In-Reply-To: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> References: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> Message-ID: On Tue, May 18, 2021 at 4:33 PM wrote: > > I am following the "Getting Started" section of the Python Developers Guide, > but when I build the first version to verify everything builds, it builds > branch 3.11. > > > > If I want to build and contribute to branch 3.9, how do I set that up > please? > git checkout 3.9 That should switch you to the branch, replacing all the (tracked) files in the build directory with the corresponding files from 3.9. Be aware that most development is going to happen on the master branch (or the main branch, whichever one you have), and branches like 3.9 are going to get backported patches; so any change you're planning to contribute to 3.9 is going to need to work correctly on both branches. ChrisA From tjreedy at udel.edu Tue May 18 12:00:15 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 18 May 2021 12:00:15 -0400 Subject: How to build stable 3.9 branch from fork and clone of cpython In-Reply-To: References: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> Message-ID: On 5/18/2021 3:00 AM, Chris Angelico wrote: > On Tue, May 18, 2021 at 4:33 PM wrote: >> >> I am following the "Getting Started" section of the Python Developers Guide, >> but when I build the first version to verify everything builds, it builds >> branch 3.11. >> >> >> >> If I want to build and contribute to branch 3.9, how do I set that up >> please? >> > > git checkout 3.9 > > That should switch you to the branch, replacing all the (tracked) > files in the build directory with the corresponding files from 3.9. > > Be aware that most development is going to happen on the master branch > (or the main branch, whichever one you have), It should be 'main' for any python/??? repository. If one forked and cloned before the switch, one should rename 'master' to 'main' both locally and on the fork. Github has directions somewhere. It might provide them if one attempts a PR against 'master'. There may also be something in the devguide. The only time an initial contribution would be for 3.9 would be for a bug that only exists in 3.9, which is very rare. > and branches like 3.9 > are going to get backported patches; so any change you're planning to > contribute to 3.9 is going to need to work correctly on both branches. It must be 'main' for any python/??? repository. The only time an initial contribution would be for 3.9 would be for a bug that only exists in 3.9, which is very rare. -- Terry Jan Reedy From mstemper at gmail.com Tue May 18 09:13:04 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Tue, 18 May 2021 08:13:04 -0500 Subject: Writers [Was: Re: Standarize TOML?] In-Reply-To: References: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> Message-ID: On 17/05/2021 18.48, Terry Reedy wrote: > I disagree.? Rehashing *opinions* is pretty useless. The issues were > already discussed on > https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068 > > There are multiple packages.? There is no consensus on which to pick, > *if any*. Existing modules apparently include writers, which are > necessarily opinionated (as is formatting of C, Python, html, ...).? As > I just noted in the discussion, the stdlib does not have an html writer. If I'm parsing this correctly, python supports something called a "writer", which does not mean "somebody who writes python". Since I've never heard of this[1], I searched on: python writer but got stuff about how to write python and how to use python to write to files. Assuming that there is a python construct called a writer, could somebody point me to somewhere that I could read up on them? [1] Well, I've used csv.DictWriter() which might be an instance. -- Michael F. Stemper Galatians 3:28 From jon+usenet at unequivocal.eu Tue May 18 09:23:56 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Tue, 18 May 2021 13:23:56 -0000 (UTC) Subject: Writers [Was: Re: Standarize TOML?] References: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> Message-ID: On 2021-05-18, Michael F. Stemper wrote: > On 17/05/2021 18.48, Terry Reedy wrote: >> I disagree.? Rehashing *opinions* is pretty useless. The issues were >> already discussed on >> https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068 >> >> There are multiple packages.? There is no consensus on which to pick, >> *if any*. Existing modules apparently include writers, which are >> necessarily opinionated (as is formatting of C, Python, html, ...).? As >> I just noted in the discussion, the stdlib does not have an html writer. > > If I'm parsing this correctly, python supports something called a > "writer", which does not mean "somebody who writes python". You are not parsing it correctly. Terry means that at least some existing TOML modules for Python include facilities for outputting ("writing") TOML as well as reading it, and this makes choosing between those modules more controversial as there are more subjective opinions involved in the implementation of writing TOML as opposed to only reading it. From mstemper at gmail.com Tue May 18 09:54:29 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Tue, 18 May 2021 08:54:29 -0500 Subject: Writers [Was: Re: Standarize TOML?] In-Reply-To: References: <479A907F-AD40-465E-8043-B9FE587FBA8B@barrys-emacs.org> Message-ID: On 18/05/2021 08.23, Jon Ribbens wrote: > On 2021-05-18, Michael F. Stemper wrote: >> On 17/05/2021 18.48, Terry Reedy wrote: >>> There are multiple packages.? There is no consensus on which to pick, >>> *if any*. Existing modules apparently include writers, which are >>> necessarily opinionated (as is formatting of C, Python, html, ...).? As >>> I just noted in the discussion, the stdlib does not have an html writer. >> >> If I'm parsing this correctly, python supports something called a >> "writer", which does not mean "somebody who writes python". > > You are not parsing it correctly. Terry means that at least some > existing TOML modules for Python include facilities for outputting > ("writing") TOML as well as reading it, and this makes choosing > between those modules more controversial as there are more subjective > opinions involved in the implementation of writing TOML as opposed to > only reading it. Okay, thanks. -- Michael F. Stemper This post contains greater than 95% post-consumer bytes by weight. From encore1 at cox.net Tue May 18 16:35:20 2021 From: encore1 at cox.net (Dick Holmes) Date: Tue, 18 May 2021 13:35:20 -0700 Subject: Winpdb-reborn anomalies Message-ID: I'm attempting to run winpdb-reborn, version 2.0.0.1, under MinGW. My first problem is that if I enter winpdb in the directory containing , winpdb can't find rpdb2.py. I assume this is due to some path problem, but I don't know how to fix it. My second problem occurs when I run winpdb from the /c/Python39/Lib/site-packages directory. The program runs correctly as far as I can tell, but it writes about 20-30 lines of what looks like debug information to the rpdb2 console window. The ourput starts with a get_namespace() call. It does this after each debug action (step over, step into, etc.) I haven't been able to find any way to turn off this output. Any suggestions greatly appreciated! Dick From encore1 at cox.net Tue May 18 20:11:41 2021 From: encore1 at cox.net (Dick Holmes) Date: Tue, 18 May 2021 17:11:41 -0700 Subject: Winpdb-reborn anomalies - workaround References: Message-ID: In article , encore1 @cox.net says... > > I'm attempting to run winpdb-reborn, version 2.0.0.1, under MinGW. My > first problem is that if I enter winpdb in the directory > containing , winpdb can't find rpdb2.py. I assume this is due > to some path problem, but I don't know how to fix it. > > My second problem occurs when I run winpdb from the > /c/Python39/Lib/site-packages directory. The program runs correctly as > far as I can tell, but it writes about 20-30 lines of what looks like > debug information to the rpdb2 console window. The ourput starts with a > get_namespace() call. It does this > after each debug action (step over, step into, etc.) I haven't been able > to find any way to turn off this output. > > Any suggestions greatly appreciated! > > Dick I found the code that forces debug info to be printed. The tests against the debug flag were commented out so debug info was written unconditionally. In case someone needs it, the file is rpdb/utils.py; look for fDebug. This doesn't fix the path problem, but I can live with that. Dick From rosuav at gmail.com Wed May 19 02:58:34 2021 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 19 May 2021 16:58:34 +1000 Subject: How to build stable 3.9 branch from fork and clone of cpython In-Reply-To: <002301d74c60$4c615ea0$e5241be0$@earthlink.net> References: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> <002301d74c60$4c615ea0$e5241be0$@earthlink.net> Message-ID: On Wed, May 19, 2021 at 1:37 PM wrote: > > > -----Original Message----- > > From: Chris Angelico > > Sent: Tuesday, May 18, 2021 3:01 AM > > To: Python > > Subject: Re: How to build stable 3.9 branch from fork and clone of cpython > > > > On Tue, May 18, 2021 at 4:33 PM wrote: > > > > > > I am following the "Getting Started" section of the Python Developers > > > Guide, but when I build the first version to verify everything builds, > > > it builds branch 3.11. > > > > > > If I want to build and contribute to branch 3.9, how do I set that up > > > please? > > > > > > > git checkout 3.9 > > > > That should switch you to the branch, replacing all the (tracked) files in the build > > directory with the corresponding files from 3.9. > > > > Be aware that most development is going to happen on the master branch (or > > the main branch, whichever one you have), and branches like 3.9 are going to > > get backported patches; so any change you're planning to contribute to 3.9 is > > going to need to work correctly on both branches. > > > > ChrisA > > Thanks Chris, that did work. Thinking over what you said though, perhaps I should change it back. > > Would "git checkout main" reverse the branch 3.9 checkout? Yes, it would! > As you can probably tell, I am very new to git, so please pardon my ignorance. > Fortunately, git may be complex and immensely detailed, but it is also logical. Also, git works *very* hard to make sure that you don't lose anything, so it's usually safe to try things out (for instance, if that "git checkout" command would overwrite changes without being able to bring them back, it'll let you know). ChrisA From pjfarley3 at earthlink.net Tue May 18 23:37:30 2021 From: pjfarley3 at earthlink.net (pjfarley3 at earthlink.net) Date: Tue, 18 May 2021 23:37:30 -0400 Subject: How to build stable 3.9 branch from fork and clone of cpython In-Reply-To: References: <000201d74b88$a5f76b90$f1e642b0$@earthlink.net> Message-ID: <002301d74c60$4c615ea0$e5241be0$@earthlink.net> > -----Original Message----- > From: Chris Angelico > Sent: Tuesday, May 18, 2021 3:01 AM > To: Python > Subject: Re: How to build stable 3.9 branch from fork and clone of cpython > > On Tue, May 18, 2021 at 4:33 PM wrote: > > > > I am following the "Getting Started" section of the Python Developers > > Guide, but when I build the first version to verify everything builds, > > it builds branch 3.11. > > > > If I want to build and contribute to branch 3.9, how do I set that up > > please? > > > > git checkout 3.9 > > That should switch you to the branch, replacing all the (tracked) files in the build > directory with the corresponding files from 3.9. > > Be aware that most development is going to happen on the master branch (or > the main branch, whichever one you have), and branches like 3.9 are going to > get backported patches; so any change you're planning to contribute to 3.9 is > going to need to work correctly on both branches. > > ChrisA Thanks Chris, that did work. Thinking over what you said though, perhaps I should change it back. Would "git checkout main" reverse the branch 3.9 checkout? As you can probably tell, I am very new to git, so please pardon my ignorance. Peter From Richard at Damon-Family.org Thu May 20 00:00:40 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 20 May 2021 00:00:40 -0400 Subject: Unexpected Inheritance Problem Message-ID: Given the following definition of classes, I am getting an unexpected error of : TypeError:? __init__() missing 2 required keyword-only arguments: 'idcode' and 'tag' On the call to create a GedcomHead in the call to GedcomHead() in Gedcom0Tag.add() Code: class GedcomTag: ??? """Represents a Level of a Gedcom file""" ??? def __init__(self, parent: 'GedcomTag', level: int, tag: str, payload: Optional[str]): ??????? pass class Gedcom0Tag(GedcomTag): ??? """Represents a Level 0 Tag of a GEDCOM file""" ??? def __init__(self, *, parent, idcode: Optional[str], tag: str): ??????? super().__init__(parent=parent, level=0, tag=tag, payload=idcode) ??? @classmethod ??? def add(cls, *, parent, tag: str, payload: str, level=0): ??????? """Add Tag based on text""" ??????? if tag == 'HEAD': ??????????? data = GedcomHead(parent=parent) ??????? elif tag == 'TRLR': ??????????? data = GedcomTRLR(parent=parent) ??????? else: ??????????? data = Gedcom0Tag(idcode=tag, tag=payload, parent=parent) ??????? return data class GedcomHead(Gedcom0Tag): ??? """GEDCOM 0 HEAD tag""" ??? def ___init___(self, *, parent): ??????? super().__init__(parent=parent, idcode=None, tag="HEAD") Gedcom0Tag.add(parent, 'Head', '') Note: GedcomHead.__init__() doesn't have these parameters, somehow it seems be requiring the parameters for the __init__ call of the base class too, even though there is a call to it through the super().__init__() Is this expected? Can derived classes not provide values for parameters to construct the base classes? Is there something funny because I am making the call from a member of that base class? -- Richard Damon From rosuav at gmail.com Thu May 20 01:58:42 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 20 May 2021 15:58:42 +1000 Subject: Unexpected Inheritance Problem In-Reply-To: References: Message-ID: On Thu, May 20, 2021 at 2:02 PM Richard Damon wrote: > > Given the following definition of classes, I am getting an unexpected > error of : > > TypeError: __init__() missing 2 required keyword-only arguments: > 'idcode' and 'tag' > > On the call to create a GedcomHead in the call to GedcomHead() in > Gedcom0Tag.add() > > class Gedcom0Tag(GedcomTag): > """Represents a Level 0 Tag of a GEDCOM file""" > > @classmethod > def add(cls, *, parent, tag: str, payload: str, level=0): > > Gedcom0Tag.add(parent, 'Head', '') > You're defining that add takes keyword-only args (because the asterisk stops them from being passed positionally), but then you're calling it with nothing but positional args. Is that the code you're using? I would expect to see *three* missing kwonly args from this. ChrisA From __peter__ at web.de Thu May 20 03:24:34 2021 From: __peter__ at web.de (Peter Otten) Date: Thu, 20 May 2021 09:24:34 +0200 Subject: Unexpected Inheritance Problem In-Reply-To: References: Message-ID: On 20/05/2021 06:00, Richard Damon wrote: > class GedcomHead(Gedcom0Tag): > ??? """GEDCOM 0 HEAD tag""" > ??? def ___init___(self, *, parent): An __init__ with three underscores; you must me joking ;) From Richard at Damon-Family.org Thu May 20 06:54:35 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 20 May 2021 06:54:35 -0400 Subject: Unexpected Inheritance Problem In-Reply-To: References: Message-ID: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> On 5/20/21 3:24 AM, Peter Otten wrote: > On 20/05/2021 06:00, Richard Damon wrote: > >> class GedcomHead(Gedcom0Tag): >> ???? """GEDCOM 0 HEAD tag""" >> ???? def ___init___(self, *, parent): > > An __init__ with three underscores; you must me joking ;) > Yes, that is what I was missing, too many underscores there, so GedcomHead didn't have an __init__ so it inherited inherited from it from its base with the wrong signature. Thank you. -- Richard Damon From Richard at Damon-Family.org Thu May 20 06:58:32 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Thu, 20 May 2021 06:58:32 -0400 Subject: Unexpected Inheritance Problem In-Reply-To: References: Message-ID: <154582b5-ce3c-9d8a-e623-972d8d4e3428@Damon-Family.org> On 5/20/21 1:58 AM, Chris Angelico wrote: > On Thu, May 20, 2021 at 2:02 PM Richard Damon wrote: >> Given the following definition of classes, I am getting an unexpected >> error of : >> >> TypeError: __init__() missing 2 required keyword-only arguments: >> 'idcode' and 'tag' >> >> On the call to create a GedcomHead in the call to GedcomHead() in >> Gedcom0Tag.add() >> >> class Gedcom0Tag(GedcomTag): >> """Represents a Level 0 Tag of a GEDCOM file""" >> >> @classmethod >> def add(cls, *, parent, tag: str, payload: str, level=0): >> >> Gedcom0Tag.add(parent, 'Head', '') >> > You're defining that add takes keyword-only args (because the asterisk > stops them from being passed positionally), but then you're calling it > with nothing but positional args. Is that the code you're using? I > would expect to see *three* missing kwonly args from this. > > ChrisA The last line wasn't copied but distiled from the rest of the code to simplify the segment. The actual code had the parameters named in the call. Peter found the error with too many underscores on init. -- Richard Damon From mats at wichmann.us Thu May 20 11:14:10 2021 From: mats at wichmann.us (Mats Wichmann) Date: Thu, 20 May 2021 09:14:10 -0600 Subject: Unexpected Inheritance Problem In-Reply-To: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> References: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> Message-ID: <7d9f45b2-8f24-0282-0b9e-5af2ff0683fe@wichmann.us> On 5/20/21 4:54 AM, Richard Damon wrote: > On 5/20/21 3:24 AM, Peter Otten wrote: >> On 20/05/2021 06:00, Richard Damon wrote: >> >>> class GedcomHead(Gedcom0Tag): >>> ???? """GEDCOM 0 HEAD tag""" >>> ???? def ___init___(self, *, parent): >> >> An __init__ with three underscores; you must me joking ;) >> > Yes, that is what I was missing, too many underscores there, so > GedcomHead didn't have an __init__ so it inherited inherited from it > from its base with the wrong signature. > > Thank you. > many fonts squish together repeated underscores in the display so it's hard to see this visually, I've had a problem or two of this nature as well (a keyboard that got a little "bouncy" and more than once doubled keypresses). Even with an IDE - well, you can define whatever you want, so it's not an error that you "spelled it funny", right? From rtm443x at googlemail.com Thu May 20 07:06:08 2021 From: rtm443x at googlemail.com (jan) Date: Thu, 20 May 2021 12:06:08 +0100 Subject: Python install failing. Install log is available. Message-ID: Hi, I've usually had problems installing python, typically pip breaking. This time it's simply not installing correctly when run as administrator, and not at all when run as non-administrator. As administrator, it's not installing for other users as I believe it should. It's certainly not adding the python path correctly *for all users* (install option "add python to environment variables"), from a command console run as admin: C:\WINDOWS\system32>whoami antik\administrator C:\WINDOWS\system32>echo %PATH% C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\dotnet\;C:\Program Files\TortoiseGit\bin;C:\Users\Administrator\AppData\Local\Programs\Python\Python39\Scripts\;C:\Users\Administrator\AppData\Local\Programs\Python\Python39\;C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps;C:\Users\Administrator\.dotnet\tools It's there, but from a non-admin console (I work just a normal user): C:\Users\jan>whoami antik\jan C:\Users\jan>echo %path% C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\dotnet\;C:\Program Files\TortoiseGit\bin;C:\Users\jan\AppData\Local\Microsoft\WindowsApps;C:\Users\jan\AppData\Local\Programs\Git\cmd So no python path added. When install is run as non-administrator it seems to fail outright due to lack of privileges. The install log for this non-admin is available on request (I'd rather not attach it as it contain have sensitive info, but can post it publicly if really wanted. It's 60K). I tried elevating my non-admin account to admin then re-running the python installer, it broke. Trying to reinstall it has now lost all associations with the .py extension. I don't know what's going on. My build depends on python and obviously that's failing now. I've worked around it by downloading and unzipping python embedded, setting the file association and hardcoding file paths, but that's certainly not ideal. Any thoughts? Using python-3.9.5-amd64.exe, OS is win 2016 server eval, fresh install. From tjreedy at udel.edu Wed May 19 14:57:52 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 19 May 2021 14:57:52 -0400 Subject: If you have Python Cookbook, 3rd ed. Message-ID: can you verify that the Algorithm chapter (near end in 2nd ed.) does *NOT* have an introduction by Tim Peters? (Info needed to verify timeit doc correction https://github.com/python/cpython/pull/21744) -- Terry Jan Reedy From ethan at stoneleaf.us Thu May 20 12:59:10 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 20 May 2021 09:59:10 -0700 Subject: Typing and Enum and Abstract Message-ID: Here's a question on SO about typing, enum, and ABC: https://stackoverflow.com/q/67610562/208880 No answers so far. -- ~Ethan~ From robertvstepp at gmail.com Thu May 20 13:14:24 2021 From: robertvstepp at gmail.com (boB Stepp) Date: Thu, 20 May 2021 12:14:24 -0500 Subject: If you have Python Cookbook, 3rd ed. In-Reply-To: References: Message-ID: On Thu, May 20, 2021 at 11:43 AM Terry Reedy wrote: > > can you verify that the Algorithm chapter (near end in 2nd ed.) does > *NOT* have an introduction by Tim Peters? > (Info needed to verify timeit doc correction > https://github.com/python/cpython/pull/21744) In my 3rd edition copy chapter 1 is "Data Structures and Algorithms". The only thing comprising an introduction is a brief paragraph that starts the chapter and has no attribution. HTH, boB Stepp From grant.b.edwards at gmail.com Thu May 20 14:53:19 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Thu, 20 May 2021 18:53:19 -0000 (UTC) Subject: Unexpected Inheritance Problem References: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> <7d9f45b2-8f24-0282-0b9e-5af2ff0683fe@wichmann.us> Message-ID: On 2021-05-20, Mats Wichmann wrote: > On 5/20/21 4:54 AM, Richard Damon wrote: >> On 5/20/21 3:24 AM, Peter Otten wrote: >>> On 20/05/2021 06:00, Richard Damon wrote: >>> >>>> class GedcomHead(Gedcom0Tag): >>>> ???? """GEDCOM 0 HEAD tag""" >>>> ???? def ___init___(self, *, parent): >>> >>> An __init__ with three underscores; you must me joking ;) >>> >> Yes, that is what I was missing, too many underscores there, so >> GedcomHead didn't have an __init__ so it inherited inherited from it >> from its base with the wrong signature. > > many fonts squish together repeated underscores in the display so it's > hard to see this visually, Is it just me, or does it seem foolish to use such fonts for editing/browsing source code... -- Grant From contact.tarneo at gmail.com Thu May 20 13:08:39 2021 From: contact.tarneo at gmail.com (max pothier) Date: Thu, 20 May 2021 10:08:39 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python Message-ID: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> My school has a website for homework called pronote (no problem if you don't know it). After logging in on parisclassenumerique.fr (works with selenium but I cant get requests to work), I want to read one of the packets that is sent: All the info about my day, my homework, etc. are in there and it is the perfect file: header request response stack trace The file's download address looks random. The login works only for a limited period of time in the same browser. Any ideas for using that tool of Firefox or same of Chrome? Thanks! From rosuav at gmail.com Thu May 20 15:12:59 2021 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 21 May 2021 05:12:59 +1000 Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> Message-ID: On Fri, May 21, 2021 at 4:59 AM max pothier wrote: > > > > My school has a website for homework called pronote (no problem if you don't know it). After logging in on parisclassenumerique.fr (works with selenium but I cant get requests to work), I want to read one of the packets that is sent: All the info about my day, my homework, etc. are in there and it is the perfect file: header request response stack trace > > The file's download address looks random. The login works only for a limited period of time in the same browser. > > Any ideas for using that tool of Firefox or same of Chrome? > Most likely, what you're looking at is going to require some sort of login token, a cookie or equivalent. It's not going to be easy to replicate that in Python without actually providing your login credentials. I'd say the easiest approach is going to be a hybrid of Python to do your processing, with some JavaScript to collect the request information. But it all depends on how much you want to automate this, and how much effort you're willing to put in. For instance, you could write a Chrome extension that is aware of the traffic, or perhaps it'd be sufficient to just paste some JavaScript code into the Dev Tools console before you send the request. ChrisA From tjreedy at udel.edu Thu May 20 16:40:36 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 20 May 2021 16:40:36 -0400 Subject: Python install failing. Install log is available. In-Reply-To: References: Message-ID: On 5/20/2021 7:06 AM, jan via Python-list wrote: > This time it's simply not installing correctly when run as > administrator, and not at all when run as non-administrator. > > As administrator, it's not installing for other users as I believe it should. > > It's certainly not adding the python path correctly *for all users* > C:\WINDOWS\system32>whoami ... > Any thoughts? On Windows, use the py launcher to launch python. It was added as the solution to problems with adding python paths, including problems with multiple installs and those with removing them. -- Terry Jan Reedy From tjreedy at udel.edu Thu May 20 16:44:02 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 20 May 2021 16:44:02 -0400 Subject: If you have Python Cookbook, 3rd ed. In-Reply-To: References: Message-ID: On 5/20/2021 1:14 PM, boB Stepp wrote: > On Thu, May 20, 2021 at 11:43 AM Terry Reedy wrote: >> >> can you verify that the Algorithm chapter (near end in 2nd ed.) does >> *NOT* have an introduction by Tim Peters? >> (Info needed to verify timeit doc correction >> https://github.com/python/cpython/pull/21744) > > In my 3rd edition copy chapter 1 is "Data Structures and Algorithms". > The only thing comprising an introduction is a brief paragraph that > starts the chapter and has no attribution. Hmm. 2nd ed starts with 1. Text. The intro mentioned was for 18. Algorithms, starting with removing duplicates from a sequence. -- Terry Jan Reedy From robertvstepp at gmail.com Thu May 20 17:42:50 2021 From: robertvstepp at gmail.com (boB Stepp) Date: Thu, 20 May 2021 16:42:50 -0500 Subject: If you have Python Cookbook, 3rd ed. In-Reply-To: References: Message-ID: On Thu, May 20, 2021 at 3:48 PM Terry Reedy wrote: > > On 5/20/2021 1:14 PM, boB Stepp wrote: > > On Thu, May 20, 2021 at 11:43 AM Terry Reedy wrote: > >> > >> can you verify that the Algorithm chapter (near end in 2nd ed.) does > >> *NOT* have an introduction by Tim Peters? > >> (Info needed to verify timeit doc correction > >> https://github.com/python/cpython/pull/21744) > > > > In my 3rd edition copy chapter 1 is "Data Structures and Algorithms". > > The only thing comprising an introduction is a brief paragraph that > > starts the chapter and has no attribution. > > Hmm. 2nd ed starts with 1. Text. The intro mentioned was for 18. > Algorithms, starting with removing duplicates from a sequence. 3rd edition in chapter 1 starts with "1.1 Unpacking a Sequence into Separate Variables" Later in chapter is "1.10 Removing Duplicates from a Sequence while Maintaining Order". The preface does say the third edition is a major rewrite, so I suppose there will be significant differences from the 2nd edition which I don't own. boB Stepp From tjreedy at udel.edu Thu May 20 17:02:10 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 20 May 2021 17:02:10 -0400 Subject: Unexpected Inheritance Problem In-Reply-To: References: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> <7d9f45b2-8f24-0282-0b9e-5af2ff0683fe@wichmann.us> Message-ID: On 5/20/2021 2:53 PM, Grant Edwards wrote: > On 2021-05-20, Mats Wichmann wrote: >> On 5/20/21 4:54 AM, Richard Damon wrote: >>> On 5/20/21 3:24 AM, Peter Otten wrote: >>>> On 20/05/2021 06:00, Richard Damon wrote: >>>> >>>>> class GedcomHead(Gedcom0Tag): >>>>> ???? """GEDCOM 0 HEAD tag""" >>>>> ???? def ___init___(self, *, parent): >>>> >>>> An __init__ with three underscores; you must me joking ;) >>>> >>> Yes, that is what I was missing, too many underscores there, so >>> GedcomHead didn't have an __init__ so it inherited inherited from it >>> from its base with the wrong signature. >> >> many fonts squish together repeated underscores in the display so it's >> hard to see this visually, > > Is it just me, or does it seem foolish to use such fonts for > editing/browsing source code... Windows 10, at least, has Source Code Pro, and variations, in which __init__ has distinct _s with a small space in between (unlike the default font here in Thunderbird, or in Firefox). This is the only monospaced TrueType font available in the Windows console with this property. -- Terry Jan Reedy From rtm443x at googlemail.com Fri May 21 06:21:19 2021 From: rtm443x at googlemail.com (jan) Date: Fri, 21 May 2021 11:21:19 +0100 Subject: Python install failing. Install log is available. In-Reply-To: References: Message-ID: OK, but 1. should the installer work for administrator + all users or not? 2. if not, should the installer work for me (a non-admin) and install python correctly and successfully for my account if I run it in my account, not the admin? thanks jan On 20/05/2021, Terry Reedy wrote: > On 5/20/2021 7:06 AM, jan via Python-list wrote: > >> This time it's simply not installing correctly when run as >> administrator, and not at all when run as non-administrator. >> >> As administrator, it's not installing for other users as I believe it >> should. >> >> It's certainly not adding the python path correctly *for all users* > >> C:\WINDOWS\system32>whoami > ... >> Any thoughts? > > On Windows, use the py launcher to launch python. It was added as the > solution to problems with adding python paths, including problems with > multiple installs and those with removing them. > > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > From mats at wichmann.us Fri May 21 10:25:22 2021 From: mats at wichmann.us (Mats Wichmann) Date: Fri, 21 May 2021 08:25:22 -0600 Subject: Python install failing. Install log is available. In-Reply-To: References: Message-ID: <96a0f1c0-9669-e6f3-d403-bc22340278e3@wichmann.us> On 5/21/21 4:21 AM, jan via Python-list wrote: > OK, but > > 1. should the installer work for administrator + all users or not? > > 2. if not, should the installer work for me (a non-admin) and install > python correctly and successfully for my account if I run it in my > account, not the admin? It should, and for many, it does. An ordinary install, not "for all users", defaults to your own AppData\Local\Programs\Python - the pattern you see in your Administrator install. So you don't seem to have installed that one for all users. I don't think you want to do a user-install using the administrator account. If you tell it to add to PATH, I believe it adds to the user variables in this case, so other accounts won't see that. The Python launcher should help with this part of the problem, as Terry said, but only if other users are able to work with things installed in admin's account-local locations. An install for all users will drop it into someplace different - by default at the top of the drive, so e.g. C:\Python39. From torriem at gmail.com Fri May 21 10:48:44 2021 From: torriem at gmail.com (Michael Torrie) Date: Fri, 21 May 2021 08:48:44 -0600 Subject: Python install failing. Install log is available. In-Reply-To: <96a0f1c0-9669-e6f3-d403-bc22340278e3@wichmann.us> References: <96a0f1c0-9669-e6f3-d403-bc22340278e3@wichmann.us> Message-ID: <0a7d2713-c6fc-707b-a033-4a545b9e7569@gmail.com> On 5/21/21 8:25 AM, Mats Wichmann wrote: > An install for all users will drop it into someplace different - by > default at the top of the drive, so e.g. C:\Python39. I just did an install of 3.9 on Windows 10. There was an option to install the launcher for all users but no option for installing Python for all users if you go through with the default install options. When I chose to install the launcher for all users, it still installed Python in the my user local AppData... path. In order to select to install for all users, I had to choose custom options during the install. Then I could choose to install for all users, and it let me select a path which defaulted to C:\Program Files\Python39. As well I selected to place Python in the path, which it did. From grant.b.edwards at gmail.com Thu May 20 21:21:20 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Fri, 21 May 2021 01:21:20 -0000 (UTC) Subject: Unexpected Inheritance Problem References: <37a37ae4-a6ce-aa54-29f0-85ccf52a369a@Damon-Family.org> <7d9f45b2-8f24-0282-0b9e-5af2ff0683fe@wichmann.us> Message-ID: On 2021-05-20, Terry Reedy wrote: > On 5/20/2021 2:53 PM, Grant Edwards wrote: >> On 2021-05-20, Mats Wichmann wrote: >> >>> many fonts squish together repeated underscores in the display so it's >>> hard to see this visually, >> >> Is it just me, or does it seem foolish to use such fonts for >> editing/browsing source code... > > Windows [...] Ah, I think I see the underlying problem. ;) -- Grant From tjreedy at udel.edu Thu May 20 23:49:45 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 20 May 2021 23:49:45 -0400 Subject: Python at SpaceX Message-ID: https://stackoverflow.blog/tag/software-in-space/ has 4 links to interviews. 2 specifically mention Python. https://stackoverflow.blog/2021/05/11/testing-software-so-its-reliable-enough-for-space/ "Python ?is for backend test running, build orchestration, and all our web servers are python-based. It?s a lot of little scripts and a lot of big web services. " https://stackoverflow.blog/2021/05/11/building-a-space-based-isp/ "Starlink software, both in satellites and on the ground, is written almost exclusively in C++, with some prototyping development in Python." ?For development and test of these algorithms, we have a full-scale network simulation running in continuous integration on a high-performance computing cluster. This simulation is capable of running the C++ production code as well as running against prototype code written in Python,? -- Terry Jan Reedy From Bischoop at vimart.net Fri May 21 06:46:07 2021 From: Bischoop at vimart.net (Bischoop) Date: Fri, 21 May 2021 10:46:07 -0000 (UTC) Subject: If you have Python Cookbook, 3rd ed. References: Message-ID: On 2021-05-19, Terry Reedy wrote: > can you verify that the Algorithm chapter (near end in 2nd ed.) does > *NOT* have an introduction by Tim Peters? > (Info needed to verify timeit doc correction > https://github.com/python/cpython/pull/21744) Preface ...... xi 1.Data Structure adn Algorithms.........................................1 1.1 Unpacking a Sequence into Separate Variables 1 1.2 Unpacking Elements from Iterables of Arbitrary Lenght 3 1.2 Keeping the Last N items 5 1.3 Finding the Largest or Smallest N itemst 7 Third Edition. From contact.tarneo at gmail.com Fri May 21 06:46:50 2021 From: contact.tarneo at gmail.com (max pothier) Date: Fri, 21 May 2021 03:46:50 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> Message-ID: <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Hello, Thanks for you answer! Actually my goal is not to automatically get the file once I open the page, but more to periodically check the site and get a notification when there's new homework or, at the morning, know when an hour is cancelled, so I don't want to have to open the browser every time. I have pretty good javascript knowledge so if you could better explain that idea, it would be a great help. From __peter__ at web.de Fri May 21 14:00:23 2021 From: __peter__ at web.de (Peter Otten) Date: Fri, 21 May 2021 20:00:23 +0200 Subject: Instantiating abstract classes Message-ID: Usually an abstract class cannot be instantiated: >>> from abc import ABCMeta, abstractmethod >>> from fractions import Fraction >>> class A(Fraction, metaclass=ABCMeta): @abstractmethod def frobnicate(self): pass >>> A() Traceback (most recent call last): File "", line 1, in A() File "C:\Program Files\Python39-32\lib\fractions.py", line 93, in __new__ self = super(Fraction, cls).__new__(cls) TypeError: Can't instantiate abstract class A with abstract method frobnicate However, if I derive from a builtin class that mechanism doesn't work: >>> class A(int, metaclass=ABCMeta): @abstractmethod def frobnicate(self): pass >>> A() 0 Is this a bug, or an implementation accident, or the expected behavior? From rosuav at gmail.com Fri May 21 18:07:07 2021 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 22 May 2021 08:07:07 +1000 Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Message-ID: On Sat, May 22, 2021 at 3:55 AM max pothier wrote: > > Hello, > Thanks for you answer! > Actually my goal is not to automatically get the file once I open the page, but more to periodically check the site and get a notification when there's new homework or, at the morning, know when an hour is cancelled, so I don't want to have to open the browser every time. > I have pretty good javascript knowledge so if you could better explain that idea, it would be a great help. > Ahh, now I better understand your purpose. Hmm. First and by far the best option would be to see if there's any sort of (documented or undocumented) API. See if you can figure out how the requests are being done, and try to find a pre-request request that is hinting at the download address. (You might have to do some exploration here.) Secondly, it may be possible to do an occasional manual check, but then keep your login cookie alive by periodic queries by your automated script. No idea how well that would work. Third, your worst case might be to do most of the work in JavaScript, maybe as a Chrome extension, but then have it call a Python script (via an HTTP request, since that's how JavaScript in a browser can best notify anything) to do whatever extra work you need Python for. Not sure how well that would work. Unfortunately it depends a LOT on the homework server you're working with, so it's hard to be specific. On the plus side, though, you're going to learn all kinds of things along the way! Or maybe that's another downside, depending on how Daily WTF-worthy the site is.... ChrisA From tjreedy at udel.edu Fri May 21 17:59:42 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 21 May 2021 17:59:42 -0400 Subject: If you have Python Cookbook, 3rd ed. In-Reply-To: References: Message-ID: On 5/19/2021 2:57 PM, Terry Reedy wrote: > can you verify that the Algorithm chapter (near end in 2nd ed.) does > *NOT* have an introduction by Tim Peters? > (Info needed to verify timeit doc correction > https://github.com/python/cpython/pull/21744) Thank you to 2 respondents. I have gone ahead with the patch. -- Terry Jan Reedy From martinp.dipaola at gmail.com Sat May 22 15:53:04 2021 From: martinp.dipaola at gmail.com (Martin Di Paola) Date: Sat, 22 May 2021 19:53:04 +0000 Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Message-ID: <20210522195304.qlq4aot44bs2e5xa@gmail.com> Hello, I'm not 100% sure but I think that I understand what you are trying to do. I faced the same problem a few months ago. I wanted to know when a particular blog posted a new article. My plan was to query the blog every day running a python script, get the list of articles it has and comparing them with the list of the previous day. I used Selenium (https://selenium-python.readthedocs.io/) and on top of that I implemented a thin layer to manipulate the web page called "selectq" (https://github.com/SelectQuery/sQ) You could write a similar script. Using Selenium or selectq will open a web browser but given that it is fully automated, it should not be a problem (well, yes, it may run a little slow however). The good side is that both can inject javascript if you have to. Would this work for you or am I saying nonsense? Thanks! Martin. On Fri, May 21, 2021 at 03:46:50AM -0700, max pothier wrote: >Hello, >Thanks for you answer! >Actually my goal is not to automatically get the file once I open the page, but more to periodically check the site and get a notification when there's new homework or, at the morning, know when an hour is cancelled, so I don't want to have to open the browser every time. >I have pretty good javascript knowledge so if you could better explain that idea, it would be a great help. >-- >https://mail.python.org/mailman/listinfo/python-list From phd at phdru.name Sun May 23 10:50:18 2021 From: phd at phdru.name (Oleg Broytman) Date: Sun, 23 May 2021 16:50:18 +0200 Subject: mimedecode 3.1.0 Message-ID: <20210523145018.GA7200@phdru.name> mimedecode WHAT IS IT Mail users, especially in non-English countries, often find that mail messages arrived in different formats, with different content types, in different encodings and charsets. Usually this is good because it allows us to use appropriate format/encoding/whatever. Sometimes, though, some unification is desirable. For example, one may want to put mail messages into an archive, make HTML indices, run search indexer, etc. In such situations converting messages to text in one character set and skipping some binary attachments is much desirable. Here is the solution - mimedecode. This is a program to decode MIME messages. The program expects one input file (either on command line or on stdin) which is treated as an RFC822 message, and decodes to stdout or an output file. If the file is not an RFC822 message it is just copied to the output one-to-one. If the file is a simple RFC822 message it is decoded as one part. If it is a MIME message with multiple parts ("attachments") all parts are decoded. Decoding can be controlled by command-line options. Think about said mail archive; for example, its maintainer wants to put there only texts, convert PDF/Postscript to text, pass HTML and images decoding base64 to html but leaving images encoded, and ignore everything else. This is how it could be done: mimedecode -t application/pdf -t application/postscript -t text/plain -b text/html -B 'image/*' -i '*/*' Version 3.1.0 (2021-05-23) Convert mimedecode.docbook to reST. Generate html/man/text using Sphinx. Replaced outdated and insecure `mktemp` with `NamedTemporaryFile`. Python 3.8, 3.9. WHERE TO GET Home page: https://phdru.name/Software/Python/#mimedecode git clone https://github.com/phdru/mimedecode.git git clone https://git.phdru.name/mimedecode.git git clone git://git.phdru.name/mimedecode.git Requires: Python 2.7 or Python 3.4+, m_lib.defenc 1.0+. Tests require: tox, m_lib 3.1+. Recommends: configured mailcap database. Documentation: https://phdru.name/Software/Python/mimedecode.html (also included in the package in html, man and txt formats). AUTHOR Oleg Broytman COPYRIGHT Copyright (C) 2001-2021 PhiloSoft Design. LICENSE GPL Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From pjfarley3 at earthlink.net Sun May 23 12:20:03 2021 From: pjfarley3 at earthlink.net (pjfarley3 at earthlink.net) Date: Sun, 23 May 2021 12:20:03 -0400 Subject: Question for potential python development contributions on Windows Message-ID: <000001d74fef$7d0051f0$7700f5d0$@earthlink.net> I asked this question on python-dev last week but did not get an answer. If anyone here know the answer I would appreciate it. The Python Developers Guide specifically states to get VS2017 for developing or enhancing python on a Windows system. Is it still correct to specifically use VS2017 , or is VS2019 also acceptable? I ask this because I know that the *.vcxproj files and other build-environment files have changed format pretty dramatically over the many releases of VS. ?If a potential new contribution targeted for current and future python will require new build environment files, I wouldn?t want to have to ?down release? those files (or expect core dev?s to do it) at or after submission to the community for approval.? Much better to use the same setup as core dev?s use than to introduce up-level differences in the build environment. IOW, for new releases on Windows are core dev?s still using VS2017 and so potential contributors should also use that version, or has the core dev?s process for Windows releases been updated to use VS2019? Peter -- From curty at free.fr Sun May 23 04:35:04 2021 From: curty at free.fr (Curt) Date: 23 May 2021 08:35:04 GMT Subject: Use Chrome's / Firefox's dev-tools in python References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Message-ID: On 2021-05-21, max pothier wrote: > Hello, Thanks for you answer! Actually my goal is not to > automatically get the file once I open the page, but more to > periodically check the site and get a notification when there's new > homework or, at the morning, know when an hour is cancelled, so I > don't want to have to open the browser every time. I have pretty good > javascript knowledge so if you could better explain that idea, it > would be a great help. It seems there's a smartphone app that does what you want, so this wheel may already have been invented (in a manner of speaking). Maybe you are already aware of this and are looking for a way to improve your hacking skills, or perhaps you don't have a smartphone--unlikely!--or want your notifications on your computer rather than your phone, etc. https://www.parisclassenumerique.fr/lutece/jsp/site/Portal.jsp?page_id=9 Notifications Afin de rester inform? en temps r?el de tous les ?v?nements qui vous concernent (actualit?s, messages, blogs, espace documentaire?), il est n?cessaire d?activer sur votre mobile les notifications pour l?application (par d?faut, ? votre arriv?e sur l?application, toutes les notifications sont activ?es). From contact.tarneo at gmail.com Sun May 23 04:36:48 2021 From: contact.tarneo at gmail.com (max pothier) Date: Sun, 23 May 2021 01:36:48 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <20210522195304.qlq4aot44bs2e5xa@gmail.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Message-ID: <5a03d59e-dc6c-47b6-ac14-35e26c9c13d0n@googlegroups.com> Hi, Seems like that could be a method of doing things. Just one clarification: the website has unselectable text, looks like it's an image strangely generated, so if I can get the packet with it, it would be perfect. As I said (I think), logging in with Selenium was already possible, and I could get a screenshot of the page after logging in. If you got this working like a packet listener in browser capable of seeing packet data, I'd gladly accept the code. I've tried to do this for 3 years now (since I came into that school basically), looks like it's coming to an end! Thanks! From contact.tarneo at gmail.com Sun May 23 04:39:04 2021 From: contact.tarneo at gmail.com (max pothier) Date: Sun, 23 May 2021 01:39:04 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> Message-ID: <33b3c1b3-d715-4eb3-9e40-a797e595f75bn@googlegroups.com> @Curt: That is notifications for the ENT app, I want the notifications for the app named ProNote. ENT is for e-mails and Pronote for homework, quotes, etc. From curty at free.fr Sun May 23 05:33:40 2021 From: curty at free.fr (Curt) Date: 23 May 2021 09:33:40 GMT Subject: Use Chrome's / Firefox's dev-tools in python References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <33b3c1b3-d715-4eb3-9e40-a797e595f75bn@googlegroups.com> Message-ID: On 2021-05-23, max pothier wrote: > @Curt: That is notifications for the ENT app, I want the notifications > for the app named ProNote. ENT is for e-mails and Pronote for > homework, quotes, etc. https://doc.index-education.com/fr-fr/pn/2018/N/Notification.htm Notifications dans PRONOTE ? Param?trer les notifications Vous ?tes notifi? lorsque vous recevez un message, une information, un sondage ou un document. 1. Rendez-vous dans le menu Mes pr?f?rences > communication > Messagerie. 2. Cochez le ou les modes de notification souhait?s. ... Notification via l'application (parents / ?l?ves / professeurs) D?s la rentr?e, un syst?me de notifications sur mobile permettra aux parents, ?l?ves et professeurs d'avoir une notification sur leur t?l?phone ? l'arriv?e d'un nouveau message ou d'une nouvelle information. From contact.tarneo at gmail.com Sun May 23 08:46:52 2021 From: contact.tarneo at gmail.com (max pothier) Date: Sun, 23 May 2021 05:46:52 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <33b3c1b3-d715-4eb3-9e40-a797e595f75bn@googlegroups.com> Message-ID: <4b3efab2-21a7-4f5e-ab27-10d742f00721n@googlegroups.com> Already tried this, only works for messages and not for homework etc. From curty at free.fr Sun May 23 10:45:21 2021 From: curty at free.fr (Curt) Date: 23 May 2021 14:45:21 GMT Subject: Use Chrome's / Firefox's dev-tools in python References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <33b3c1b3-d715-4eb3-9e40-a797e595f75bn@googlegroups.com> <4b3efab2-21a7-4f5e-ab27-10d742f00721n@googlegroups.com> Message-ID: On 2021-05-23, max pothier wrote: > Already tried this, only works for messages and not for homework etc. https://play.google.com/store/apps/details?id=com.androz2091.pronote_notifications&gl=FR Notifications pour Pronote vous permet de recevoir des notifications push lorsqu'une nouvelle note ou un nouveau *devoir* est ajout? sur Pronote ! Soyez inform?s en direct et ?vitez de vous connecter 50 fois par semaine pour voir si le prof d'histoire g?o a enfin mis les notes du contr?le ? Et voil? l'appli qui fait tout ! From pradeepsy3 at gmail.com Sun May 23 00:45:44 2021 From: pradeepsy3 at gmail.com (pradeep Y) Date: Sun, 23 May 2021 10:15:44 +0530 Subject: Issue in software Message-ID: I I couldn't get the solution for this issue since last week will you please help me to solve this issue the issue is when I opened command prompt this below message will Pop up "The program can't start because api-ms-win-crt-runtime-[1-1-0.dl] is missing from your computer.try reinstalling the program to fix this problem." I tried to solve several times and many times but I didn't get any expected outcome. Can you please help me please. From hw at adminart.net Sun May 23 00:37:07 2021 From: hw at adminart.net (hw) Date: Sun, 23 May 2021 06:37:07 +0200 Subject: learning python ... Message-ID: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> Hi, I'm starting to learn python and have made a little example program following a tutorial[1] I'm attaching. Running it, I'm getting: Traceback (most recent call last): File "[...]/hworld.py", line 18, in print(isinstance(int, float)) TypeError: isinstance() arg 2 must be a type or tuple of types I would understand to get an error message in line 5 but not in 18. Is this a bug or a feature? [1]: https://www.learnpython.org/en/Variables_and_Types From ikorot01 at gmail.com Sun May 23 13:05:11 2021 From: ikorot01 at gmail.com (Igor Korot) Date: Sun, 23 May 2021 12:05:11 -0500 Subject: Issue in software In-Reply-To: References: Message-ID: Hi, On Sun, May 23, 2021 at 11:50 AM pradeep Y wrote: > > I I couldn't get the solution for this issue since last week will you > please help me to solve this issue the issue is when I opened command > prompt this below message will Pop up > > > "The program can't start because api-ms-win-crt-runtime-[1-1-0.dl] is > missing from your computer.try reinstalling the program to fix this > problem." You should download the above mentioned DLL from MS website and install it. Thank you. > > > > I tried to solve several times and many times but I didn't get any expected > outcome. Can you please help me please. > -- > https://mail.python.org/mailman/listinfo/python-list From __peter__ at web.de Sun May 23 13:28:24 2021 From: __peter__ at web.de (Peter Otten) Date: Sun, 23 May 2021 19:28:24 +0200 Subject: learning python ... In-Reply-To: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> Message-ID: On 23/05/2021 06:37, hw wrote: > > Hi, > > I'm starting to learn python and have made a little example program > following a tutorial[1] I'm attaching. > > Running it, I'm getting: > > > Traceback (most recent call last): > ? File "[...]/hworld.py", line 18, in > ??? print(isinstance(int, float)) > TypeError: isinstance() arg 2 must be a type or tuple of types > > > I would understand to get an error message in line 5 but not in 18.? Is > this a bug or a feature? It is a bug in your code (which you don't provide). Did you assign some value to float, e. g.: >>> float = 42.0 >>> isinstance(int, float) Traceback (most recent call last): File "", line 1, in isinstance(int, float) TypeError: isinstance() arg 2 must be a type or tuple of types If you do not shadow the built-in you should get >>> isinstance(int, float) False From hw at adminart.net Sun May 23 15:34:29 2021 From: hw at adminart.net (hw) Date: Sun, 23 May 2021 21:34:29 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> Message-ID: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> On 5/23/21 7:28 PM, Peter Otten wrote: > On 23/05/2021 06:37, hw wrote: >> >> Hi, >> >> I'm starting to learn python and have made a little example program >> following a tutorial[1] I'm attaching. >> >> Running it, I'm getting: >> >> >> Traceback (most recent call last): >> ?? File "[...]/hworld.py", line 18, in >> ???? print(isinstance(int, float)) >> TypeError: isinstance() arg 2 must be a type or tuple of types >> >> >> I would understand to get an error message in line 5 but not in 18. >> Is this a bug or a feature? > > It is a bug in your code (which you don't provide). Did you assign some > value to float, e. g.: > > >>> float = 42.0 > >>> isinstance(int, float) > Traceback (most recent call last): > ? File "", line 1, in > ??? isinstance(int, float) > TypeError: isinstance() arg 2 must be a type or tuple of types > > If you do not shadow the built-in you should get > > >>> isinstance(int, float) > False > Apparently the attachment was stripped from my message. I'll put a smaller version directly into this message instead of an attachment: #!/usr/bin/python print("world!") int = 17 print("world", int) float = 6.670 print("world", float) foo = 0 print(type(int)) print(type(float)) print(type(foo)) print(isinstance(foo, str)) print(isinstance(int, float)) print(isinstance(float, float)) I don't know about shadowing. If I have defeated a whole variable type by naming a variable like a variable type, I would think it is a bad idea for python to allow this without warning. It seems like a recipie for creating chaos. From python at mrabarnett.plus.com Sun May 23 15:58:58 2021 From: python at mrabarnett.plus.com (MRAB) Date: Sun, 23 May 2021 20:58:58 +0100 Subject: learning python ... In-Reply-To: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: <5627423f-267d-9c01-3d61-5c67f5d192d2@mrabarnett.plus.com> On 2021-05-23 20:34, hw wrote: > On 5/23/21 7:28 PM, Peter Otten wrote: >> On 23/05/2021 06:37, hw wrote: >>> >>> Hi, >>> >>> I'm starting to learn python and have made a little example program >>> following a tutorial[1] I'm attaching. >>> >>> Running it, I'm getting: >>> >>> >>> Traceback (most recent call last): >>> ?? File "[...]/hworld.py", line 18, in >>> ???? print(isinstance(int, float)) >>> TypeError: isinstance() arg 2 must be a type or tuple of types >>> >>> >>> I would understand to get an error message in line 5 but not in 18. >>> Is this a bug or a feature? >> >> It is a bug in your code (which you don't provide). Did you assign some >> value to float, e. g.: >> >> >>> float = 42.0 >> >>> isinstance(int, float) >> Traceback (most recent call last): >> ? File "", line 1, in >> ??? isinstance(int, float) >> TypeError: isinstance() arg 2 must be a type or tuple of types >> >> If you do not shadow the built-in you should get >> >> >>> isinstance(int, float) >> False >> > > Apparently the attachment was stripped from my message. I'll put a > smaller version directly into this message instead of an attachment: > > > #!/usr/bin/python > > print("world!") > > int = 17 > print("world", int) > > float = 6.670 > print("world", float) > > foo = 0 > print(type(int)) > print(type(float)) > print(type(foo)) > > print(isinstance(foo, str)) > print(isinstance(int, float)) > print(isinstance(float, float)) > > > I don't know about shadowing. If I have defeated a whole variable type > by naming a variable like a variable type, I would think it is a bad > idea for python to allow this without warning. It seems like a recipie > for creating chaos. > The example you're following calls the variables "myfloat", etc, not "float", etc, so, yes, you're hiding the names of the types. Don't do that. As far as Python is concerned, it's just a name that refers to something. It doesn't care whether that something is a type or a function or something else, it's just a name that refers to something. From stestagg at gmail.com Sun May 23 16:02:58 2021 From: stestagg at gmail.com (Stestagg) Date: Sun, 23 May 2021 21:02:58 +0100 Subject: learning python ... In-Reply-To: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: On Sun, 23 May 2021 at 20:37, hw wrote: > On 5/23/21 7:28 PM, Peter Otten wrote: > > On 23/05/2021 06:37, hw wrote: > >> > >> Hi, > >> > >> I'm starting to learn python and have made a little example program > >> following a tutorial[1] I'm attaching. > >> > >> Running it, I'm getting: > >> > >> > >> Traceback (most recent call last): > >> File "[...]/hworld.py", line 18, in > >> print(isinstance(int, float)) > >> TypeError: isinstance() arg 2 must be a type or tuple of types > >> > >> > >> I would understand to get an error message in line 5 but not in 18. > >> Is this a bug or a feature? > > > > It is a bug in your code (which you don't provide). Did you assign some > > value to float, e. g.: > > > > >>> float = 42.0 > > >>> isinstance(int, float) > > Traceback (most recent call last): > > File "", line 1, in > > isinstance(int, float) > > TypeError: isinstance() arg 2 must be a type or tuple of types > > > > If you do not shadow the built-in you should get > > > > >>> isinstance(int, float) > > False > > > > Apparently the attachment was stripped from my message. I'll put a > smaller version directly into this message instead of an attachment: > > > #!/usr/bin/python > > print("world!") > > int = 17 > print("world", int) > > float = 6.670 > print("world", float) > > foo = 0 > print(type(int)) > print(type(float)) > print(type(foo)) > > print(isinstance(foo, str)) > print(isinstance(int, float)) > print(isinstance(float, float)) > > > I don't know about shadowing. Shadowing is effectively saying ?within this bit of code, (scope) I?m going to use an already-used name for my own value? If I have defeated a whole variable type > by naming a variable like a variable type, I would think it is a bad > idea for python to allow this without warning. There are some reasons why allowing this is quite nice. And there?s actually a ton of corner cases to consider when thinking about changing the rules Interestingly python 3 made this a little bit better by stopping you from rebinding (shadowing) a number of built ins, such as True and False. In your case, I agree that it is super confusing. One thing to learn to look out for is if you assign to a name, then use that name on a different context, expecting it to be different, then that?s not likely to work as you expect. It seems like a recipie > for creating chaos. Luckily almost every python code checker and/or linter will highlight this for you. If you?re learning python, I?d highly recommend doing so in an ide or editor that has a code checker running. > -- > https://mail.python.org/mailman/listinfo/python-list > From mats at wichmann.us Sun May 23 17:18:07 2021 From: mats at wichmann.us (Mats Wichmann) Date: Sun, 23 May 2021 15:18:07 -0600 Subject: Issue in software In-Reply-To: References: Message-ID: <1da49893-fc18-37d4-d8fd-3517e85ca0f8@wichmann.us> On 5/22/21 10:45 PM, pradeep Y wrote: > I I couldn't get the solution for this issue since last week will you > please help me to solve this issue the issue is when I opened command > prompt this below message will Pop up > > > "The program can't start because api-ms-win-crt-runtime-[1-1-0.dl] is > missing from your computer.try reinstalling the program to fix this > problem." > > > > I tried to solve several times and many times but I didn't get any expected > outcome. Can you please help me please. You're running Windows 7? That's where this usually happens. Here's (some of) the deal: when you build a program with Microsoft compilers (MSVC) it links in a way so that it requires certain runtime components. This is absolutely no different than other compilers + operating systems, to start with. In this case, the msvc version current Pythons are built with require a component that isn't available by default on Windows 7, or in fact, the WIndows 8 variants, which are quite old (*); it is included in Windows 10. The Python installer includes this piece, because it's a known issue, and it will try to installe it, but if you don't select an install with administrator privilege - and the Python devs worked hard to make it not necessary to do an admin install otherwise - installing it will fail... often silently from the point of view of what you as the user see (probably will be in the logfile). Sometimes it fails even with admin privilege AFAIK. Easiest workaround is to install the package that contains it - manually copying in dll files rarely works as expected. It comes from "Visual C++ 2015 Redistributable", if I'm not remembering wrong - that's something you should be able to find and install. (*) Win7 came out in 2009; Win8 in 2012; Win8.1 in 2013. It's somehow not entirely unsurprising that they wouldn't come with a piece of software that was introduced with Visual Studio 2015. From cs at cskk.id.au Sun May 23 18:03:24 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Mon, 24 May 2021 08:03:24 +1000 Subject: learning python ... In-Reply-To: References: Message-ID: On 23May2021 21:02, Stestagg wrote: >On Sun, 23 May 2021 at 20:37, hw wrote: >> I don't know about shadowing. > >Shadowing is effectively saying ?within this bit of code, (scope) I?m going >to use an already-used name for my own value? An example might make this clearer: x = 1 # global variable def f(a): x = a * 2 return x Inside the function f() the name 'x" shadows the global "x"; references to "x" are to the function's local vairable. Which is very desireable. >If I have defeated a whole variable type >> by naming a variable like a variable type, I would think it is a bad >> idea for python to allow this without warning. > >There are some reasons why allowing this is quite nice. And there?s >actually a ton of corner cases to consider when thinking about changing the >rules As Stestagg has mentioned, there are also tools called linters which warn you about issues like this. Tools like pyflakes, pylint, pycodestyle all inspect your code for a wide variety of potential errors and discouraged habits. Not to mention tools like mypy which do type validation. >Interestingly python 3 made this a little bit better by stopping you from >rebinding (shadowing) a number of built ins, such as True and False. > >In your case, I agree that it is super confusing. One thing to learn to >look out for is if you assign to a name, then use that name on a different >context, expecting it to be different, then that?s not likely to work as >you expect. > >It seems like a recipie >> for creating chaos. The runtime lets you do all sorts of things. Linters and type checkers exist to help you notice if you're writing such a recipe. There _are_ times when it is useful to shadow a builtin name. Not being able to prevents a useful activity. A common example in my own code is this: from cs.upd import Upd, print which shadows the print() builtin. The Upd class maintains status lines such as progress bars and so forth. It provides a print() function which withdraws the status lines, runs the builtin print, then restores them, allowing normal idiomatic use of print() in scripts making use of the status lines. Similar situations abound. Cheers, Cameron Simpson From martinp.dipaola at gmail.com Sun May 23 21:49:35 2021 From: martinp.dipaola at gmail.com (Martin Di Paola) Date: Mon, 24 May 2021 01:49:35 +0000 Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: <5a03d59e-dc6c-47b6-ac14-35e26c9c13d0n@googlegroups.com> References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <20210522195304.qlq4aot44bs2e5xa@gmail.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <5a03d59e-dc6c-47b6-ac14-35e26c9c13d0n@googlegroups.com> Message-ID: <20210524014935.xinvyvf2unq3ltp5@gmail.com> "unselectable text" not necessary means that it is an image. There is a CSS property that you can change to make a text selectable/unselectable. And if it is an image, it very likely that it comes from the server as such, so "intercepting" the packet coming from there will be for nothing: you will have the same image. About the "packet listener", you could setup a proxy between your browser and the server and use the proxy to see the messages. "Burp" is the classical tool for this. But I have the feeling that the solution is easier. Try the following: do it manually but take note of the steps you do. Example: 1) Go to page https://www.parisclassenumerique.fr 2) Click in the upper-right menu button and choose "Tutoriels". Now the URL is https://www.parisclassenumerique.fr/lutece/jsp/site/Portal.jsp?page_id=9 3) Then click in "Comment d?marrer sur PCN ?", on the left panel ... and so on. Basically you can then translate those steps to Selenium/selectq and automate them. It's here where I could help you but I cannot do much without more info because I don't know which page you are looking and in which link you are trying to click and stuff like that. On Sun, May 23, 2021 at 01:36:48AM -0700, max pothier wrote: >Hi, >Seems like that could be a method of doing things. Just one clarification: the website has unselectable text, looks like it's an image strangely generated, so if I can get the packet with it, it would be perfect. As I said (I think), logging in with Selenium was already possible, and I could get a screenshot of the page after logging in. >If you got this working like a packet listener in browser capable of seeing packet data, I'd gladly accept the code. >I've tried to do this for 3 years now (since I came into that school basically), looks like it's coming to an end! >Thanks! >-- >https://mail.python.org/mailman/listinfo/python-list From tjreedy at udel.edu Sun May 23 22:05:11 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 23 May 2021 22:05:11 -0400 Subject: Question for potential python development contributions on Windows In-Reply-To: <000001d74fef$7d0051f0$7700f5d0$@earthlink.net> References: <000001d74fef$7d0051f0$7700f5d0$@earthlink.net> Message-ID: On 5/23/2021 12:20 PM, pjfarley3 at earthlink.net wrote: > I asked this question on python-dev last week but did not get an answer. If > anyone here know the answer I would appreciate it. > > The Python Developers Guide specifically states to get VS2017 for developing > or enhancing python on a Windows system. > > Is it still correct to specifically use VS2017 , or is VS2019 also > acceptable? > > I ask this because I know that the *.vcxproj files and other > build-environment files have changed format pretty dramatically over the > many releases of VS. ?If a potential new contribution targeted for current > and future python will require new build environment files, I wouldn?t want > to have to ?down release? those files (or expect core dev?s to do it) at or > after submission to the community for approval.? Much better to use the same > setup as core dev?s use than to introduce up-level differences in the build > environment. > > IOW, for new releases on Windows are core dev?s still using VS2017 and so > potential contributors should also use that version, or has the core dev?s > process for Windows releases been updated to use VS2019? I am pretty sure that VS2019 output is binary compatible with with output from VS2017 and VS2015. I believe the only issue would be is one were developing a patch to a CPython .c file and one used recent C## features not allowed in CPython code. You could open an issue on bugs.python.org asking that the doc be clarified. -- Terry Jan Reedy From hw at adminart.net Mon May 24 01:20:39 2021 From: hw at adminart.net (hw) Date: Mon, 24 May 2021 07:20:39 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> On 5/23/21 10:02 PM, Stestagg wrote: > > > On Sun, 23 May 2021 at 20:37, hw > wrote: > > On 5/23/21 7:28 PM, Peter Otten wrote: > > On 23/05/2021 06:37, hw wrote: > >> > >> Hi, > >> > >> I'm starting to learn python and have made a little example program > >> following a tutorial[1] I'm attaching. > >> > >> Running it, I'm getting: > >> > >> > >> Traceback (most recent call last): > >> ?? File "[...]/hworld.py", line 18, in > >> ???? print(isinstance(int, float)) > >> TypeError: isinstance() arg 2 must be a type or tuple of types > >> > >> > >> I would understand to get an error message in line 5 but not in 18. > >> Is this a bug or a feature? > > > > It is a bug in your code (which you don't provide). Did you > assign some > > value to float, e. g.: > > > >? >>> float = 42.0 > >? >>> isinstance(int, float) > > Traceback (most recent call last): > >? ? File "", line 1, in > >? ??? isinstance(int, float) > > TypeError: isinstance() arg 2 must be a type or tuple of types > > > > If you do not shadow the built-in you should get > > > >? >>> isinstance(int, float) > > False > > > > Apparently the attachment was stripped from my message.? I'll put a > smaller version directly into this message instead of an attachment: > > > #!/usr/bin/python > > print("world!") > > int = 17 > print("world", int) > > float = 6.670 > print("world", float) > > foo = 0 > print(type(int)) > print(type(float)) > print(type(foo)) > > print(isinstance(foo, str)) > print(isinstance(int, float)) > print(isinstance(float, float)) > > > I don't know about shadowing. > > > Shadowing is effectively saying ?within this bit of code, (scope) I?m > going to use an already-used name for my own value? That should give at least a warning. > If I have defeated a whole variable type > by naming a variable like a variable type, I would think it is a bad > idea for python to allow this without warning. > > > There are some reasons why allowing this is quite nice. And there?s > actually a ton of corner cases to consider when thinking about changing > the rules Perl has a way to turn off unwanted warnings. It won't change the rules to give a warning. > Interestingly python 3 made this a little bit better by stopping you > from rebinding (shadowing) a number of built ins, such as True and False. > > In your case, I agree that it is super confusing. It seems dangerous and seems to show that python is too unfinished to be used. For all I know, it makes it easy to, for example, drop a whole table in a database because something was shadowed without warning. I can imagine that there can be all kinds of situations in which something like that happens, and you can spend hours or days trying to figure out what's wrong and may never find it. > One thing to learn to > look out for is if you assign to a name, then use that name on a > different context, expecting it to be different, then that?s not likely > to work as you expect. Then why doesn't give it at least a warning? There is even no indication from the output from the program before it aborts with an error message that something might be wrong: For 'type(float)', it prints "" just like it does for int. How is anyone supposed to debug stuff like that? Why doesn't print(type(float)) give an error message after the variable type was already defeated (or prints something else)? What is it actually printing? > It seems like a recipie > for creating chaos. > > > Luckily almost every python code checker and/or linter will highlight > this for you. > > If you?re learning python, I?d highly recommend doing so in an ide or > editor that has a code checker running. Emcas highlights the syntax fine; I don't know if it can do more for python. It shouldn't need to. Things get creepy when a programming language makes it so that the programmer can't figure out anymore how a result produced by his program has come about. From ikorot01 at gmail.com Mon May 24 01:34:16 2021 From: ikorot01 at gmail.com (Igor Korot) Date: Mon, 24 May 2021 00:34:16 -0500 Subject: learning python ... In-Reply-To: <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> Message-ID: Hi, On Mon, May 24, 2021 at 12:26 AM hw wrote: > > On 5/23/21 10:02 PM, Stestagg wrote: > > > > > > On Sun, 23 May 2021 at 20:37, hw > > wrote: > > > > On 5/23/21 7:28 PM, Peter Otten wrote: > > > On 23/05/2021 06:37, hw wrote: > > >> > > >> Hi, > > >> > > >> I'm starting to learn python and have made a little example program > > >> following a tutorial[1] I'm attaching. > > >> > > >> Running it, I'm getting: > > >> > > >> > > >> Traceback (most recent call last): > > >> File "[...]/hworld.py", line 18, in > > >> print(isinstance(int, float)) > > >> TypeError: isinstance() arg 2 must be a type or tuple of types > > >> > > >> > > >> I would understand to get an error message in line 5 but not in 18. > > >> Is this a bug or a feature? > > > > > > It is a bug in your code (which you don't provide). Did you > > assign some > > > value to float, e. g.: > > > > > > >>> float = 42.0 > > > >>> isinstance(int, float) > > > Traceback (most recent call last): > > > File "", line 1, in > > > isinstance(int, float) > > > TypeError: isinstance() arg 2 must be a type or tuple of types > > > > > > If you do not shadow the built-in you should get > > > > > > >>> isinstance(int, float) > > > False > > > > > > > Apparently the attachment was stripped from my message. I'll put a > > smaller version directly into this message instead of an attachment: > > > > > > #!/usr/bin/python > > > > print("world!") > > > > int = 17 > > print("world", int) > > > > float = 6.670 > > print("world", float) > > > > foo = 0 > > print(type(int)) > > print(type(float)) > > print(type(foo)) > > > > print(isinstance(foo, str)) > > print(isinstance(int, float)) > > print(isinstance(float, float)) > > > > > > I don't know about shadowing. > > > > > > Shadowing is effectively saying ?within this bit of code, (scope) I?m > > going to use an already-used name for my own value? > > That should give at least a warning. > > > If I have defeated a whole variable type > > by naming a variable like a variable type, I would think it is a bad > > idea for python to allow this without warning. > > > > > > There are some reasons why allowing this is quite nice. And there?s > > actually a ton of corner cases to consider when thinking about changing > > the rules > > Perl has a way to turn off unwanted warnings. It won't change the rules > to give a warning. > > > Interestingly python 3 made this a little bit better by stopping you > > from rebinding (shadowing) a number of built ins, such as True and False. > > > > In your case, I agree that it is super confusing. > > It seems dangerous and seems to show that python is too unfinished to be > used. For all I know, it makes it easy to, for example, drop a whole > table in a database because something was shadowed without warning. > > I can imagine that there can be all kinds of situations in which > something like that happens, and you can spend hours or days trying to > figure out what's wrong and may never find it. > > > One thing to learn to > > look out for is if you assign to a name, then use that name on a > > different context, expecting it to be different, then that?s not likely > > to work as you expect. > > Then why doesn't give it at least a warning? > > There is even no indication from the output from the program before it > aborts with an error message that something might be wrong: For > 'type(float)', it prints "" just like it does for int. > How is anyone supposed to debug stuff like that? > > Why doesn't print(type(float)) give an error message after the variable > type was already defeated (or prints something else)? What is it > actually printing? > > > It seems like a recipie > > for creating chaos. > > > > > > Luckily almost every python code checker and/or linter will highlight > > this for you. > > > > If you?re learning python, I?d highly recommend doing so in an ide or > > editor that has a code checker running. > > Emcas highlights the syntax fine; I don't know if it can do more for > python. It shouldn't need to. > > Things get creepy when a programming language makes it so that the > programmer can't figure out anymore how a result produced by his program > has come about. Remember - python is an untyped language. It is not C, C++ or even Pascal. So there is no difference whether you write float = 5.0 or float1 = 5.0 Thank you. > -- > https://mail.python.org/mailman/listinfo/python-list From hw at adminart.net Mon May 24 01:31:37 2021 From: hw at adminart.net (hw) Date: Mon, 24 May 2021 07:31:37 +0200 Subject: learning python ... In-Reply-To: <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> Message-ID: <8ef57f67-e7f5-2020-6d9f-50403d153fc2@adminart.net> PS: On 5/24/21 7:20 AM, hw wrote: > There is even no indication from the output from the program before it > aborts with an error message that something might be wrong:? For > 'type(float)', it prints "" just like it does for int. > How is anyone supposed to debug stuff like that? Ok, it prints "" for type(str) when str hasn't been defeated. But still: #!/usr/bin/python foo = 0 print(type(int)) print(type(float)) print(type(foo)) print(type(str)) type = 4 print(type(str)) line 9, in print(type(str)) TypeError: 'int' object is not callable How is this /not/ bad? It seems like a no-go for any programming language that isn't designed for the programmer to shoot into thier own feet. From hw at adminart.net Mon May 24 02:21:19 2021 From: hw at adminart.net (hw) Date: Mon, 24 May 2021 08:21:19 +0200 Subject: learning python ... In-Reply-To: References: Message-ID: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> On 5/24/21 12:03 AM, Cameron Simpson wrote: > On 23May2021 21:02, Stestagg wrote: >> On Sun, 23 May 2021 at 20:37, hw wrote: >>> I don't know about shadowing. >> >> Shadowing is effectively saying ?within this bit of code, (scope) I?m going >> to use an already-used name for my own value? > > An example might make this clearer: > > x = 1 # global variable > > def f(a): > x = a * 2 > return x > > Inside the function f() the name 'x" shadows the global "x"; references > to "x" are to the function's local vairable. Which is very desireable. If it works that way, I would consider it an entirely different variable. Is there a way to access the global x from within a function without transferring it through parameters of the function? Than can also sometimes be useful. >> If I have defeated a whole variable type >>> by naming a variable like a variable type, I would think it is a bad >>> idea for python to allow this without warning. >> >> There are some reasons why allowing this is quite nice. And there?s >> actually a ton of corner cases to consider when thinking about changing the >> rules > > As Stestagg has mentioned, there are also tools called linters which > warn you about issues like this. Tools like pyflakes, pylint, > pycodestyle all inspect your code for a wide variety of potential errors > and discouraged habits. Not to mention tools like mypy which do type > validation. So you're saying one can't really go without those unless you want to take the risk? >> Interestingly python 3 made this a little bit better by stopping you from >> rebinding (shadowing) a number of built ins, such as True and False. >> >> In your case, I agree that it is super confusing. One thing to learn to >> look out for is if you assign to line 9, in print(type(str)) TypeError: 'int' object is not callablea name, then use that name on a different >> context, expecting it to be different, then that?s not likely to work as >> you expect. >> >> It seems like a recipie >>> for creating chaos. > > The runtime lets you do all sorts of things. Linters and type checkers > exist to help you notice if you're writing such a recipe. > > There _are_ times when it is useful to shadow a builtin name. Not being > able to prevents a useful activity. > > A common example in my own code is this: > > from cs.upd import Upd, print > > which shadows the print() builtin. The Upd class maintains status lines > such as progress bars and so forth. It provides a print() function which > withdraws the status lines, runs the builtin print, then restores them, > allowing normal idiomatic use of print() in scripts making use of the > status lines. > > Similar situations abound. I'm not saying it shouldn't be allowed to defeat or to re-define stuff, only that it shouldn't go through quietly. From rosuav at gmail.com Mon May 24 03:52:20 2021 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 24 May 2021 17:52:20 +1000 Subject: learning python ... In-Reply-To: <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> Message-ID: On Mon, May 24, 2021 at 3:25 PM hw wrote: > > On 5/23/21 10:02 PM, Stestagg wrote: > > > > > > On Sun, 23 May 2021 at 20:37, hw > > wrote: > > > > On 5/23/21 7:28 PM, Peter Otten wrote: > > > On 23/05/2021 06:37, hw wrote: > > >> > > >> Hi, > > >> > > >> I'm starting to learn python and have made a little example program > > >> following a tutorial[1] I'm attaching. > > >> > > >> Running it, I'm getting: > > >> > > >> > > >> Traceback (most recent call last): > > >> File "[...]/hworld.py", line 18, in > > >> print(isinstance(int, float)) > > >> TypeError: isinstance() arg 2 must be a type or tuple of types > > >> > > >> > > >> I would understand to get an error message in line 5 but not in 18. > > >> Is this a bug or a feature? > > > > > > It is a bug in your code (which you don't provide). Did you > > assign some > > > value to float, e. g.: > > > > > > >>> float = 42.0 > > > >>> isinstance(int, float) > > > Traceback (most recent call last): > > > File "", line 1, in > > > isinstance(int, float) > > > TypeError: isinstance() arg 2 must be a type or tuple of types > > > > > > If you do not shadow the built-in you should get > > > > > > >>> isinstance(int, float) > > > False > > > > > > > Apparently the attachment was stripped from my message. I'll put a > > smaller version directly into this message instead of an attachment: > > > > > > #!/usr/bin/python > > > > print("world!") > > > > int = 17 > > print("world", int) > > > > float = 6.670 > > print("world", float) > > > > foo = 0 > > print(type(int)) > > print(type(float)) > > print(type(foo)) > > > > print(isinstance(foo, str)) > > print(isinstance(int, float)) > > print(isinstance(float, float)) > > > > > > I don't know about shadowing. > > > > > > Shadowing is effectively saying ?within this bit of code, (scope) I?m > > going to use an already-used name for my own value? > > That should give at least a warning. No, it shouldn't, because it's a deliberate feature. The entire point of scoping rules - whether you're in C, Python, REXX, or any other language - is to *allow* you to use a name for what you intend it to be. Does C give you a warning if you create a function-local variable called "printf"? No, and it shouldn't. Does any other language complain if you use its scoping rules to reuse a name? Nope. Does Python? As above, no. > It seems dangerous and seems to show that python is too unfinished to be > used. For all I know, it makes it easy to, for example, drop a whole > table in a database because something was shadowed without warning. No, it doesn't. It simply allows you to use a name the way you choose to. And if you want to learn how to use Python, stop insulting it - calling it "too unfinished to be used" is a tad unfair to a language that has been used in production code for three decades. All you're really doing is proving the Blub Paradox - look it up. > I can imagine that there can be all kinds of situations in which > something like that happens, and you can spend hours or days trying to > figure out what's wrong and may never find it. What happens more often with me is that I'm typing out a perfectly reasonable section of code, and my editor highlights some word, and I realize that I'm shadowing some obscure standard library name or something. (And then I usually just carry on, because there's no way that it's going to matter.) > > One thing to learn to > > look out for is if you assign to a name, then use that name on a > > different context, expecting it to be different, then that?s not likely > > to work as you expect. > > Then why doesn't give it at least a warning? Because there's no difference between shadowing a standard library name and shadowing your own name. And there's absolutely nothing wrong with that. > There is even no indication from the output from the program before it > aborts with an error message that something might be wrong: For > 'type(float)', it prints "" just like it does for int. > How is anyone supposed to debug stuff like that? You debug it by noticing that you changed the value of "float" between where you printed it and where you tried to call it. Or changed the value of "type", either way. You debug it by printing things out *right where the exception is happening*. You debug it, especially, by *reading the exception traceback* to figure out where your code isn't doing the right thing. This is what it is to be a programmer. > Why doesn't print(type(float)) give an error message after the variable > type was already defeated (or prints something else)? What is it > actually printing? It's calling type, whatever that is, with the value of float, whatever that is, and then printing out the result. This is exactly what you asked it to do. > Things get creepy when a programming language makes it so that the > programmer can't figure out anymore how a result produced by his program > has come about. Learn the language before you blame the language for this. All you're doing is insulting Python, insulting all of us for using it, moaning, complaining, and all in all, revealing your own shortcomings. If you want to become a better programmer, start by assuming that you are an imperfect programmer, rather than assuming that Python should be "better". ChrisA From hjp-python at hjp.at Mon May 24 05:11:28 2021 From: hjp-python at hjp.at (Peter J. Holzer) Date: Mon, 24 May 2021 11:11:28 +0200 Subject: learning python ... In-Reply-To: <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> Message-ID: <20210524091128.GA8638@hjp.at> On 2021-05-24 07:20:39 +0200, hw wrote: > python is too unfinished to be used. You have to realize that different programming languages have different goals and develop in different directions. Python is not an "unfinished Java" (and neither is Java an "unfinished Python"). The scoping and binding rules of Python were a conscious decision, not a quick hack intended to be fixed later. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cs at cskk.id.au Mon May 24 05:33:49 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Mon, 24 May 2021 19:33:49 +1000 Subject: learning python ... In-Reply-To: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> Message-ID: On 24May2021 08:21, hw wrote: >On 5/24/21 12:03 AM, Cameron Simpson wrote: >>On 23May2021 21:02, Stestagg wrote: >>>On Sun, 23 May 2021 at 20:37, hw wrote: >>>>I don't know about shadowing. >>> >>>Shadowing is effectively saying ?within this bit of code, (scope) I?m going >>>to use an already-used name for my own value? >> >>An example might make this clearer: >> >> x = 1 # global variable >> >> def f(a): >> x = a * 2 >> return x >> >>Inside the function f() the name 'x" shadows the global "x"; references >>to "x" are to the function's local vairable. Which is very desireable. > >If it works that way, I would consider it an entirely different >variable. Is there a way to access the global x from within a >function without transferring it through parameters of the function? >Than can also sometimes be useful. Sure. You can declare a name like this: def f(a): global x # find x in the global namespace (the module) x = a * 2 return x This is pretty rare and usually discouraged. Of there are times when it is useful. Note that in this function: x = 1 y = 2 def f(a): x = 3 print(x, y) "x" is local, because the function contains an assignment to it. "y" comes from an outer scope (in this case, the global scope) because there's no assignment to it. >>As Stestagg has mentioned, there are also tools called linters which >>warn you about issues like this. Tools like pyflakes, pylint, >>pycodestyle all inspect your code for a wide variety of potential errors >>and discouraged habits. Not to mention tools like mypy which do type >>validation. > >So you're saying one can't really go without those unless you want to >take the risk? Self restraint and developing good habits does 99% of the work. Linters are great for catching various accidents. [...] >I'm not saying it shouldn't be allowed to defeat or to re-define stuff, >only that it shouldn't go through quietly. Well, most of us use linters to exhibit that noise, rather than requiring the code to be littered with special directives. I usually code without much linter fuss until I've got the latest batch of work (eg feature or fix) ready, commit the changes, then lint vigorously and commit that polish before merging with the main line of code. Finally, consider this code: num = input("Enter a number: ") num = int(num) input() returns a string, which would need converting to a number before some numeric stuff. Plenty of people write the above. To my mind, this is also a kind of shadowing, and I like this instead: num_s = input("Enter a number: ") num = int(num_s) where the "_s" indicates quietly that this variable holds a string. Is that shadowing to your mind? Or not? If yes, should the language emit noise there, too? Remembering that Python _values_ are strongly typed, though the variables are not (a variable might reference any kind of object, as above). I wouldn't say that your opinion would be wrong regardless of what side of this question you come down on, but Python's chosen a side: noise for nonsensical things, but not noise for dubious things. But plenty of linters to complain about dubious things. Cheers, Cameron Simpson From hw at adminart.net Mon May 24 09:34:37 2021 From: hw at adminart.net (hw) Date: Mon, 24 May 2021 15:34:37 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> Message-ID: <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> On 5/24/21 9:52 AM, Chris Angelico wrote: > On Mon, May 24, 2021 at 3:25 PM hw wrote: >> >> On 5/23/21 10:02 PM, Stestagg wrote: >>> >>> >>> On Sun, 23 May 2021 at 20:37, hw >> > wrote: >>> >>> On 5/23/21 7:28 PM, Peter Otten wrote: >>> > On 23/05/2021 06:37, hw wrote: >>> >> >>> >> Hi, >>> >> >>> >> I'm starting to learn python and have made a little example program >>> >> following a tutorial[1] I'm attaching. >>> >> >>> >> Running it, I'm getting: >>> >> >>> >> >>> >> Traceback (most recent call last): >>> >> File "[...]/hworld.py", line 18, in >>> >> print(isinstance(int, float)) >>> >> TypeError: isinstance() arg 2 must be a type or tuple of types >>> >> >>> >> >>> >> I would understand to get an error message in line 5 but not in 18. >>> >> Is this a bug or a feature? >>> > >>> > It is a bug in your code (which you don't provide). Did you >>> assign some >>> > value to float, e. g.: >>> > >>> > >>> float = 42.0 >>> > >>> isinstance(int, float) >>> > Traceback (most recent call last): >>> > File "", line 1, in >>> > isinstance(int, float) >>> > TypeError: isinstance() arg 2 must be a type or tuple of types >>> > >>> > If you do not shadow the built-in you should get >>> > >>> > >>> isinstance(int, float) >>> > False >>> > >>> >>> Apparently the attachment was stripped from my message. I'll put a >>> smaller version directly into this message instead of an attachment: >>> >>> >>> #!/usr/bin/python >>> >>> print("world!") >>> >>> int = 17 >>> print("world", int) >>> >>> float = 6.670 >>> print("world", float) >>> >>> foo = 0 >>> print(type(int)) >>> print(type(float)) >>> print(type(foo)) >>> >>> print(isinstance(foo, str)) >>> print(isinstance(int, float)) >>> print(isinstance(float, float)) >>> >>> >>> I don't know about shadowing. >>> >>> >>> Shadowing is effectively saying ?within this bit of code, (scope) I?m >>> going to use an already-used name for my own value? >> >> That should give at least a warning. > > No, it shouldn't, because it's a deliberate feature. The entire point > of scoping rules - whether you're in C, Python, REXX, or any other > language - is to *allow* you to use a name for what you intend it to > be. > > Does C give you a warning if you create a function-local variable > called "printf"? No, and it shouldn't. Does any other language > complain if you use its scoping rules to reuse a name? Nope. Does > Python? As above, no. Try the equivalent of above python in C: void foo(void) { int int = 25; printf("int: %d\n", int); } int main(int argc, char **argv) { foo(); } I don't know which C compiler you're using; gcc doesn't compile this and gives several error messages. Python quietly allows things like this without any warning at all, and I'm saying that's a bad thing and that python seems unfinished because it doesn't even give a warning in cases like this. I don't know REXX, and I'm not sure what the equivalent would be in elisp. The issue doesn't exist in perl. It may be intentionally so that python makes it easy to defeat fundamental aspects of the language simply by, accidentially or intentionally, re-defining them without warning, and even if that is so, nobody else has to like a feature like that just because you do like it. Maybe you can show how this is a likeable feature. I already understood that you can somehow re-define functions in python and I can see how that can be useful. You can do things like that in elisp as well. But easily messing up built-in variable types like that is something else. Why would I want that in a programming language, and why would I want to use one that allows it? Your claim that I'm insulting python or anoyone is ridiculous. According to your logic, C is insulting python. I suggest you stop making assumptions. The example you want is probably this one: #include void foo(void) { int printf = 25; printf("int: %d\n", printf); } int main(int argc, char **argv) { foo(); } Perhaps you can't see how both examples are different because you're looking at things from a python perspective. From rosuav at gmail.com Mon May 24 09:54:03 2021 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 24 May 2021 23:54:03 +1000 Subject: learning python ... In-Reply-To: <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On Mon, May 24, 2021 at 11:35 PM hw wrote: > > On 5/24/21 9:52 AM, Chris Angelico wrote: > > Does C give you a warning if you create a function-local variable > > called "printf"? No, and it shouldn't. Does any other language > > complain if you use its scoping rules to reuse a name? Nope. Does > > Python? As above, no. > > Try the equivalent of above python in C: > > > void foo(void) { > int int = 25; > printf("int: %d\n", int); > } > > int main(int argc, char **argv) { > foo(); > } I did specifically mention "printf", which works just fine, as you see below. > I don't know which C compiler you're using; gcc doesn't compile this and > gives several error messages. Python quietly allows things like this > without any warning at all, and I'm saying that's a bad thing and that > python seems unfinished because it doesn't even give a warning in cases > like this. You keep using that word "unfinished". I do not think it means what you think it does. Python has keywords. C has keywords. In Python, "None" is a keyword, so you can't assign to it; in C, "int" is a keyword, so you can't assign to it. There is no fundamental difference here, and the two languages even have roughly the same number of keywords (35 in current versions of Python; about 40 or 50 in C, depending on the exact specification you're targeting). The only difference is that, in Python, type names aren't keywords. You're getting caught up on a trivial difference that has happened to break one particular test that you did, and that's all. > I don't know REXX, and I'm not sure what the equivalent would be in > elisp. The issue doesn't exist in perl. It may be intentionally so > that python makes it easy to defeat fundamental aspects of the language > simply by, accidentially or intentionally, re-defining them without > warning, and even if that is so, nobody else has to like a feature like > that just because you do like it. REXX doesn't have keywords at all. (It has language syntax words, but everything is contextual, so you can quite happily say "if = 1" and then "if if" becomes valid.) Perl has keywords, just like everything else, but not for data types. This is NOT something fundamental to the language that is "defeated". You have made it harder to perform isinstance checks, but that's neither fundamental nor defeated by this shadowing. The integer type still exists - you just made a new variable with the name "int". The float type still exists - you just made a new variable with the name "float". > Maybe you can show how this is a likeable feature. I already understood > that you can somehow re-define functions in python and I can see how > that can be useful. You can do things like that in elisp as well. But > easily messing up built-in variable types like that is something else. > Why would I want that in a programming language, and why would I want to > use one that allows it? Because all you did was mess with the *name* of the type. It's not breaking the type system at all. Most Python programs manage just fine without ever doing an isinstance check, and even if you do have to, it's possible to refer to the type in other ways: >>> (1).__class__ >>> int = 42 >>> isinstance(int, (1).__class__) True See? Not broken. All you did was change the meaning of the name "int", by assigning to it. > Your claim that I'm insulting python or anoyone is ridiculous. > According to your logic, C is insulting python. I suggest you stop > making assumptions. The C language never says that Python is "unfinished". I'm not making assumptions, I'm reading your posts. > The example you want is probably this one: > > > #include > > void foo(void) { > int printf = 25; > printf("int: %d\n", printf); > } > > int main(int argc, char **argv) { > foo(); > } > > > Perhaps you can't see how both examples are different because you're > looking at things from a python perspective. Well, look at them from a language design perspective and tell me how different they really are. ChrisA From hw at adminart.net Mon May 24 10:17:09 2021 From: hw at adminart.net (hw) Date: Mon, 24 May 2021 16:17:09 +0200 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> Message-ID: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> On 5/24/21 11:33 AM, Cameron Simpson wrote: > On 24May2021 08:21, hw wrote: >> On 5/24/21 12:03 AM, Cameron Simpson wrote: >>> On 23May2021 21:02, Stestagg wrote: >>>> On Sun, 23 May 2021 at 20:37, hw wrote: >>>>> I don't know about shadowing. >>>> >>>> Shadowing is effectively saying ?within this bit of code, (scope) I?m going >>>> to use an already-used name for my own value? >>> >>> An example might make this clearer: >>> >>> x = 1 # global variable >>> >>> def f(a): >>> x = a * 2 >>> return x >>> >>> Inside the function f() the name 'x" shadows the global "x"; references >>> to "x" are to the function's local vairable. Which is very desireable. >> >> If it works that way, I would consider it an entirely different >> variable. Is there a way to access the global x from within a >> function without transferring it through parameters of the function? >> Than can also sometimes be useful. > > Sure. You can declare a name like this: > > def f(a): > global x # find x in the global namespace (the module) > x = a * 2 > return x > > This is pretty rare and usually discouraged. Of there are times when it > is useful. > > Note that in this function: > > x = 1 > y = 2 > > def f(a): > x = 3 > print(x, y) > > "x" is local, because the function contains an assignment to it. "y" > comes from an outer scope (in this case, the global scope) because > there's no assignment to it. Thanks! That basically works the same as in perl then. >>> As Stestagg has mentioned, there are also tools called linters which >>> warn you about issues like this. Tools like pyflakes, pylint, >>> pycodestyle all inspect your code for a wide variety of potential errors >>> and discouraged habits. Not to mention tools like mypy which do type >>> validation. >> >> So you're saying one can't really go without those unless you want to >> take the risk? > > Self restraint and developing good habits does 99% of the work. Linters > are great for catching various accidents. I never needed one before. > [...] >> I'm not saying it shouldn't be allowed to defeat or to re-define stuff, >> only that it shouldn't go through quietly. > > Well, most of us use linters to exhibit that noise, rather than > requiring the code to be littered with special directives. > > I usually code without much linter fuss until I've got the latest batch > of work (eg feature or fix) ready, commit the changes, then lint > vigorously and commit that polish before merging with the main line of > code. Maybe python requires a different approach than other languages in that it doesn't allow for the overhead that can be used to make things easy to read and without guessing in other languages. That overhead can be a disadvantage, yet getting to used to not having it could take a while. > Finally, consider this code: > > num = input("Enter a number: ") > num = int(num) > > input() returns a string, which would need converting to a number before > some numeric stuff. Plenty of people write the above. To my mind, this > is also a kind of shadowing, and I like this instead: > > num_s = input("Enter a number: ") > num = int(num_s) > > where the "_s" indicates quietly that this variable holds a string. Isn't that a kind of overhead python is trying to avoid? > Is that shadowing to your mind? Or not? If yes, should the language emit > noise there, too? Remembering that Python _values_ are strongly typed, > though the variables are not (a variable might reference any kind of > object, as above). No, I don't see any shadowing in either example. In the first one, you (seem to) make sure that you get an integer (not considering what happens when the input is not something that can be cast into an integer) using the same variable by altering its contents. In the second example, you're using two different variables, trying to cast the first one to an integer while assigning it to a second one which is implicitly declared. If anything, I could argue that this is convoluted code because you're doing lots of stuff implicitly --- and that could be argued for both examples. You could make it worse like if(int(num = input("foo: ")) == 5): pass involving side effects, but I don't know if python would allow you to do that. (Not that I would want to do something like this, but it would make sense to me if it could be done ...) > I wouldn't say that your opinion would be wrong regardless of what side > of this question you come down on, but Python's chosen a side: noise for > nonsensical things, but not noise for dubious things. But plenty of > linters to complain about dubious things. What does python actually do in the first example? Does it overshadow a variable or does it change one? If it overshadows a variable, it would be dubious, if it doesn't, it won't be dubious. There are more alternatives: Python might create a new variable with the same name and forget about the old one. Or it doesn't forget about the old one and the old one becomes inaccessible (unless you have a reference to it, if there is such a thing in python). How do you call that? From torriem at gmail.com Mon May 24 10:21:33 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 08:21:33 -0600 Subject: learning python ... In-Reply-To: <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: <2bd5da94-e585-5992-8f96-cb8a5157793b@gmail.com> On 5/24/21 7:34 AM, hw wrote: > Perhaps you can't see how both examples are different because you're > looking at things from a python perspective. Sorry but they aren't all that different. In both cases you're shadowing printf. The difference is that C is a statically-typed, compiled language, so the compiler complains that an int is not callable, whereas Python is a dynamic language so lookups are done at run time, not compile time. I don't know your background, but it sounds like you've not had a lot of experience with dynamic languages. Certainly you have never used a language like Scheme or LISP! Or Smalltalk! What is your purpose here? Why are you learning Python when it's apparently that you have very little desire to understand the hows and whys of Python and its idioms and paradigms, and to find its strengths. You've encountered some things that to you are unexpected. That happens when learning any language. Unfortunately from time to time we see someone come to the list apparently trying to do battle with the language; rather than learn how to work with the language they try to twist python to their preconceived notions of what a proper language should be, whether that's by getting hung up on a specific criticism of the grammar, or by trying to program Python in another language (often Java). Such encounters always lead to frustration and such posters most often walkaway disillusioned and even bitter. It's a bit of an odd thing to watch, and always sad because the outcome simply hinges on the attitude of the person learning the language. Someone that works with the language finds it's a very expressive and powerful tool. Given your posts thus far, hw, I don't think Python is a good fit for you. You're better off learning a language that more closely aligns with the statically-typed languages you already know. From rosuav at gmail.com Mon May 24 10:24:25 2021 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 25 May 2021 00:24:25 +1000 Subject: learning python ... In-Reply-To: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On Tue, May 25, 2021 at 12:18 AM hw wrote: > There are more alternatives: Python might create a new variable with > the same name and forget about the old one. Or it doesn't forget about > the old one and the old one becomes inaccessible (unless you have a > reference to it, if there is such a thing in python). How do you call that? It's the latter option: create a new variable, and the old one becomes inaccessible. That's called "shadowing". It's how scoping works in most languages (called "lexical scope"). ChrisA From torriem at gmail.com Mon May 24 10:28:42 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 08:28:42 -0600 Subject: learning python ... In-Reply-To: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 5/24/21 8:17 AM, hw wrote: > What does python actually do in the first example? Does it overshadow a > variable or does it change one? If it overshadows a variable, it would > be dubious, if it doesn't, it won't be dubious. Are you referring to this? num = input("Enter a number: ") num = int(num) No it is not "overshadowing" a variable. You cannot get back to the original string value for num. > There are more alternatives: Python might create a new variable with > the same name and forget about the old one. Or it doesn't forget about > the old one and the old one becomes inaccessible (unless you have a > reference to it, if there is such a thing in python). How do you call that? Python variables are not memory boxes like in a compiled language. They are names bound to objects, as Mr Simpson alluded to. So in the first line, the name num is bound to a string. In the second line, the name is re-bound to an int object. Furthermore, if num had come from the global name scope, either of these lines would create a local name num that does shadow the name from the global scope. Hope that helps. From torriem at gmail.com Mon May 24 10:30:29 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 08:30:29 -0600 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> On 5/24/21 8:24 AM, Chris Angelico wrote: > On Tue, May 25, 2021 at 12:18 AM hw wrote: >> There are more alternatives: Python might create a new variable with >> the same name and forget about the old one. Or it doesn't forget about >> the old one and the old one becomes inaccessible (unless you have a >> reference to it, if there is such a thing in python). How do you call that? > > It's the latter option: create a new variable, and the old one becomes > inaccessible. That's called "shadowing". It's how scoping works in > most languages (called "lexical scope"). Is it really shadowing, though? The old one is not only inaccessible, it's possibly reaped by the garbage collector, no? Both nums are in the same scope so the one overwrote the other in the name table. Or am I missing something. From rosuav at gmail.com Mon May 24 10:37:18 2021 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 25 May 2021 00:37:18 +1000 Subject: learning python ... In-Reply-To: <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> Message-ID: On Tue, May 25, 2021 at 12:31 AM Michael Torrie wrote: > > On 5/24/21 8:24 AM, Chris Angelico wrote: > > On Tue, May 25, 2021 at 12:18 AM hw wrote: > >> There are more alternatives: Python might create a new variable with > >> the same name and forget about the old one. Or it doesn't forget about > >> the old one and the old one becomes inaccessible (unless you have a > >> reference to it, if there is such a thing in python). How do you call that? > > > > It's the latter option: create a new variable, and the old one becomes > > inaccessible. That's called "shadowing". It's how scoping works in > > most languages (called "lexical scope"). > > Is it really shadowing, though? The old one is not only inaccessible, > it's possibly reaped by the garbage collector, no? Both nums are in the > same scope so the one overwrote the other in the name table. Or am I > missing something. > We're talking about many different things. If it's simply "num = ..." followed by "num = ...", then it's not a new variable or anything, it's simply rebinding the same name. But when you do "int = ...", it's shadowing the builtin name. But the rules are very close to the same in most modern high level languages. There are some small differences (eg Python doesn't have sub-function scope, but C-like languages can do that; JavaScript kinda does and kinda doesn't, because JavaScript), but by and large, the same rules apply. ChrisA From torriem at gmail.com Mon May 24 10:41:22 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 08:41:22 -0600 Subject: learning python ... In-Reply-To: <2bd5da94-e585-5992-8f96-cb8a5157793b@gmail.com> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2bd5da94-e585-5992-8f96-cb8a5157793b@gmail.com> Message-ID: <75e7d97b-df0e-d4f9-b640-73aa20ae0d52@gmail.com> On 5/24/21 8:21 AM, Michael Torrie wrote: > Given your posts thus far, hw, I don't think Python is a good fit for > you. You're better off learning a language that more closely aligns with > the statically-typed languages you already know. That was unnecessarily harsh; my apologies. I can see now that you might be comparing some features to Perl, which is a more dynamic language. I see in your recent posts that you are trying to understand how Python works, and that is good. Hopefully you'll find Python a dynamic and useful tool. If not, that's perfectly okay. Use the right tool for the job. From torriem at gmail.com Mon May 24 10:43:54 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 08:43:54 -0600 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> Message-ID: <5b1308a5-fe40-5bae-5a80-6cc55c0953f1@gmail.com> On 5/24/21 8:37 AM, Chris Angelico wrote: > We're talking about many different things. Indeed. The context of that original question about whether this was shadowing or not seemed to be specifically about the num=input(); num=int(num) example that Cameron Simpson posted. Although hw was not clear on that. From Joseph.Schachner at Teledyne.com Mon May 24 10:42:40 2021 From: Joseph.Schachner at Teledyne.com (Schachner, Joseph) Date: Mon, 24 May 2021 14:42:40 +0000 Subject: learning python ... In-Reply-To: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: OMG that is awful abuse of Python! You have overloaded two Python keywords by making variables of that name. As a result, float is no longer a type name, it is a variable name that refers to the value 6.67 ! Type(int) is int; type(float) is float, but isinstance(int,float) doesn't work because float is not a type in your script because you assigned float=6.67 and the local variable dictionary is searched first! To fix this, make your variable name myfloat. Change it wherever the variable name is wanted. In particular, the last line should be print(isinstance(myfloat, float)). The first argument is the variable, the second should be type name. --- Joseph S. Teledyne Confidential; Commercially Sensitive Business Data -----Original Message----- From: hw Sent: Sunday, May 23, 2021 3:34 PM To: python-list at python.org Subject: Re: learning python ... On 5/23/21 7:28 PM, Peter Otten wrote: > On 23/05/2021 06:37, hw wrote: >> >> Hi, >> >> I'm starting to learn python and have made a little example program >> following a tutorial[1] I'm attaching. >> >> Running it, I'm getting: >> >> >> Traceback (most recent call last): >> ?? File "[...]/hworld.py", line 18, in >> ???? print(isinstance(int, float)) >> TypeError: isinstance() arg 2 must be a type or tuple of types >> >> >> I would understand to get an error message in line 5 but not in 18. >> Is this a bug or a feature? > > It is a bug in your code (which you don't provide). Did you assign > some value to float, e. g.: > > >>> float = 42.0 > >>> isinstance(int, float) > Traceback (most recent call last): > ? File "", line 1, in > ??? isinstance(int, float) > TypeError: isinstance() arg 2 must be a type or tuple of types > > If you do not shadow the built-in you should get > > >>> isinstance(int, float) > False > Apparently the attachment was stripped from my message. I'll put a smaller version directly into this message instead of an attachment: #!/usr/bin/python print("world!") int = 17 print("world", int) float = 6.670 print("world", float) foo = 0 print(type(int)) print(type(float)) print(type(foo)) print(isinstance(foo, str)) print(isinstance(int, float)) print(isinstance(float, float)) I don't know about shadowing. If I have defeated a whole variable type by naming a variable like a variable type, I would think it is a bad idea for python to allow this without warning. It seems like a recipie for creating chaos. From rob.cliffe at btinternet.com Mon May 24 10:32:57 2021 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Mon, 24 May 2021 15:32:57 +0100 Subject: learning python ... In-Reply-To: <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 24/05/2021 14:34, hw wrote: > > Your claim that I'm insulting python or anoyone is ridiculous. > According to your logic, C is insulting python.? I suggest you stop > making assumptions. Calling a mature, widely used language "unfinished" because of what *you* see as a defect *is* insulting. (Of course, all languages evolve, and Python is no exception.? But the change you are in effect proposing won't happen.) And using a hectoring arrogant tone as a self-confessed Python beginner when addressing veterans with decades of experience in *developing Python* as well as developing with Python (disclosure: I'm not describing myself) is unlikely to endear anyone to your views. Python has few keywords (deliberately so), and anything that is not a keyword can be used as an identifier.? That will stop your program from crashing in 5 years time if a new built-in type is added to the language that happens to have the same name as an identifier you used (like maybe 'quaternion'? 'matrix'? 'group'? 'query', to imagine a few). One day you may want to write (as you can in Python) ??? class int(int): ??? ??? ..... to shadow the built-in 'int' type with a modified version.? I'm not suggesting this has many real world applications, but it can be fun to play with.? Python has a "consenting adults" policy: it assumes that if you do something weird, you're doing it deliberately, and it doesn't try to stop you.? I am sure after a little more experience with Python you will remember the commonest built-in types (int, float, list, dict, str etc.). Regards Rob Cliffe From torriem at gmail.com Mon May 24 11:28:02 2021 From: torriem at gmail.com (Michael Torrie) Date: Mon, 24 May 2021 09:28:02 -0600 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: On 5/24/21 8:42 AM, Schachner, Joseph wrote: > OMG that is awful abuse of Python! You have overloaded two Python > keywords by making variables of that name. Nitpick. hw did not overload keywords. Python does not allow keywords to be overloaded. Instead hw overwrote type names. Upon learning that type names are not keywords and can be overwritten, hw aw asked a legitimate question: why does Python allow you to do that? I don't believe the OP found the answer acceptable, though. From rob.cliffe at btinternet.com Mon May 24 12:16:47 2021 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Mon, 24 May 2021 17:16:47 +0100 Subject: learning python ... In-Reply-To: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: Please don't be put off by your experience so far.? Everyone stumbles along the way and runs into "gotchas" when learning a new language.? Python is a fantastic language for development.? One of my early "epiphany" moments was experimenting with different algorithms to try to find the right one for a tricky task.? If I remember rightly it took me about 2 weeks, on and off.? I could never have done it in any flavour of C in 6 months, or at all for that matter.? Python's built-in lists, dictionaries and memory management saved so much donkey work and made it so easy to throw ideas around! Regards Rob Cliffe From contact.tarneo at gmail.com Mon May 24 05:23:20 2021 From: contact.tarneo at gmail.com (max pothier) Date: Mon, 24 May 2021 02:23:20 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <20210522195304.qlq4aot44bs2e5xa@gmail.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <20210524014935.xinvyvf2unq3ltp5@gmail.com> <5a03d59e-dc6c-47b6-ac14-35e26c9c13d0n@googlegroups.com> Message-ID: <5dbfebb3-6139-4df6-a4b2-4dceb1b10710n@googlegroups.com> Ok, So here's a screenshot: https://ibb.co/2dtGr3c 1 is the website's scrollbar and 2 is Firefox's scrollbar. Seems like it uses a strange embed thing. The packet follows: https://pastebin.com/2qEkhZMN @Martin Di Paola: I sent you the pastebin password per email so that you're the only one who can access it, I just don't want anyone who passes by to be able to see my quotes... What is that CSS tag? I could try to disable it in the inspector. From contact.tarneo at gmail.com Mon May 24 05:33:03 2021 From: contact.tarneo at gmail.com (max pothier) Date: Mon, 24 May 2021 02:33:03 -0700 (PDT) Subject: Use Chrome's / Firefox's dev-tools in python In-Reply-To: <5dbfebb3-6139-4df6-a4b2-4dceb1b10710n@googlegroups.com> References: <491394a0-4f90-4f3b-8479-199bdc2abc92n@googlegroups.com> <20210522195304.qlq4aot44bs2e5xa@gmail.com> <644ac9d6-f860-46cf-8573-87b7d4f9c407n@googlegroups.com> <20210524014935.xinvyvf2unq3ltp5@gmail.com> <5a03d59e-dc6c-47b6-ac14-35e26c9c13d0n@googlegroups.com> <5dbfebb3-6139-4df6-a4b2-4dceb1b10710n@googlegroups.com> Message-ID: <14abf9c9-2257-4db2-9240-23ea28ce1fa1n@googlegroups.com> Found this: https://pastebin.com/fvLkSJRp with use-select tags. I'll try to use selenium and select the page. But using the JSON packet that's sent will still be more practical. From alan.gauld at yahoo.co.uk Mon May 24 10:13:07 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Mon, 24 May 2021 15:13:07 +0100 Subject: learning python ... In-Reply-To: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> Message-ID: On 24/05/2021 07:21, hw wrote: >> Inside the function f() the name 'x" shadows the global "x"; references >> to "x" are to the function's local vairable. Which is very desireable. > > If it works that way, I would consider it an entirely different > variable. Remember that in Python variables are just names. They are literally keys to a dictionary and the value that is associated with the name can change. It may be a literal value, a function or a class or a type. Names can be anything that is not a reserved word. (Provided they keep within the naming grammar rules) Also, unlike some other languages, type names are not reserved words. >>>> by naming a variable like a variable type, I would think it is a bad >>>> idea for python to allow this without warning. It does warn you, that's what the message it printed said: print(isinstance(int, float)) TypeError: isinstance() arg 2 must be a type or tuple of types There is only on possible cause for that error. float is not a type or a tuple of types. Therefore you must have changed it somewhere. Since this is the first place in the program that python can identify an error, this is where the message gets printed. You are working in a dynamic language that allows you to do whatever you want to do. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From mstemper at gmail.com Mon May 24 11:54:56 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Mon, 24 May 2021 10:54:56 -0500 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 24/05/2021 09.32, Rob Cliffe wrote: > One day you may want to write (as you can in Python) > > ??? class int(int): > ??? ??? ..... > > to shadow the built-in 'int' type with a modified version.? I'm not > suggesting this has many real world applications, but it can be fun to > play with.? Python has a "consenting adults" policy: it assumes that if > you do something weird, you're doing it deliberately, and it doesn't try > to stop you.? I am sure after a little more experience with Python you > will remember the commonest built-in types (int, float, list, dict, str In my early days of writing python, I created lists named "list", dictionaries named "dict", and strings named "str". I mostly know better now, but sometimes still need to restrain my fingers. -- Michael F. Stemper Nostalgia just ain't what it used to be. From antoon.pardon at rece.vub.ac.be Mon May 24 14:30:59 2021 From: antoon.pardon at rece.vub.ac.be (Antoon Pardon) Date: Mon, 24 May 2021 20:30:59 +0200 Subject: f-strings and internationalisation. Message-ID: <0f9f1d78-4edd-af6f-82bb-4dba96c59326@rece.vub.ac.be> I have now come across several occasion where an author advice the use of f-strings above the %-formatting and the format method. However it seems these authors were only thinking about rather straight forward english communication. So what if you want your application to work with multiple languages. Can that be done with f-strings? -- Antoon Pardon. From grant.b.edwards at gmail.com Mon May 24 14:48:58 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Mon, 24 May 2021 18:48:58 -0000 (UTC) Subject: learning python ... References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 2021-05-24, Dennis Lee Bieber wrote: > Attempting to rebind a keyword in Python will produce an error... > >>>> if = 1.234 > Traceback ( File "", line 1 > if = 1.234 > ^ > SyntaxError: invalid syntax I must admit it might be nice if the compiler told you _why_ the syntax is invalid (e.g. "expected conditional expression while parsing 'if' statement"). It's usually fairly obvious, but... -- Grant From barry at barrys-emacs.org Mon May 24 15:14:07 2021 From: barry at barrys-emacs.org (Barry Scott) Date: Mon, 24 May 2021 20:14:07 +0100 Subject: f-strings and internationalisation. In-Reply-To: <0f9f1d78-4edd-af6f-82bb-4dba96c59326@rece.vub.ac.be> References: <0f9f1d78-4edd-af6f-82bb-4dba96c59326@rece.vub.ac.be> Message-ID: > On 24 May 2021, at 19:30, Antoon Pardon wrote: > > I have now come across several occasion where an author advice the use > of f-strings above the %-formatting and the format method. However it > seems these authors were only thinking about rather straight forward > english communication. > > So what if you want your application to work with multiple languages. > Can that be done with f-strings? No it cannot be done. This is because a translation can reorder the parts of the string is drastic ways that f'strings' does not allow for. You need to use this style: _('This %(arg1)s and %(arg2)s') % {'arg1': value_arg1, 'arg2': value_arg2} or _('This {arg1} and {arg2}').format(arg1=value_args, arg2=values_arg2) A translator would be free to swap arg1 and arg2 order in a translation. See https://docs.python.org/3/library/gettext.html for more details. And https://www.mattlayman.com/blog/2015/i18n/ looks useful as well. Then you can use use the I18N gettext tools to make a .pot and .po files. Barry > > -- > Antoon Pardon. > -- > https://mail.python.org/mailman/listinfo/python-list > From tjreedy at udel.edu Mon May 24 15:37:29 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 24 May 2021 15:37:29 -0400 Subject: Question for potential python development contributions on Windows In-Reply-To: References: <000001d74fef$7d0051f0$7700f5d0$@earthlink.net> Message-ID: On 5/23/2021 10:05 PM, Terry Reedy wrote: > On 5/23/2021 12:20 PM, pjfarley3 at earthlink.net wrote: >> I asked this question on python-dev last week but did not get an >> answer.? If >> anyone here know the answer I would appreciate it. >> >> The Python Developers Guide specifically states to get VS2017 for >> developing >> or enhancing python on a Windows system. >> >> Is it still correct to specifically use VS2017 , or is VS2019 also >> acceptable? pjfarley just got answers on pydev. For anyone else, they are no, not only VS2017, and yes, VS2019 is fine. The same will be true of a possible VS2021 as long as the compiler version remain 14.something. -- Terry Jan Reedy From cs at cskk.id.au Mon May 24 17:27:01 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Tue, 25 May 2021 07:27:01 +1000 Subject: learning python ... In-Reply-To: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 24May2021 16:17, hw wrote: >On 5/24/21 11:33 AM, Cameron Simpson wrote: >>Note that in this function: >> >> x = 1 >> y = 2 >> >> def f(a): >> x = 3 >> print(x, y) >> >>"x" is local, because the function contains an assignment to it. "y" >>comes from an outer scope (in this case, the global scope) because >>there's no assignment to it. > >Thanks! That basically works the same as in perl then. ISTR that Perl needed me to declare locals with my(). Locals are deduced from the code in Python. >>>>As Stestagg has mentioned, there are also tools called linters which >>>>warn you about issues like this. Tools like pyflakes, pylint, >>>>pycodestyle all inspect your code for a wide variety of potential errors >>>>and discouraged habits. Not to mention tools like mypy which do type >>>>validation. >>> >>>So you're saying one can't really go without those unless you want to >>>take the risk? >> >>Self restraint and developing good habits does 99% of the work. Linters >>are great for catching various accidents. > >I never needed one before. I programmed for years in Python (and Perl etc etc) without bothing with linters. As I said, 99% of the work can be achieved with a loittle self discipline. But linters are good for catching mistakes - computers don't get bored. And they can also catch things you weren't considering. I used to use lint in C and liked the attention to tedious detail. So for my environment I wrote myself a "lint" script which runs the linters I like with the options I like, and linting is now an easy step that I perform at my choosing (generally post bug fixing or feature implementing). >>[...] >>>I'm not saying it shouldn't be allowed to defeat or to re-define stuff, >>>only that it shouldn't go through quietly. >> >>Well, most of us use linters to exhibit that noise, rather than >>requiring the code to be littered with special directives. >> >>I usually code without much linter fuss until I've got the latest batch >>of work (eg feature or fix) ready, commit the changes, then lint >>vigorously and commit that polish before merging with the main line of >>code. > >Maybe python requires a different approach than other languages in >that it doesn't allow for the overhead that can be used to make things >easy to read and without guessing in other languages. That overhead >can be a disadvantage, yet getting to used to not having it could take >a while. The approach isn't required. I find the approach useful to me. >>Finally, consider this code: >> >> num = input("Enter a number: ") >> num = int(num) >> >>input() returns a string, which would need converting to a number before >>some numeric stuff. Plenty of people write the above. To my mind, this >>is also a kind of shadowing, and I like this instead: >> >> num_s = input("Enter a number: ") >> num = int(num_s) >> >>where the "_s" indicates quietly that this variable holds a string. > >Isn't that a kind of overhead python is trying to avoid? It's a style or work practice of my own choosing. Python itself is happy with either code. >>Is that shadowing to your mind? Or not? If yes, should the language emit >>noise there, too? Remembering that Python _values_ are strongly typed, >>though the variables are not (a variable might reference any kind of >>object, as above). > >No, I don't see any shadowing in either example. In the first one, >you (seem to) make sure that you get an integer (not considering what >happens when the input is not something that can be cast into an >integer) using the same variable by altering its contents. > >In the second example, you're using two different variables, trying to >cast the first one to an integer while assigning it to a second one >which is implicitly declared. > >If anything, I could argue that this is convoluted code because you're >doing lots of stuff implicitly --- and that could be argued for both >examples. You could make it worse like > > if(int(num = input("foo: ")) == 5): > pass > >involving side effects, but I don't know if python would allow you to >do that. (Not that I would want to do something like this, but it >would make sense to me if it could be done ...) > >>I wouldn't say that your opinion would be wrong regardless of what side >>of this question you come down on, but Python's chosen a side: noise for >>nonsensical things, but not noise for dubious things. But plenty of >>linters to complain about dubious things. > >What does python actually do in the first example? Does it overshadow >a variable or does it change one? If it overshadows a variable, it >would be dubious, if it doesn't, it won't be dubious. Variables are just names which reference objects. The first example causes "num" to reference the string returned by input(), then it causes "num" to reference the int returned by int(). If you think of them like C pointers the analogy works well. They're not pointers (i.e. they're not memory addresses and you can't do arithmetic with the addresses), but they are references. >There are more alternatives: Python might create a new variable with >the same name and forget about the old one. Or it doesn't forget >about the old one and the old one becomes inaccessible (unless you >have a reference to it, if there is such a thing in python). How do >you call that? Dunno, because that's not what happens. You're conflating values (objects, such as an int or a string) with variables (which _are_ references in Python, as opposed to named storage in some other languages). Maybe you should give the Language Reference a read: https://docs.python.org/3/reference/index.html Cheers, Cameron Simpson From greg.ewing at canterbury.ac.nz Mon May 24 18:37:07 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 25 May 2021 10:37:07 +1200 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 25/05/21 9:27 am, Cameron Simpson wrote: > On 24May2021 16:17, hw wrote: > >> Or it doesn't forget >> about the old one and the old one becomes inaccessible (unless you >> have a reference to it, if there is such a thing in python). How do >> you call that? > > You're conflating values > (objects, such as an int or a string) with variables (which _are_ > references in Python, I think hw might have meant the C++ notion of a reference to a *variable*. There is no equivalent of that in Python. Python does have references to *objects*. All objects live on the heap and are kept alive as long as there is at least one reference to them. If you rebind a name, and it held the last reference to an object, there is no way to get that object back. On the other hand, if you shadow a name, the original name still exists, and there is usually some way to get at it, e.g. >>> int = 42 >>> int 42 >>> __builtins__.int >>> -- Greg From drsalists at gmail.com Mon May 24 19:27:08 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Mon, 24 May 2021 16:27:08 -0700 Subject: learning python ... In-Reply-To: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> Message-ID: On Sun, May 23, 2021 at 12:35 PM hw wrote: > I don't know about shadowing. If I have defeated a whole variable type > by naming a variable like a variable type, I would think it is a bad > idea for python to allow this without warning. It seems like a recipie > for creating chaos. > It strikes me as a pretty natural consequence of types being first class objects in Python. There's a little unlearning to do if you're coming from a more traditional language, but it's not difficult once you know how Python does its thing. Have you ever tried to put int (not an int, the type int) in a variable in C? You can sort of do it with the C PreProcessor, but that's always been a bit of a kludge. IOW, in Python everything is an object. From alan.gauld at yahoo.co.uk Mon May 24 19:30:23 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Tue, 25 May 2021 00:30:23 +0100 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 24/05/2021 16:54, Michael F. Stemper wrote: > In my early days of writing python, I created lists named "list", > dictionaries named "dict", and strings named "str". I mostly know better > now, but sometimes still need to restrain my fingers. I think most newbie programmers make that mistake. I certainly did when learning Pascal back in the 80's. But I was lucky, the tutorials were run by a guy who penalized bad variable names severely and took a half-mark off for every bad name. We very quickly learned to choose names that were descriptive of the purpose rather than the type. Its a lesson that I've never forgotten! -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From pjfarley3 at earthlink.net Mon May 24 20:02:56 2021 From: pjfarley3 at earthlink.net (pjfarley3 at earthlink.net) Date: Mon, 24 May 2021 20:02:56 -0400 Subject: Question for potential python development contributions on Windows In-Reply-To: References: <000001d74fef$7d0051f0$7700f5d0$@earthlink.net> Message-ID: <00a301d750f9$512c1040$f38430c0$@earthlink.net> > -----Original Message----- > From: Terry Reedy > Sent: Sunday, May 23, 2021 10:05 PM > To: python-list at python.org > Subject: Re: Question for potential python development contributions on > Windows > I am pretty sure that VS2019 output is binary compatible with with output from > VS2017 and VS2015. I believe the only issue would be is one were developing a > patch to a CPython .c file and one used recent C## features not allowed in > CPython code. > > You could open an issue on bugs.python.org asking that the doc be clarified. I have received several positive answers on the python-dev list since I posted the question here. The answer is yes, VS2019 and all VS20xx releases since VS2015 are correct to use for Windows contributions until MS changes the binary C/C++ ABI, currently at level V14x. The core dev's have indicated that the Python Development Guide documentation needs updating to reflect this fact. Peter From alan.gauld at yahoo.co.uk Mon May 24 19:36:41 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Tue, 25 May 2021 00:36:41 +0100 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 24/05/2021 19:48, Grant Edwards wrote: >> Traceback ( File "", line 1 >> if = 1.234 >> ^ >> SyntaxError: invalid syntax > > I must admit it might be nice if the compiler told you _why_ the > syntax is invalid (e.g. "expected conditional expression while parsing > 'if' statement"). Although wouldn't it be "expected boolean expression" rather than conditional expression? Python doesn't care how the argument to 'if' is arrived at so long as it's a boolean. And with assignment expressions, conditional expressions and literals all possible unambiguous error messages get harder and harder to figure out. But I do accept the general point that slightly more information about syntax errors would be nice. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From jon+usenet at unequivocal.eu Mon May 24 19:41:55 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Mon, 24 May 2021 23:41:55 -0000 (UTC) Subject: learning python ... References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 2021-05-24, Alan Gauld wrote: > On 24/05/2021 16:54, Michael F. Stemper wrote: > >> In my early days of writing python, I created lists named "list", >> dictionaries named "dict", and strings named "str". I mostly know better >> now, but sometimes still need to restrain my fingers. > > I think most newbie programmers make that mistake. I certainly > did when learning Pascal back in the 80's. > > But I was lucky, the tutorials were run by a guy who penalized > bad variable names severely and took a half-mark off for every > bad name. We very quickly learned to choose names that were > descriptive of the purpose rather than the type. Tricky when you're writing general utility functions. What would you call the argument to a function that returns, say, an upper-cased version of its input? (Pretending for a moment that Python didn't already have such a function built-in ;-) ) I mean, sure, you could call it "inputString" or something but that sort of thing gets annoyingly verbose very quickly. If you're using type annotations then "input: str" would be ok but if you're not then just "input" is overly opaque (not to mention shadowing a builtin). This is why it's good when languages have conventions like "types and classes start with an upper-case letter", so that you can do "string = String()" without problems... From hw at adminart.net Mon May 24 22:59:19 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 04:59:19 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> On 5/24/21 3:54 PM, Chris Angelico wrote: > On Mon, May 24, 2021 at 11:35 PM hw wrote: >> >> On 5/24/21 9:52 AM, Chris Angelico wrote: >>> Does C give you a warning if you create a function-local variable >>> called "printf"? No, and it shouldn't. Does any other language >>> complain if you use its scoping rules to reuse a name? Nope. Does >>> Python? As above, no. >> >> Try the equivalent of above python in C: >> >> >> void foo(void) { >> int int = 25; >> printf("int: %d\n", int); >> } >> >> int main(int argc, char **argv) { >> foo(); >> } > > I did specifically mention "printf", which works just fine, as you see below. see below >> I don't know which C compiler you're using; gcc doesn't compile this and >> gives several error messages. Python quietly allows things like this >> without any warning at all, and I'm saying that's a bad thing and that >> python seems unfinished because it doesn't even give a warning in cases >> like this. > > You keep using that word "unfinished". I do not think it means what > you think it does. What do you think I think it means? > Python has keywords. C has keywords. In Python, "None" is a keyword, > so you can't assign to it; in C, "int" is a keyword, so you can't > assign to it. There is no fundamental difference here, and the two > languages even have roughly the same number of keywords (35 in current > versions of Python; about 40 or 50 in C, depending on the exact > specification you're targeting). The only difference is that, in > Python, type names aren't keywords. You're getting caught up on a > trivial difference that has happened to break one particular test that > you did, and that's all. Then what is 'float' in the case of isinstance() as the second parameter, and why can't python figure out what 'float' refers to in this case? Perhaps type names should be keywords to avoid confusion. >> I don't know REXX, and I'm not sure what the equivalent would be in >> elisp. The issue doesn't exist in perl. It may be intentionally so >> that python makes it easy to defeat fundamental aspects of the language >> simply by, accidentially or intentionally, re-defining them without >> warning, and even if that is so, nobody else has to like a feature like >> that just because you do like it. > > REXX doesn't have keywords at all. (It has language syntax words, but > everything is contextual, so you can quite happily say "if = 1" and > then "if if" becomes valid.) Perl has keywords, just like everything > else, but not for data types. > > This is NOT something fundamental to the language that is "defeated". > You have made it harder to perform isinstance checks, but that's > neither fundamental nor defeated by this shadowing. The integer type > still exists - you just made a new variable with the name "int". The > float type still exists - you just made a new variable with the name > "float". Ok, that is an important difference. >> Maybe you can show how this is a likeable feature. I already understood >> that you can somehow re-define functions in python and I can see how >> that can be useful. You can do things like that in elisp as well. But >> easily messing up built-in variable types like that is something else. >> Why would I want that in a programming language, and why would I want to >> use one that allows it? > > Because all you did was mess with the *name* of the type. It's not > breaking the type system at all. And how is it a likeable feature? > Most Python programs manage just fine > without ever doing an isinstance check, and even if you do have to, > it's possible to refer to the type in other ways: > >>>> (1).__class__ > > >>>> int = 42 >>>> isinstance(int, (1).__class__) > True > > See? Not broken. All you did was change the meaning of the name "int", > by assigning to it. No, but I take your word for it. >> Your claim that I'm insulting python or anoyone is ridiculous. >> According to your logic, C is insulting python. I suggest you stop >> making assumptions. > > The C language never says that Python is "unfinished". I'm not making > assumptions, I'm reading your posts. I never said it is unfinished, I said it /seems/ unfinished. In any case, there is nothing insulting about it. Python is still being worked on (which is probably a good thing), and the switch from version 2 to version 3 has broken a lot of software, which doesn't help in making it appear as finished or mature. >> The example you want is probably this one: >> >> >> #include >> >> void foo(void) { >> int printf = 25; >> printf("int: %d\n", printf); >> } >> >> int main(int argc, char **argv) { >> foo(); >> } >> >> >> Perhaps you can't see how both examples are different because you're >> looking at things from a python perspective. > > Well, look at them from a language design perspective and tell me how > different they really are. Just look at what the compiler says when you try to compile these examples. In the first example, you can't defeat a built-in data type by assigning something to it, and in the second one, you declare something as an instance of a build-in data type and then try to use it as a function. That is so because the language is designed as it is. And if you want to compare that to python, C is entirely clear in both examples while python is anything but clear. This makes me wonder if people are using external tools for python to discover ambiguities because python is not as easy and clear to read as the designers intended. Maybe at the end of the day, the good intentions aren't working to the benefit of the programmer as much as it would seem at first. Maybe they work better for everyone else who reads a program, after the programmer has worked things out. From hw at adminart.net Mon May 24 23:09:16 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 05:09:16 +0200 Subject: learning python ... In-Reply-To: <75e7d97b-df0e-d4f9-b640-73aa20ae0d52@gmail.com> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2bd5da94-e585-5992-8f96-cb8a5157793b@gmail.com> <75e7d97b-df0e-d4f9-b640-73aa20ae0d52@gmail.com> Message-ID: <89a8e997-a249-9a63-cddb-8b894263216c@adminart.net> On 5/24/21 4:41 PM, Michael Torrie wrote: > On 5/24/21 8:21 AM, Michael Torrie wrote: >> Given your posts thus far, hw, I don't think Python is a good fit for >> you. You're better off learning a language that more closely aligns with >> the statically-typed languages you already know. Maybe it is, maybe it isn't; I've been thinking about it for a while now. > That was unnecessarily harsh; my apologies. I can see now that you > might be comparing some features to Perl, which is a more dynamic > language. I see in your recent posts that you are trying to understand > how Python works, and that is good. Hopefully you'll find Python a > dynamic and useful tool. If not, that's perfectly okay. Use the right > tool for the job. > That's what I'm trying to do. I'm just using a particular problem I want to solve as an occassion to maybe learn python because it seems much easier to solve in python than in perl. From hw at adminart.net Mon May 24 23:20:37 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 05:20:37 +0200 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> Message-ID: On 5/24/21 4:37 PM, Chris Angelico wrote: > On Tue, May 25, 2021 at 12:31 AM Michael Torrie wrote: >> >> On 5/24/21 8:24 AM, Chris Angelico wrote: >>> On Tue, May 25, 2021 at 12:18 AM hw wrote: >>>> There are more alternatives: Python might create a new variable with >>>> the same name and forget about the old one. Or it doesn't forget about >>>> the old one and the old one becomes inaccessible (unless you have a >>>> reference to it, if there is such a thing in python). How do you call that? >>> >>> It's the latter option: create a new variable, and the old one becomes >>> inaccessible. That's called "shadowing". It's how scoping works in >>> most languages (called "lexical scope"). >> >> Is it really shadowing, though? The old one is not only inaccessible, >> it's possibly reaped by the garbage collector, no? Both nums are in the >> same scope so the one overwrote the other in the name table. Or am I >> missing something. >> > > We're talking about many different things. If it's simply "num = ..." > followed by "num = ...", then it's not a new variable or anything, > it's simply rebinding the same name. But when you do "int = ...", it's > shadowing the builtin name. Why? And how is that "shadowing"? What if I wanted to re-define the built-in thing? From hw at adminart.net Mon May 24 23:53:27 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 05:53:27 +0200 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 5/24/21 4:28 PM, Michael Torrie wrote: > On 5/24/21 8:17 AM, hw wrote: >> What does python actually do in the first example? Does it overshadow a >> variable or does it change one? If it overshadows a variable, it would >> be dubious, if it doesn't, it won't be dubious. > > Are you referring to this? > > num = input("Enter a number: ") > num = int(num) yes > No it is not "overshadowing" a variable. You cannot get back to the > original string value for num. So the other example that uses a second variable to avoid possible ambiguity could be considered as bloating because it keeps both variables around. >> There are more alternatives: Python might create a new variable with >> the same name and forget about the old one. Or it doesn't forget about >> the old one and the old one becomes inaccessible (unless you have a >> reference to it, if there is such a thing in python). How do you call that? > > Python variables are not memory boxes like in a compiled language. They > are names bound to objects, as Mr Simpson alluded to. That seems like an important distinction. I've always been thinking of variables that get something assigned to them, not as something that is being assigned to something. > So in the first > line, the name num is bound to a string. In the second line, the name > is re-bound to an int object. I would think of it as assigning a string to a variable and then changing the content of the variable by assigning something else to the same variable. When variables are typeless, it doesn't matter if a string or an integer is assigned to one (which is weird but can be very useful). It seems much more practical to assign different strings to the same variable rather than assigning a different variable to each string, or to assign a string to a variable and then to assign an integer to it. Isn't that what variables are for? > Furthermore, if num had come from the > global name scope, either of these lines would create a local name num > that does shadow the name from the global scope. > > Hope that helps. > > Yes, I guess it will be interesting not to think of variables but of objects. From hw at adminart.net Tue May 25 00:08:57 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 06:08:57 +0200 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 5/25/21 12:37 AM, Greg Ewing wrote: > On 25/05/21 9:27 am, Cameron Simpson wrote: >> On 24May2021 16:17, hw wrote: > > >>> Or it doesn't forget >>> about the old one and the old one becomes inaccessible (unless you >>> have a reference to it, if there is such a thing in python).? How do >>> you call that? >> >> You're conflating values >> (objects, such as an int or a string) with variables (which _are_ >> references in Python, > > I think hw might have meant the C++ notion of a reference to > a *variable*. There is no equivalent of that in Python. yes, or a reference in perl > Python does have references to *objects*. All objects live on > the heap and are kept alive as long as there is at least one > reference to them. > > If you rebind a name, and it held the last reference to an > object, there is no way to get that object back. Are all names references? When I pass a name as a parameter to a function, does the object the name is referring to, when altered by the function, still appear altered after the function has returned? I wouldn't expect that ... > On the other hand, if you shadow a name, the original name > still exists, and there is usually some way to get at it, > e.g. > > >>> int = 42 > >>> int > 42 > >>> __builtins__.int > > >>> > You mean built-in objects never go away, even when they are no longer referenced? From cs at cskk.id.au Tue May 25 00:22:06 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Tue, 25 May 2021 14:22:06 +1000 Subject: learning python ... In-Reply-To: References: Message-ID: On 25May2021 05:53, hw wrote: >That seems like an important distinction. I've always been thinking of >variables that get something assigned to them, not as something that is >being assigned to something. They are what you thought. But it's references to objects what are being passed around. C is a deliberately "close to the machine" language, and things a CPU can store in a register are natural types (ints of various sizes, etc). But consider a C string: char *s = "foo"; The compiler here allocates some char storage, puts "foo\0" in it, and puts a reference in "s". char *t = strcpy(s) char *t2; t2 = s; t2 = t; Here "s", "t" and "t2" are all of type (char*), and store references. When you pass "s" or "t" around, eg as above in an assignment, or when you pass it to a function, you're not copying the storage, just the reference. Same with Python, except that all the basic types like int and float are also done with references. Cheers, Cameron Simpson From cs at cskk.id.au Tue May 25 00:15:41 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Tue, 25 May 2021 14:15:41 +1000 Subject: learning python ... In-Reply-To: References: Message-ID: On 25May2021 06:08, hw wrote: >On 5/25/21 12:37 AM, Greg Ewing wrote: >>If you rebind a name, and it held the last reference to an >>object, there is no way to get that object back. > >Are all names references? Yes. >When I pass a name as a parameter to a function, does the object the >name is referring to, when altered by the function, still appear >altered after the function has returned? I wouldn't expect that ... Yes. Please ready the language specification. This is basic to Python's function. >>On the other hand, if you shadow a name, the original name >>still exists, and there is usually some way to get at it, >>e.g. >> >> >>> int = 42 >> >>> int >>42 >> >>> __builtins__.int >> >> >>> >> > >You mean built-in objects never go away, even when they are no longer >referenced? Well, the builtins module itself has a reference. But what greg's showing you above it the "int" class/type. You've got an in in play in the code above - the class will of course exist. But the builtin classes (and other names) always exist because they're built in. Cheers, Cameron Simpson From avigross at verizon.net Tue May 25 01:56:31 2021 From: avigross at verizon.net (Avi Gross) Date: Tue, 25 May 2021 01:56:31 -0400 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> Message-ID: <01b701d7512a$b689cf00$239d6d00$@verizon.net> I have studied many programming languages and am amused when people attack python as if every other language is somehow more optimal. Cameron and others have provided examples but look at positives AND negatives. Yes code like: num = int(num) does look a tad off as it reuses the same name for something that is actually in many ways different. You could easily use a new name. But then you would have TWO variables in your name space and the old one would not be garbage collected unless you explicitly removed it. If you follow this path, would you suggest not writing: X = X + 1 either? It is actually a fairly common practice in many languages to have code like this: Var = read in something from a file and make some structure like a data.frame Var = remove some columns from the above thing pointed to by Var Var = make some new calculated columns ditto Var = remove some rows ... Var = set some kind of grouping on the above or sort it and so on. As you go along you may keep transforming but have no need for earlier results, just the new and improved one. So why keep changing names? Some languages support not having any names for intermediate results by using nested function calls or pipelines. The reality is that most languages have a series of what I loosely would call environments or name tables and as they run, new ones regularly get created and removed and even the order of them may change. The algorithm for searching for a name varies and can be in some sense linear or more complex. When looking in context for a function name, you may follow a different trail or the same one as for a variable holding a string and in some implementations the same name shadows and in others does not. Wait till you try to figure out the diamond pattern of inheritance when you create classes that depend on multiple other classes ad nauseum and you try to call a method and it tries to find the one you wanted by searching backwards in an interesting way. Many other languages decided to just not allow multiple inheritance! How can you write a recursive function without this kind of variable shadowing? Each invocation of a function places the internal namespace in front of the parent so the meaning of a variable name used within is always backed by all the iterations before it. But with some kinds of closures, a function may be gone and yet variables it had within it persists. Lots of odd examples more make this a complex set of CHOICES. So what if you suggest we allow re-use of names but WARN you. OK, Python is a largely interpreted language. Normally if you ask to use a variable called X, it starts a search in the nearest place then the next one and so on till it finds it or fails. In many programs, variables are fairly local and found easily. But if you want, you can search dozens or hundreds of places and find each and every use of X visible at THIS moment and tell the user there are 82 places it can be seen and here they are. Now what? The first 50 places may be in other instances of the recursive function and you have already been warned this way 49 times and soon will be warned a few more as it continues to recurse as it travels down a tree or graph structure quite legitimately. Some of the other places X may be in use are in some package in a part you are not even using indirectly or in middle of a for-loop as a token variable and so on. I suspect that 99.99% of the time re-using a name has no negative consequence. Making someone keep choosing names like X12346 because there is somewhere an X12345 seems a tad silly. But why go to all that expense at run-time versus in some lint program? I recently studied a language called GO that goes to some length to protect the user from themselves and often at great expense to getting programming done. It won't compile a program if it declares a variable and does not use it. Fair enough but I often want to write a sort of shell of a program and check as I go to make sure it works before adding more. If I will need 5 variables, I might declare them up-front then work on interactions and calculations that only include some of them and later I plan on connecting the rest. Nope, it won't let me unless I use it as in a print statement or comment it out or just remove it. Ah, but then it is not happy I did not initialize it so I set it to zero or something. Later, when I finally use it as intended, I need to remove the junk. Some of this annoyance is so common that they had to come up with a way to shut it up. Consider this line: Result, err = functionA(args) It returns two arguments. Sometimes it seems silly to worry about the error but you MUST write a line of code like: If (err != nil) { Do_something } Other times you just care if it worked and don't want the result. So placing an _ for one or the other is a signal to shut the darn compiler up that you are DELIBERATELY ignoring the return value you did not want! There are many other places the darn thing tries to protect you and insists you write code the hard way. Some are not unreasonable and some I argue are. Their method of trapping errors deliberately chose to not do the fairly common try/catch method lest it make programmers stop worrying about causing a panic, for example, or even depending on it. Their switch statement does not flow through to the next item because they worry people might forget the break statement so instead, they have a way to specify when you want execution to fall through. This last one is an example maybe of something more reasonable. So, yes, there are languages with philosophies that may help users avoid some common mistakes. Use them if you wish. But some of these have a longer learning curve and generate lots of frustration and may make some people stop learning to program because it takes forever to get something to compile, let alone run. In my experience, often the work-around they supply to do things is far more complex than just providing some freedom and hoping you do not abuse it. In interpreted languages, you can really do some weird things if you know more, including access to the actual names of variables and the ability to change them on the fly and so on and yes, the ability to make weird mistakes. There can be a happy medium. Supply a function call a user can place anywhere in the code that asks if there is an "X" defined at this point in time before they use it. And, if there is, tell me about all of them as in if I remove one X, is there now another. But will that work the way you want so you can choose another name if that bothers you? My guess is no. The same function containing your test might be called from somewhere else in your code and there is does mask something or is masked deeper. You may be using modules that change with some new release and have variables that now conflict with yours. Some identifiers are so common that the order you load packages/modules may determine which one is uppermost. I often program in R and I do get messages when say a function called select() in package B is loaded and shadow the same name in package A or the base. If it matters, I am free to call A::select() or B::select so the names no longer clash at that point or I use other techniques. So dynamic changes as packages are updated are possible even if my lint method once declared things to be fine. So should we force people to use fully qualified names like the above or worse? Python is not perfect, Frankly, a good chunk of the features in python added to it as an interpreted language seem to work pretty well in various compiled languages I have studied. Many features do not require the interpreter and can now be done in other ways. Designers make choices and some are a matter of taste. Arguably Python is best for things like prototyping or even learning but arguably it is not as efficient for programs that run fairly simple algorithms constantly where running faster or using less memory can mean major savings. So, yes, often a program written in Python and shown to work, may be rewritten. But the opposite can be true as people give up trying to use a restrictive environment when the needs keep changing and a more flexible scripting language allows rapid changes. Python is not designed or planned the way some want and if that bothers them, use something else when told by others that the language was designed to do what it is supposed to and needs no change. On another forum someone is asking for R to not have just an NA variable when something is missing, but as many variants as needed to record why it is missing such as ILLEGIBLE or DELAYED or RAN_OUT_OF_TIME and so on. The claim is that many social science applications need this and some other programs/languages sort of support it. Fair enough but again, the design way-back-when saw no need for this and lots of drawbacks and although we brainstormed lots of ideas on how to attach metadata to a vector to support this, it often breaks down as most existing functions toss it away so you may have to redo tons of code very carefully to preserve the data or even reapply it after a change. Something as simple as converting a vector from character strings to their integer values will drop the changes. So, again, if this is that important, use something else and do NOT suggest diddling with unused bits in one implementation of NA to store your additional metadata as there is no guarantee it will get the result you want and it is not a documented guaranteed implementation and may break lots of other existing code. I am not discouraging anyone from asking questions and even suggesting changes. I simply suggest when others push back and tell you it was designed this way for darn good reasons and many LIKE IT the way it is, ... -----Original Message----- From: Python-list On Behalf Of Cameron Simpson Sent: Monday, May 24, 2021 5:34 AM To: python-list at python.org Subject: Re: learning python ... On 24May2021 08:21, hw wrote: >On 5/24/21 12:03 AM, Cameron Simpson wrote: >>On 23May2021 21:02, Stestagg wrote: >>>On Sun, 23 May 2021 at 20:37, hw wrote: >>>>I don't know about shadowing. >>> >>>Shadowing is effectively saying ?within this bit of code, (scope) I?m >>>going to use an already-used name for my own value? >> >>An example might make this clearer: >> >> x = 1 # global variable >> >> def f(a): >> x = a * 2 >> return x >> >>Inside the function f() the name 'x" shadows the global "x"; >>references to "x" are to the function's local vairable. Which is very desireable. > >If it works that way, I would consider it an entirely different >variable. Is there a way to access the global x from within a function >without transferring it through parameters of the function? >Than can also sometimes be useful. Sure. You can declare a name like this: def f(a): global x # find x in the global namespace (the module) x = a * 2 return x This is pretty rare and usually discouraged. Of there are times when it is useful. Note that in this function: x = 1 y = 2 def f(a): x = 3 print(x, y) "x" is local, because the function contains an assignment to it. "y" comes from an outer scope (in this case, the global scope) because there's no assignment to it. >>As Stestagg has mentioned, there are also tools called linters which >>warn you about issues like this. Tools like pyflakes, pylint, >>pycodestyle all inspect your code for a wide variety of potential >>errors and discouraged habits. Not to mention tools like mypy which >>do type validation. > >So you're saying one can't really go without those unless you want to >take the risk? Self restraint and developing good habits does 99% of the work. Linters are great for catching various accidents. [...] >I'm not saying it shouldn't be allowed to defeat or to re-define stuff, >only that it shouldn't go through quietly. Well, most of us use linters to exhibit that noise, rather than requiring the code to be littered with special directives. I usually code without much linter fuss until I've got the latest batch of work (eg feature or fix) ready, commit the changes, then lint vigorously and commit that polish before merging with the main line of code. Finally, consider this code: num = input("Enter a number: ") num = int(num) input() returns a string, which would need converting to a number before some numeric stuff. Plenty of people write the above. To my mind, this is also a kind of shadowing, and I like this instead: num_s = input("Enter a number: ") num = int(num_s) where the "_s" indicates quietly that this variable holds a string. Is that shadowing to your mind? Or not? If yes, should the language emit noise there, too? Remembering that Python _values_ are strongly typed, though the variables are not (a variable might reference any kind of object, as above). I wouldn't say that your opinion would be wrong regardless of what side of this question you come down on, but Python's chosen a side: noise for nonsensical things, but not noise for dubious things. But plenty of linters to complain about dubious things. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list From hw at adminart.net Tue May 25 04:23:41 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 10:23:41 +0200 Subject: imaplib: is this really so unwieldy? Message-ID: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Hi, I'm about to do stuff with emails on an IMAP server and wrote a program using imaplib which, so far, gets the UIDs of the messages in the inbox: #!/usr/bin/python import imaplib import re imapsession = imaplib.IMAP4_SSL('imap.example.com', port = 993) status, data = imapsession.login('user', 'password') if status != 'OK': print('Login failed') exit messages = imapsession.select(mailbox = 'INBOX', readonly = True) typ, msgnums = imapsession.search(None, 'ALL') message_uuids = [] for number in str(msgnums)[3:-2].split(): status, data = imapsession.fetch(number, '(UID)') if status == 'OK': match = re.match('.*\(UID (\d+)\)', str(data)) message_uuids.append(match.group(1)) for uid in message_uuids: print('UID %5s' % uid) imapsession.close() imapsession.logout() It's working (with Cyrus), but I have the feeling I'm doing it all wrong because it seems so unwieldy. Apparently the functions of imaplib return some kind of bytes while expecting strings as arguments, like message numbers must be strings. The documentation doesn't seem to say if message UIDs are supposed to be integers or strings. So I'm forced to convert stuff from bytes to strings (which is weird because bytes are bytes) and to use regular expressions to extract the message-uids from what the functions return (which I shouldn't have to because when I'm asking a function to give me a uid, I expect it to return a uid). This so totally awkward and unwieldy and involves so much overhead that I must be doing this wrong. But am I? How would I do this right? From rosuav at gmail.com Tue May 25 04:32:21 2021 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 25 May 2021 18:32:21 +1000 Subject: learning python ... In-Reply-To: <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> Message-ID: On Tue, May 25, 2021 at 1:00 PM hw wrote: > > On 5/24/21 3:54 PM, Chris Angelico wrote: > > You keep using that word "unfinished". I do not think it means what > > you think it does. > > What do you think I think it means? I think it means that the language is half way through development, doesn't have enough features to be usable, isn't reliable enough for production, and might at some point in the future become ready to use. None of which is even slightly supported by evidence. > > Python has keywords. C has keywords. In Python, "None" is a keyword, > > so you can't assign to it; in C, "int" is a keyword, so you can't > > assign to it. There is no fundamental difference here, and the two > > languages even have roughly the same number of keywords (35 in current > > versions of Python; about 40 or 50 in C, depending on the exact > > specification you're targeting). The only difference is that, in > > Python, type names aren't keywords. You're getting caught up on a > > trivial difference that has happened to break one particular test that > > you did, and that's all. > > Then what is 'float' in the case of isinstance() as the second > parameter, and why can't python figure out what 'float' refers to in > this case? Perhaps type names should be keywords to avoid confusion. It's a name. In Python, any name reference is just a name reference. There's no magic about the language "knowing" that the isinstance() function should take a keyword, especially since there's no keywords for these things. > >> Maybe you can show how this is a likeable feature. I already understood > >> that you can somehow re-define functions in python and I can see how > >> that can be useful. You can do things like that in elisp as well. But > >> easily messing up built-in variable types like that is something else. > >> Why would I want that in a programming language, and why would I want to > >> use one that allows it? > > > > Because all you did was mess with the *name* of the type. It's not > > breaking the type system at all. > > And how is it a likeable feature? You can complain about whether it's likeable or not, but all you're doing is demonstrating the Blub Paradox. > > The C language never says that Python is "unfinished". I'm not making > > assumptions, I'm reading your posts. > > I never said it is unfinished, I said it /seems/ unfinished. In any > case, there is nothing insulting about it. Python is still being worked > on (which is probably a good thing), and the switch from version 2 to > version 3 has broken a lot of software, which doesn't help in making it > appear as finished or mature. It's been around for thirty years. Quit fudding. You're getting very close to my killfile. Python 3 has been around since 2009. Are you really telling me that Python looks unfinished because of a breaking change more than a decade ago? The Go language didn't even *exist* before Python 3 - does that mean that Go is also unfinished? > Just look at what the compiler says when you try to compile these > examples. In the first example, you can't defeat a built-in data type > by assigning something to it, and in the second one, you declare > something as an instance of a build-in data type and then try to use it > as a function. That is so because the language is designed as it is. Yes, because C uses keywords for types. That's the only difference you're seeing here. You keep getting caught up on this one thing, one phenomenon that comes about because of YOUR expectations that Python and C should behave the same way. If you weren't doing isinstance checks, you wouldn't even have noticed this! It is *NOT* a fundamental difference. Also, you keep arguing against the language, instead of just using it the way it is. It really sounds to me like you'd do better to just give up on Python and go use some language that fits your brain better. If you won't learn how a language works, it's not going to work well for you. ChrisA From __peter__ at web.de Tue May 25 05:46:31 2021 From: __peter__ at web.de (Peter Otten) Date: Tue, 25 May 2021 11:46:31 +0200 Subject: Shadowing, was Re: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> <9121937f-6364-a309-dbe7-3fd0ee117aa0@gmail.com> Message-ID: On 25/05/2021 05:20, hw wrote: >> We're talking about many different things. If it's simply "num = ..." >> followed by "num = ...", then it's not a new variable or anything, >> it's simply rebinding the same name. But when you do "int = ...", it's >> shadowing the builtin name. > > Why?? And how is that "shadowing"? > > What if I wanted to re-define the built-in thing? When you write foo in a module the name "foo" is looked up in the module's global namespace. If it's not found it is looked up in builtins. If that lookup fails a NameError exception is raised. >>> import builtins >>> builtins.foo = "built-in foo" >>> foo 'built-in foo' >>> foo = "module-global-foo" # at this point builtins.foo is shadowed >>> foo 'module-global-foo' >>> del foo # delete the global to make the built-in visible again: >>> foo 'built-in foo' That mechanism allows newbies who don't know the builtins to write list = [1, 2, 3] without affecting other modules they may use. It also allows old scripts that were written when a builtin name did not yet exist to run without error. The problem you ran into, using a name in two roles float = float("1.2") could be circumvented by writing float = builtins.float("1.2") but most of the time it is more convenient to think of builtins as names that are predefined in your current module and act accordingly. As you see redefining a builtin is as easy as importing builtins and setting the respective attribute >>> builtins.float = int >>> float(1.23) 1 From cs at cskk.id.au Tue May 25 05:38:35 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Tue, 25 May 2021 19:38:35 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 25May2021 10:23, hw wrote: >I'm about to do stuff with emails on an IMAP server and wrote a program >using imaplib which, so far, gets the UIDs of the messages in the >inbox: > > >#!/usr/bin/python I'm going to assume you're using Python 3. >import imaplib >import re > >imapsession = imaplib.IMAP4_SSL('imap.example.com', port = 993) > >status, data = imapsession.login('user', 'password') >if status != 'OK': > print('Login failed') > exit Your "exit" won't do what you want. I expect this code to raise a NameError exception here (you've not defined "exit"). That _will_ abort the programme, but in a manner indicating that you're used an unknown name. You probably want: sys.exit(1) You'll need to import "sys". >messages = imapsession.select(mailbox = 'INBOX', readonly = True) >typ, msgnums = imapsession.search(None, 'ALL') I've done little with IMAP. What's in msgnums here? Eg: print(type(msgnums), repr(msgnums)) just so we all know what we're dealing with here. >message_uuids = [] >for number in str(msgnums)[3:-2].split(): This is very strange. Did you see the example at the end of the module docs, it has this example code: import getpass, imaplib M = imaplib.IMAP4() M.login(getpass.getuser(), getpass.getpass()) M.select() typ, data = M.search(None, 'ALL') for num in data[0].split(): typ, data = M.fetch(num, '(RFC822)') print('Message %s\n%s\n' % (num, data[0][1])) M.close() M.logout() It is just breaking apart data[0] into strings which were separated by whitespace in the response. And then using those same strings as keys for the .fecth() call. That doesn't seem complex, and in fact is blind to the format of the "message numbers" returned. It just takes what it is handed and uses those to fetch each message. > status, data = imapsession.fetch(number, '(UID)') > if status == 'OK': > match = re.match('.*\(UID (\d+)\)', str(data)) [...] >It's working (with Cyrus), but I have the feeling I'm doing it all >wrong because it seems so unwieldy. IMAP's quite complex. Have you read RFC2060? https://datatracker.ietf.org/doc/html/rfc2060.html The imaplib library is probably a fairly basic wrapper for the underlying protocol which provides methods for the basic client requests and conceals the asynchronicity from the user for ease of (basic) use. >Apparently the functions of imaplib return some kind of bytes while >expecting strings as arguments, like message numbers must be strings. >The documentation doesn't seem to say if message UIDs are supposed to >be integers or strings. You can go a long way by pretending that they are opaque strings. That they may be numeric in content can be irrelevant to you. treat them as strings. >So I'm forced to convert stuff from bytes to strings (which is weird >because bytes are bytes) "bytes are bytes" is tautological. You're getting bytes for a few reasons: - the imap protocol largely talks about octets (bytes), but says they're text. For this reason a lot of stuff you pass as client parameters are strings, because strings are text. - text may be encoded as bytes in many ways, and without knowing the encoding, you can't extract text (strings) from bytes - the imaplib library may date from Python 2, where the str type was essentially a byte sequence. In Python 3 a str is a sequence of Unicode code points, and you translate to/from bytes if you need to work with bytes. Anyway, the IMAP response are bytes containing text. You get a lot of bytes. When you go: text = str(data) that is _assuming_ a particular text encoding stored in the data. You really ought to specify an encoding here. If you've not specified the CHARSET for things, 'ascii' would be a conservative choice. The IMAP RFC talks about what to expect in section 4 (Data Formats). There's quite a lot of possible response formats and I can understand imaplib not getting deeply into decoding these. >and to use regular expressions to extract the message-uids from what >the functions return (which I shouldn't have to because when I'm asking >a function to give me a uid, I expect it to return a uid). No, you're asking the IMAP _protocol_ to return you UIDs. The module itself doesn't parse what you ask for in the fetch results, and therefore it can't decode the response (data bytes) into some higher level thing (such as UIDs in your case, but you can ask for all sorts of weird stuff with IMAP). So having passed '(UID)' to the SEARCH request, you now need to parse the response. >This so totally awkward and unwieldy and involves so much overhead >that I must be doing this wrong. But am I? How would I do this right? Well, you _could_ get immersed in the nitty gritty of the IMAP protocol and the imaplib module, _or_ you could see if someone else has done some work to make this easier by writing a higher level library. A search at pypi.org for "imap" found a lot of stuff. The package named "imap-tools" looks promising. Try that. Cheers, Cameron Simpson From rosuav at gmail.com Tue May 25 07:46:34 2021 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 25 May 2021 21:46:34 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On Tue, May 25, 2021 at 8:21 PM Cameron Simpson wrote: > When you go: > > text = str(data) > > that is _assuming_ a particular text encoding stored in the data. You > really ought to specify an encoding here. If you've not specified the > CHARSET for things, 'ascii' would be a conservative choice. The IMAP RFC > talks about what to expect in section 4 (Data Formats). There's quite a > lot of possible response formats and I can understand imaplib not > getting deeply into decoding these. Worse than that: what you actually get is the repr of the bytes. That might happen to look a lot like an ASCII decode, but if the string contains unprintable characters, quotes, or anything outside of the ASCII range, it's going to represent it as an escape code. The best way to turn bytes into text is the decode method: data.decode("UTF-8") ChrisA From Richard at Damon-Family.org Tue May 25 07:57:29 2021 From: Richard at Damon-Family.org (Richard Damon) Date: Tue, 25 May 2021 07:57:29 -0400 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 5/25/21 12:08 AM, hw wrote: > > Are all names references?? When I pass a name as a parameter to a > function, does the object the name is referring to, when altered by > the function, still appear altered after the function has returned?? I > wouldn't expect that ... If you mutate the object the parameter was bound to, the calling function will see the changed object. (This requires the object to BE mutateable, like a list, not an int) If you rebind that parameter to a new object, the calling function doesn't see the change, as its name wasn't rebound. -- Richard Damon From skip.montanaro at gmail.com Tue May 25 08:00:55 2021 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Tue, 25 May 2021 07:00:55 -0500 Subject: imaplib: is this really so unwieldy? In-Reply-To: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: > It's working (with Cyrus), but I have the feeling I'm doing it all wrong > because it seems so unwieldy. I have a program, Polly , which I wrote to generate XKCD 936 passphrases. (I got the idea - and the name - from Chris Angelico. See the README.) It builds its dictionary from emails in my Gmail account which are tagged "polly" by a Gmail filter. I had put it away for a few years, at which time it was still using Python 2. When I came back to it, I wanted to update it to Python 3. As with so many 2-to-3 ports, the whole bytes/str problem was my stumbling block. Imaplib's API (as you've discovered) is not the most Pythonic. I didn't spend much time horsing around with it. Instead, I searched for higher-level packages, eventually landing on IMAPClient . Once I made the switch, things came together pretty quickly, due in large part, I think, to its more sane API. YMMV, but you're more than welcome to steal code from Polly. Skip From torriem at gmail.com Tue May 25 10:37:22 2021 From: torriem at gmail.com (Michael Torrie) Date: Tue, 25 May 2021 08:37:22 -0600 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: <9b826a97-e4f5-535c-0574-959da921e2e5@gmail.com> On 5/24/21 9:53 PM, hw wrote: > That seems like an important distinction. I've always been thinking of > variables that get something assigned to them, not as something that is > being assigned to something. Your thinking is not incorrect. Assignment is how you set a variable to something. For the most part the details of how the variables work doesn't matter all that much. An expression in Python works about the same as it does in other languages. Where it becomes important to understand the name binding mechanism is in situations like you found yourself. What happens, for example, when you do something like float=5? Hence the discussion about name shadowing. The reason I brought up the distinction of how python's variables work compared to a language like C is because under the hood Python's assignment doesn't "alter" the variable. Assignment replaces it entirely in the name space. This is consistent with a more formal definition of variable found in lambda calculus. I learned in uni there are some formal languages that don't allow any variable names to be rebound at all, which makes formal proofs and analysis easier. But I digress. There are also implications for parameter passing. All of this is in the language reference documentation of course. But even still there have been many arguments about whether Python is pass by value or pass by reference. Consider: def foo(bar): bar += 1 a = 5 foo(a) print(a) or def frob(foo): foo.append('bar') a = [ 'one', 'two' ] frob(a) print(a) The truth is Python might be said to "pass by object." In other words when you call a function, it goes through the names table and extracts references to all the objects involves with the arguments and passes those objects to the function. Objects that are mutable can be changed by a function, and those changes are visible in the code that called it, since both caller and callee are dealing with the *same object*, just by different names (aliases). Strings and other values like ints are *immutable*. They cannot be changed. Assignment will not change them, only overwrite the names in the locals table. > I would think of it as assigning a string to a variable and then > changing the content of the variable by assigning something else to the > same variable. When variables are typeless, it doesn't matter if a > string or an integer is assigned to one (which is weird but can be very > useful). Yes that's how it's done in many lower-level languages. Python does not assign that way, though. It's not clearing the contents and placing something else there. Instead assignment overwrites the binding in the name table, connecting the name to the new string object that was created. The old object is dereferenced, and the garbage collector will eventually remove it. > It seems much more practical to assign different strings to the same > variable rather than assigning a different variable to each string, or > to assign a string to a variable and then to assign an integer to it. How exactly would one overwrite an integer in memory with a string, though? You would have to either preallocate a lot of memory for it in case something large were to be written to the variable, or you'd allocate it on the heap on demand and use a reference for it. Under the hood, Python does the second. How else would you do it? > Isn't that what variables are for? In the formal sense, variables are just names that stand in for values. Don't get too hung up on the mechanics of how one implements that as being a formal part of the definition, and don't think that one language's implementation of variables is the only way to do it. From greg.ewing at canterbury.ac.nz Tue May 25 03:42:26 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 25 May 2021 19:42:26 +1200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> Message-ID: On 25/05/21 2:59 pm, hw wrote: > Then what is 'float' in the case of isinstance() as the second > parameter, and why can't python figure out what 'float' refers to in > this case? You seem to be asking for names to be interpreted differently when they are used as parameters to certain functions. Python doesn't do that sort of thing. The way it evaluates expressions is very simple and consistent, and that's a good thing. It means there aren't any special cases to learn and remember. Maybe you're not aware that isinstance is just a function, and not any kind of special syntax? > Perhaps type names should be keywords to avoid confusion. Python has quite a lot of built-in types, some of them in the builtin namespace, some elsewhere. Making them all keywords would be impractical, even if it were desirable. And what about user-defined types? Why should they be treated differently to built-in types? Or are you suggesting there should be a special syntax for declaring type names? -- Greg From alan.gauld at yahoo.co.uk Tue May 25 05:18:31 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Tue, 25 May 2021 10:18:31 +0100 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 25/05/2021 00:41, Jon Ribbens via Python-list wrote: > What would you call the argument to a function that > returns, say, an upper-cased version of its input? Probably 'candidate' or 'original' or 'initial' or somesuch. Or even just 's'. Single character names are OK when there is no significant meaning to convey! But never a type name since the type could change or be extended (like bytes or even a user defined string subclass.) The exception being where it's a teaching exercise where the type is important, but even there I'd precede it with an article: aString, the_string or similar. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From greg.ewing at canterbury.ac.nz Tue May 25 09:09:08 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 26 May 2021 01:09:08 +1200 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: On 25/05/21 5:56 pm, Avi Gross wrote: > Var = read in something from a file and make some structure like a data.frame > Var = remove some columns from the above thing pointed to by Var > Var = make some new calculated columns ditto > Var = remove some rows ... > Var = set some kind of grouping on the above or sort it and so on. As long as all the values are of the same type, this isn't too bad, although it might interfere with your ability to give the intermediate results names that help the reader understand what they refer to. A variable that refers to things of different *types* at different times is considerably more confusing, both for a human reader and for any type checking software you might want to use. > How can you write a recursive function without this kind of variable shadowing? Each invocation of a function places the internal namespace in front of the parent so the meaning of a variable name used within is always backed by all the iterations before it. Um, no. What you're describing is called "dynamic scoping", and Python doesn't have it. Python is *lexically* scoped, meaning that only scopes that textually enclose the function in the source are searched for names. Frames on the call stack don't come into it. > So what if you suggest we allow re-use of names but WARN you. ... The first 50 places may be in other instances of the recursive function and you have already been warned this way 49 times If this were to be done, the shadowing would be detected at compile time, so you would only be warned once. -- Greg From grant.b.edwards at gmail.com Tue May 25 09:45:59 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 25 May 2021 13:45:59 -0000 (UTC) Subject: learning python ... References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 2021-05-24, Alan Gauld via Python-list wrote: > On 24/05/2021 19:48, Grant Edwards wrote: > >>> Traceback ( File "", line 1 >>> if = 1.234 >>> ^ >>> SyntaxError: invalid syntax >> >> I must admit it might be nice if the compiler told you _why_ the >> syntax is invalid (e.g. "expected conditional expression while parsing >> 'if' statement"). > > Although wouldn't it be "expected boolean expression" rather than > conditional expression? Python doesn't care how the argument to 'if' > is arrived at so long as it's a boolean. Indeed -- after posting that I realized that "conditional expression" was not the best phrase to choose because that's often used to refer to an expression involving the new ternary operator. I should have said "boolean valued expression". Though in the syntax for the ternary operator expression I've seen such a boolean valued expression called a "conditional expression". https://realpython.com/python-conditional-statements/ if else From grant.b.edwards at gmail.com Tue May 25 09:55:52 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 25 May 2021 13:55:52 -0000 (UTC) Subject: imaplib: is this really so unwieldy? References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 2021-05-25, hw wrote: > I'm about to do stuff with emails on an IMAP server and wrote a program > using imaplib My recollection of using imaplib a few years ago is that yes, it is unweildy, oddly low-level, and rather un-Pythonic (excuse my presumption in declaring what is and isn't "Pythonic"). I switched to using imaplib2 and found it much easier to use. It's a higher-level wrapper for imaplib. I think this is the currently maintained fork: https://github.com/jazzband/imaplib2 I haven't activly used either for several years, so things may have changed... -- Grant From grant.b.edwards at gmail.com Tue May 25 12:14:46 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 25 May 2021 16:14:46 -0000 (UTC) Subject: learning python ... References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: On 2021-05-25, Greg Ewing wrote: > On 25/05/21 5:56 pm, Avi Gross wrote: >> Var = read in something from a file and make some structure like a data.frame >> Var = remove some columns from the above thing pointed to by Var >> Var = make some new calculated columns ditto >> Var = remove some rows ... >> Var = set some kind of grouping on the above or sort it and so on. > > As long as all the values are of the same type, this isn't too bad, > although it might interfere with your ability to give the intermediate > results names that help the reader understand what they refer to. I do vaguely recall 20+ years ago when I first started writing Python I recoiled at it, but now I don't find it to be a problem if all of the assignments are close together as above (so that it's not possible to see one and miss the others) and there's only one execution path through that chunk of code. I try to avoid it if they're spread out over hundreds of lines of code or if there are paths that result in different types at the end. > A variable that refers to things of different *types* at different > times is considerably more confusing, both for a human reader and > for any type checking software you might want to use. Ah, I've never tried any type checking software, so that may explain my lax attitude. -- Grant From mstemper at gmail.com Tue May 25 12:38:27 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Tue, 25 May 2021 11:38:27 -0500 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 24/05/2021 23.08, hw wrote: > On 5/25/21 12:37 AM, Greg Ewing wrote: >> Python does have references to *objects*. All objects live on >> the heap and are kept alive as long as there is at least one >> reference to them. >> >> If you rebind a name, and it held the last reference to an >> object, there is no way to get that object back. > > Are all names references?? When I pass a name as a parameter to a > function, does the object the name is referring to, when altered by the > function, still appear altered after the function has returned?? I > wouldn't expect that ... I just ran a quick check and java (Ack, spit) does the same thing. -- Michael F. Stemper Isaiah 10:1-2 From hw at adminart.net Tue May 25 13:21:39 2021 From: hw at adminart.net (hw) Date: Tue, 25 May 2021 19:21:39 +0200 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 5/25/21 11:38 AM, Cameron Simpson wrote: > On 25May2021 10:23, hw wrote: >> I'm about to do stuff with emails on an IMAP server and wrote a program >> using imaplib which, so far, gets the UIDs of the messages in the >> inbox: >> >> >> #!/usr/bin/python > > I'm going to assume you're using Python 3. Python 3.9.5 >> import imaplib >> import re >> >> imapsession = imaplib.IMAP4_SSL('imap.example.com', port = 993) >> >> status, data = imapsession.login('user', 'password') >> if status != 'OK': >> print('Login failed') >> exit > > Your "exit" won't do what you want. I expect this code to raise a > NameError exception here (you've not defined "exit"). That _will_ abort > the programme, but in a manner indicating that you're used an unknown > name. You probably want: > > sys.exit(1) > > You'll need to import "sys". Oh ok, it seemed to be fine. Would it be the right way to do it with sys.exit()? Having to import another library just to end a program might not be ideal. >> messages = imapsession.select(mailbox = 'INBOX', readonly = True) >> typ, msgnums = imapsession.search(None, 'ALL') > > I've done little with IMAP. What's in msgnums here? Eg: > > print(type(msgnums), repr(msgnums)) > > just so we all know what we're dealing with here. [b''] >> message_uuids = [] >> for number in str(msgnums)[3:-2].split(): > > This is very strange. Did you see the example at the end of the module > docs, it has this example code: > > import getpass, imaplib > > M = imaplib.IMAP4() > M.login(getpass.getuser(), getpass.getpass()) > M.select() > typ, data = M.search(None, 'ALL') > for num in data[0].split(): > typ, data = M.fetch(num, '(RFC822)') > print('Message %s\n%s\n' % (num, data[0][1])) > M.close() > M.logout() Yes, and I don't understand it. 'print(msgnums)' prints: [b''] when there are no messages and [b'1 2 3 4 5'] So I was guessing that it might be an array containing a single a string and that refering to the first element of the array turns into a string with which split() can used. But 'print(msgnums[0].split())' prints [b'1', b'2', b'3', b'4', b'5'] so I can only guess what that's supposed to mean: maybe an array of many bytes? The documentation[1] clearly says: "The message_set options to commands below is a string [...]" I also need to work with message uids rather than message numbers because the numbers can easily change. There doesn't seem to be a way to do that with this library in python. So it's all guesswork, and I gave up after a while and programmed what I wanted in perl. The documentation of this library sucks, and there are worlds between it and the documentation for the libraries I used with perl. That doesn't mean I don't want to understand why this is so unwieldy. It's all nice and smooth in perl. [1]: https://docs.python.org/3/library/imaplib.html > It is just breaking apart data[0] into strings which were separated by > whitespace in the response. And then using those same strings as keys > for the .fecth() call. That doesn't seem complex, and in fact is blind > to the format of the "message numbers" returned. It just takes what it > is handed and uses those to fetch each message. That's not what the documentation says. >> status, data = imapsession.fetch(number, '(UID)') >> if status == 'OK': >> match = re.match('.*\(UID (\d+)\)', str(data)) > [...] >> It's working (with Cyrus), but I have the feeling I'm doing it all >> wrong because it seems so unwieldy. > > IMAP's quite complex. Have you read RFC2060? > > https://datatracker.ietf.org/doc/html/rfc2060.html Yes, I referred to it and it didn't become any more clear in combination with the documentation of the python library. > The imaplib library is probably a fairly basic wrapper for the > underlying protocol which provides methods for the basic client requests > and conceals the asynchronicity from the user for ease of (basic) use. Skip Montanaro seems to say that the byte problem comes from the change from python 2 to 3 and there is a better library now: https://pypi.org/project/IMAPClient/ But the documentation seems even more sparse than the one for imaplib. Is it a general thing with python that libraries are not well documented? >> Apparently the functions of imaplib return some kind of bytes while >> expecting strings as arguments, like message numbers must be strings. >> The documentation doesn't seem to say if message UIDs are supposed to >> be integers or strings. > > You can go a long way by pretending that they are opaque strings. That > they may be numeric in content can be irrelevant to you. treat them as > strings. That's what I ended up doing. >> So I'm forced to convert stuff from bytes to strings (which is weird >> because bytes are bytes) > > "bytes are bytes" is tautological. which is a good thing > You're getting bytes for a few > reasons: > > - the imap protocol largely talks about octets (bytes), but says they're > text. For this reason a lot of stuff you pass as client parameters are > strings, because strings are text. > > - text may be encoded as bytes in many ways, and without knowing the > encoding, you can't extract text (strings) from bytes > > - the imaplib library may date from Python 2, where the str type was > essentially a byte sequence. In Python 3 a str is a sequence of > Unicode code points, and you translate to/from bytes if you need to > work with bytes. > > Anyway, the IMAP response are bytes containing text. You get a lot of > bytes. Well, ok, but it's not helpful that b is being inserted like everywhere, and I have to keep asking myself what I'm looking at because bytes are bytes. Since the documentation is so bad, I had to figure it out by trial and error and by printing stuff and making guesses and assumptions. That's just not the way to program something. > When you go: > > text = str(data) > > that is _assuming_ a particular text encoding stored in the data. You > really ought to specify an encoding here. If you've not specified the > CHARSET for things, 'ascii' would be a conservative choice. The IMAP RFC > talks about what to expect in section 4 (Data Formats). There's quite a > lot of possible response formats and I can understand imaplib not > getting deeply into decoding these. UTF8 is the default since quite a while now. Why doesn't it just use that? >> and to use regular expressions to extract the message-uids from what >> the functions return (which I shouldn't have to because when I'm asking >> a function to give me a uid, I expect it to return a uid). > > No, you're asking the IMAP _protocol_ to return you UIDs. The module > itself doesn't parse what you ask for in the fetch results, and > therefore it can't decode the response (data bytes) into some higher > level thing (such as UIDs in your case, but you can ask for all sorts of > weird stuff with IMAP). Then its documentation should at least specify what the library does. And perhaps it shouldn't specify that some of its functions expect their parameters to be strings rather than what other functions return, requiring guesswork and conversations of the data because the functions kinda aren't compatabile with each other. > So having passed '(UID)' to the SEARCH request, you now need to parse > the response. First I have to guess what the response might be ... And once I manged that, there's still no way to do something with a message by its uid. >> This so totally awkward and unwieldy and involves so much overhead >> that I must be doing this wrong. But am I? How would I do this right? > > Well, you _could_ get immersed in the nitty gritty of the IMAP protocol > and the imaplib module, _or_ you could see if someone else has done some > work to make this easier by writing a higher level library. A search at > pypi.org for "imap" found a lot of stuff. The package named "imap-tools" > looks promising. Try that. Thanks, both the site and the imap-tools package there look interesting. From python at mrabarnett.plus.com Tue May 25 13:25:47 2021 From: python at mrabarnett.plus.com (MRAB) Date: Tue, 25 May 2021 18:25:47 +0100 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 2021-05-25 16:41, Dennis Lee Bieber wrote: > On Tue, 25 May 2021 10:23:41 +0200, hw declaimed the > following: > >> >>So I'm forced to convert stuff from bytes to strings (which is weird >>because bytes are bytes) and to use regular expressions to extract the >>message-uids from what the functions return (which I shouldn't have to >>because when I'm asking a function to give me a uid, I expect it to >>return a uid). >> > In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER CHARACTER > (I don't recall if there is a 3-byte version). If your input bytes are all > 7-bit ASCII, then they map directly to a 1-byte per character string. If > they contain any 8-bit upper half character they may map into a 2-byte per > character string. > In CPython 3.3+: U+0000..U+00FF are stored in 1 byte. U+0100..U+FFFF are stored in 2 bytes. U+010000..U+10FFFF are stored in 4 bytes. > Bytes in Python 3 are just a binary stream, which needs an encoding to > produce characters. Use the wrong encoding (say ISO-Latin-1) when the data > is really UTF-8 will result in garbage. > > From grant.b.edwards at gmail.com Tue May 25 13:38:54 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 25 May 2021 17:38:54 -0000 (UTC) Subject: imaplib: is this really so unwieldy? References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 2021-05-25, MRAB wrote: > On 2021-05-25 16:41, Dennis Lee Bieber wrote: >> In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER >> CHARACTER (I don't recall if there is a 3-byte version). If your >> input bytes are all 7-bit ASCII, then they map directly to a 1-byte >> per character string. If they contain any 8-bit upper half >> character they may map into a 2-byte per character string. >> > In CPython 3.3+: > > U+0000..U+00FF are stored in 1 byte. > U+0100..U+FFFF are stored in 2 bytes. > U+010000..U+10FFFF are stored in 4 bytes. Are all characters in a string stored with the same "width"? IOW, does the presense of one Unicode character in the range U+010000..U+10FFFF in a string that is otherwise all 7-bit ASCII values result in the entire string being stored 4-bytes per character? Or is the storage width variable within a single string? -- Grant From grant.b.edwards at gmail.com Tue May 25 13:47:02 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Tue, 25 May 2021 17:47:02 -0000 (UTC) Subject: learning python ... References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 2021-05-25, Michael F. Stemper wrote: > On 24/05/2021 23.08, hw wrote: >> On 5/25/21 12:37 AM, Greg Ewing wrote: >> >> Are all names references?? When I pass a name as a parameter to a >> function, does the object the name is referring to, when altered by the >> function, still appear altered after the function has returned?? I >> wouldn't expect that ... > > I just ran a quick check and java (Ack, spit) does the same thing. PHP might or might not do the same thing. There might or might not be extra syntax to specify which you want. Where that syntax goes and how it works varies depending on the version of PHP. There might also be a global config file where you can change the "default" behavior. Or not. In PHP, there's nothing _but_ special cases to try to remember. And the details for those cases change from one version to the next. If ever there was a language that's perpetually unfinished, it's PHP. From mstemper at gmail.com Tue May 25 15:14:20 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Tue, 25 May 2021 14:14:20 -0500 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: On 24/05/2021 18.30, Alan Gauld wrote: > On 24/05/2021 16:54, Michael F. Stemper wrote: > >> In my early days of writing python, I created lists named "list", >> dictionaries named "dict", and strings named "str". I mostly know better >> now, but sometimes still need to restrain my fingers. > > I think most newbie programmers make that mistake. I certainly > did when learning Pascal back in the 80's. > > But I was lucky, the tutorials were run by a guy who penalized > bad variable names severely and took a half-mark off for every > bad name. We very quickly learned to choose names that were > descriptive of the purpose rather than the type. And when I write code that models something physical, I'll create an object with attributes named after the real-world attributes that such an object has. For instance, a generator (NOT in the python sense) might have attributes such as: RealPower ReactivePower IncrementalCostCurve (an object all on its own) DispatchedPower But, when I mess around with number theory, if I need a dict that has naturals as keys and their aliquot sums as values, it's easy enough to fall into that trap; especially if I already have a function AliquotSum() that populates the dictionary as it grows. -- Michael F. Stemper Deuteronomy 10:18-19 From tjreedy at udel.edu Tue May 25 18:23:34 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 25 May 2021 18:23:34 -0400 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 5/25/2021 1:25 PM, MRAB wrote: > On 2021-05-25 16:41, Dennis Lee Bieber wrote: >> ????In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER >> CHARACTER This is CPython 3.3+ specific. Before than, it depended on the OS. I believe MicroPython uses utf-8 for strings. >> (I don't recall if there is a 3-byte version). There isn't. It would save space but cost time. >> If your input bytes are all >> 7-bit ASCII, then they map directly to a 1-byte per character string. If your input bytes all have the upper bit 0 and they are interpreted as encoding ascii characters then they map to overhead + 1 byte per char >>> sys.getsizeof(b''.decode('ascii')) 49 >>> sys.getsizeof(b'a'.decode('ascii')) 50 >>> sys.getsizeof(11*b'a'.decode('ascii')) 60 >> If >> they contain any 8-bit upper half character they may map into a 2-byte >> per character string. See below. > In CPython 3.3+: > > U+0000..U+00FF are stored in 1 byte. > U+0100..U+FFFF are stored in 2 bytes. > U+010000..U+10FFFF are stored in 4 bytes. In CPython's Flexible String Representation all characters in a string are stored with the same number of bytes, depending on the largest codepoint. >>> sys.getsizeof('\U00011111') 80 >>> sys.getsizeof('\U00011111'*2) 84 >>> sys.getsizeof('a\U00011111') 84 >> Bytes in Python 3 are just a binary stream, which needs an >> encoding to produce characters. Or any other Python object. >> Use the wrong encoding (say ISO-Latin-1) when the >> data is really UTF-8 will result in garbage. So does decoding bytes as text when the bytes encode something else, such as an image ;-). -- Terry Jan Reedy From ml_news at posteo.de Tue May 25 12:49:18 2021 From: ml_news at posteo.de (Manfred Lotz) Date: Tue, 25 May 2021 18:49:18 +0200 Subject: learning python ... References: <2517859136@f192.n1.z21.fsxnet> Message-ID: <20210525184918.54d14b36.ml_news@posteo.de> On Mon, 24 May 2021 08:14:39 +1200 Ron.Lauzon at f192.n1.z21.fsxnet (Ron Lauzon) wrote: > -=> hw wrote to All <=- > > hw> Traceback (most recent call last): > hw> File "[...]/hworld.py", line 18, in > hw> print(isinstance(int, float)) > hw> TypeError: isinstance() arg 2 must be a type or tuple of types > > hw> I would understand to get an error message in line 5 but not in > hw> 18. Is this a bug or a feature? > > Python is case sensitive. Is that supposed to be "isInstance"? > > This is easy to check $ python3 Python 3.9.5 (default, May 14 2021, 00:00:00) [GCC 11.1.1 20210428 (Red Hat 11.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> isinstance >>> isInstance Traceback (most recent call last): File "", line 1, in NameError: name 'isInstance' is not defined From rosuav at gmail.com Tue May 25 18:34:28 2021 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 26 May 2021 08:34:28 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On Wed, May 26, 2021 at 8:27 AM Grant Edwards wrote: > > On 2021-05-25, MRAB wrote: > > On 2021-05-25 16:41, Dennis Lee Bieber wrote: > > >> In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER > >> CHARACTER (I don't recall if there is a 3-byte version). If your > >> input bytes are all 7-bit ASCII, then they map directly to a 1-byte > >> per character string. If they contain any 8-bit upper half > >> character they may map into a 2-byte per character string. > >> > > In CPython 3.3+: > > > > U+0000..U+00FF are stored in 1 byte. > > U+0100..U+FFFF are stored in 2 bytes. > > U+010000..U+10FFFF are stored in 4 bytes. > > Are all characters in a string stored with the same "width"? IOW, does > the presense of one Unicode character in the range U+010000..U+10FFFF > in a string that is otherwise all 7-bit ASCII values result in the > entire string being stored 4-bytes per character? Or is the storage > width variable within a single string? > Yes, any given string has a single width, which makes indexing fast. The memory cost you're describing can happen, but apart from a BOM widening an otherwise-ASCII string to 16-bit, there aren't many cases where you'll get a single wide character in a narrow string. Usually, if there are any wide characters, there'll be a good number of them (for instance, text in any particular language will often have a lot of characters from a block of characters allocated to it). As an added benefit, keeping all characters the same width simplifies string searching algorithms, if I'm reading the code correctly. Checks like >>"foo" in some_string<< can widen the string "foo" to the width of the target string and then search efficiently. ChrisA From greg.ewing at canterbury.ac.nz Tue May 25 18:35:39 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 26 May 2021 10:35:39 +1200 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 26/05/21 5:21 am, hw wrote: > On 5/25/21 11:38 AM, Cameron Simpson wrote: >> You'll need to import "sys". > > aving to import another library just to end a program > might not be ideal. The sys module is built-in, so the import isn't really loading anything, it's just giving you access to a namespace. But if you prefer, you can get the same result without needing an import using raise SystemExit(1) -- Greg From greg.ewing at canterbury.ac.nz Tue May 25 18:44:17 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 26 May 2021 10:44:17 +1200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> Message-ID: > On 2021-05-24, Alan Gauld via Python-list wrote: >> Although wouldn't it be "expected boolean expression" rather than >> conditional expression? Python doesn't care how the argument to 'if' >> is arrived at so long as it's a boolean. This isn't really true either. Almost every object in Python has an interpretation as true or false, and can be used wherever a boolean value is needed. -- Greg From greg.ewing at canterbury.ac.nz Tue May 25 18:48:34 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 26 May 2021 10:48:34 +1200 Subject: learning python ... In-Reply-To: References: <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> Message-ID: On 26/05/21 3:33 am, Dennis Lee Bieber wrote: > the OBJECTS have a type and can not change type. Well... built-in types can't, but... >>> class A: ... pass ... >>> class B: ... pass ... >>> a = A() >>> type(a) >>> a.__class__ = B >>> type(a) -- Greg From cs at cskk.id.au Tue May 25 19:02:16 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Wed, 26 May 2021 09:02:16 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> References: <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> Message-ID: On 25May2021 15:53, Dennis Lee Bieber wrote: >On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the >following: >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've never had to use sys. for exit... > >C:\Users\Wulfraed>python >Python ActivePython 3.8.2 (ActiveState Software Inc.) based on > on win32 >Type "help", "copyright", "credits" or "license" for more information. >>>> exit() !!!!!!!! I have learned a new thing today. Regardless, hw didn't call it, just named it :-) Cheers, Cameron Simpson From cs at cskk.id.au Tue May 25 18:25:49 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Wed, 26 May 2021 08:25:49 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: Message-ID: On 25May2021 19:21, hw wrote: >On 5/25/21 11:38 AM, Cameron Simpson wrote: >>On 25May2021 10:23, hw wrote: >>>if status != 'OK': >>> print('Login failed') >>> exit >> >>Your "exit" won't do what you want. I expect this code to raise a >>NameError exception here (you've not defined "exit"). That _will_ abort >>the programme, but in a manner indicating that you're used an unknown >>name. You probably want: >> >> sys.exit(1) >> >>You'll need to import "sys". > >Oh ok, it seemed to be fine. Would it be the right way to do it with >sys.exit()? Having to import another library just to end a program >might not be ideal. To end a programme early, yes. (sys.exit() actually just raises a particular exception, BTW.) I usually write a distinct main function, so in that case one can just "return". After all, what seems an end-of-life circumstance in a standalone script like yours is just an "end this function" circumstance when viewed as a function, and that also lets you _call_ the main programme from some outer thing. Wouldn't want that outer thing cancelled, if it exists. My usual boilerplate for a module with a main programme looks like this: import sys ...... def main(argv): ... main programme, return like any other function ... .... other code for the module - functions, classes etc ... if __name__ == '__main__': sys.exit(main(sys.argv)) which (a) puts main(0 up the top where it can be seen, (b) makes main() an ordinary function like any other (c) lets me just import that module elsewhere and (d) no globals - everything's local to main(). The __name__ boilerplate at the bottom is the magic which figures out if the module was imported (__name__ will be the import module name) or invoked from the command line like: python -m my_module cmd-line-args... in which case __name__ has the special value '__main__'. A historic mechanism which you will convince nobody to change. You'd be surprised how useful it is to make almost any standalone programme a module like this - in the medium term it almost always pays off for me. Even just the discipline of shoving all the formerly-global variables in the main function brings lower-bugs benefits. >>I've done little with IMAP. What's in msgnums here? Eg: >> print(type(msgnums), repr(msgnums)) >>just so we all know what we're dealing with here. > > [b''] > >>>message_uuids = [] >>>for number in str(msgnums)[3:-2].split(): >> >>This is very strange. [...] >Yes, and I don't understand it. 'print(msgnums)' prints: > >[b''] > >when there are no messages and > >[b'1 2 3 4 5'] Chris has addressed this. msgnums is list of the data components of the IMAP response. By going str(msgnums) you're not getting "the message numbers as text" you're getting what printing a list prints. Which is roughly Python code: the brakcets and the repr() of each list member. Notice that the example code accessed msgnums[0] - that is the first data component, a bytes. That you _can_ convert to a string (under assumptions about the encoding). By getting the "str" form of a list, you're forced into the weird [3:-2] hack to ttrim the ends. But it is just a hack for a transcription mistake, not a sane parse. >So I was guessing that it might be an array containing a single a >string and that refering to the first element of the array turns into >a string with which split() can used. But 'print(msgnums[0].split())' >prints > >[b'1', b'2', b'3', b'4', b'5'] msgnums[0] is bytes. You can do most str things with bytes (because that was found to be often useful) but you get bytes back from those operations as you'd hope. >so I can only guess what that's supposed to mean: maybe an array of >many bytes? The documentation[1] clearly says: "The message_set >options to commands below is a string [...]" But that is the parameter to the _call_: your '(UID)' parameter. >I also need to work with message uids rather than message numbers >because the numbers can easily change. There doesn't seem to be a way >to do that with this library in python. By asking for UIDs you're getting uids. Do they not work in subsequent calls? >So it's all guesswork, and I gave up after a while and programmed what >I wanted in perl. The documentation of this library sucks, and there >are worlds between it and the documentation for the libraries I used >with perl. I think you're better of looking for another Python imap library. The imaplib was basic functionality to (a) access the rpotocol in basic form and (b) conceal the async stuff, since IMAP is an asynchronous protocol. You can in fact subclass it to do better things. Other library might do thatm or they might have written their own protocol implementations. >That doesn't mean I don't want to understand why this is so unwieldy. >It's all nice and smooth in perl. But using what library? Something out of CPAN? Those are third party libraries, not Perl's presupplied stuff. The equivalent for Python is pypi.org. Look there. >>It is just breaking apart data[0] into strings which were separated by >>whitespace in the response. And then using those same strings as keys >>for the .fecth() call. That doesn't seem complex, and in fact is blind >>to the format of the "message numbers" returned. It just takes what it >>is handed and uses those to fetch each message. > >That's not what the documentation says. The _example code_ is blind to them, whatever the semantics of the docs. It just gets the uids and fetches with them. Aside from .split(), there's no parsing or deep understanding of the uid. >>IMAP's quite complex. Have you read RFC2060? >> >> https://datatracker.ietf.org/doc/html/rfc2060.html > >Yes, I referred to it and it didn't become any more clear in >combination with the documentation of the python library. IMAP's like that :-) >>The imaplib library is probably a fairly basic wrapper for the >>underlying protocol which provides methods for the basic client requests >>and conceals the asynchronicity from the user for ease of (basic) use. > >Skip Montanaro seems to say that the byte problem comes from the >change from python 2 to 3 and there is a better library now: >https://pypi.org/project/IMAPClient/ And someone mentioned imaplib2. There are several choices. >But the documentation seems even more sparse than the one for imaplib. >Is it a general thing with python that libraries are not well >documented? That depends on the library - it is of course at the whim of the developer. Heavily used powerful libraries are usually well documented, eg numpy. A random hacker's published module? Might have nothing. Wrappers for protocols like IMAP might have a bit of doco and expect the useful to infer stuff from knowledge of the protocol itself. [...] >>Anyway, the IMAP response are bytes containing text. You get a lot of >>bytes. > >Well, ok, but it's not helpful that b is being inserted like >everywhere, Only when you _print_ them. That "b" is an idicator that this is a bytes object being printed in a stringlike form because that is often a useful representation. Nothings inserting a "b" in the data itself. >and I have to keep asking myself what I'm looking at because bytes are >bytes. If you've got b'abc', that is a printout of a 3 byte string. _Not_ the string itself. >Since the documentation is so bad, I had to figure it out by trial and >error and by printing stuff and making guesses and assumptions. >That's just not the way to program something. No. But _many_ modules are what the original author needed to get something done, and neither complete nor perfectly documented. Life's too short. Well used module tend to become more complete, elegant and documented over time, _if_ people other than the author use them. >>When you go: >> >> text = str(data) >> >>that is _assuming_ a particular text encoding stored in the data. You >>really ought to specify an encoding here. If you've not specified the >>CHARSET for things, 'ascii' would be a conservative choice. The IMAP RFC >>talks about what to expect in section 4 (Data Formats). There's quite a >>lot of possible response formats and I can understand imaplib not >>getting deeply into decoding these. > >UTF8 is the default since quite a while now. Why doesn't it just use that? "since quite a while now" is pretty vague. Look at the date on RFC2060, and remember that that is version 4 of the protocol, _after_ a time consuming standardisation process. So subtract several years from that. Regardless, _assuming_ that arbitrary bytes are UTF8 is error prone and foolhardy and will lead to mojibake. If a protocol specifies a UTF8 encoding, you're good. Otherwise you need to find out what is actually going on. Some protocols are old enough to assume the world is ASCII. Some take a less rigid view that they're processing "text" at all, for all that their contents are effectively text. Notice that the RFC specifies that strings are 7-bit text except in certain circumstances. And those strings are probably ASCII. >Then its documentation should at least specify what the library does. It mostly does, and that doing is relatively basic. Does it say it provides high level post parsed data structures? No. It describes what it gets back from tehh IMAP responses, and further/deeper parse is up to the user. Who is free to subclass the IMAP class and add such parsing. Or to find or write a more Pythonic module (==> one with more normal Python idoms and working in Python classes like str more than in bytes). But the _protocol_ passes bytes data around. >>So having passed '(UID)' to the SEARCH request, you now need to parse >>the response. > >First I have to guess what the response might be ... And once I >manged that, there's still no way to do something with a message by >its uid. You can print the response, then look at the RFC to understand what it is and how to parse it. But this is grittiness you're not interested in, which means you need to look for a higher level library. Cheers, Cameron Simpson From grant.b.edwards at gmail.com Wed May 26 01:48:08 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Wed, 26 May 2021 05:48:08 -0000 (UTC) Subject: imaplib: is this really so unwieldy? References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> Message-ID: On 2021-05-25, Dennis Lee Bieber wrote: >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've never had to use sys. for exit... I would have sworn you used to have to import sys to use exit(). Am I misremembering? Apparently exit() and sys.exit() aren't the same, so what is the difference between the builtin exit and sys.exit? From grant.b.edwards at gmail.com Wed May 26 02:02:37 2021 From: grant.b.edwards at gmail.com (Grant Edwards) Date: Wed, 26 May 2021 06:02:37 -0000 (UTC) Subject: imaplib: is this really so unwieldy? References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> Message-ID: On 2021-05-25, Dennis Lee Bieber wrote: > On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the > following: > > >> >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've never had to use sys. for exit... > > C:\Users\Wulfraed>python > Python ActivePython 3.8.2 (ActiveState Software Inc.) based on > on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> exit() > > C:\Users\Wulfraed>python According to the docs (and various other sources), the global variable "exit" is provided by the site module and is only for use at the interactive prompt -- it should not be used in programs. https://docs.python.org/3/library/constants.html#exit I get the impression that real programs should not assume that the site module has been pre-loaded during startup. -- Grant From rosuav at gmail.com Wed May 26 02:35:51 2021 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 26 May 2021 16:35:51 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> Message-ID: On Wed, May 26, 2021 at 4:21 PM Grant Edwards wrote: > > On 2021-05-25, Dennis Lee Bieber wrote: > > >>Oh ok, it seemed to be fine. Would it be the right way to do it with > >>sys.exit()? Having to import another library just to end a program > >>might not be ideal. > > > > I've never had to use sys. for exit... > > I would have sworn you used to have to import sys to use exit(). Am I > misremembering? > > Apparently exit() and sys.exit() aren't the same, so what is the > difference between the builtin exit and sys.exit? > exit() is designed to be used interactively, so, among other things, it also has a helpful repr: >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit ChrisA From hw at adminart.net Wed May 26 03:15:56 2021 From: hw at adminart.net (hw) Date: Wed, 26 May 2021 09:15:56 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> Message-ID: <2752cfc2-fadb-a5f0-4d31-7fda393ff217@adminart.net> On 5/25/21 9:42 AM, Greg Ewing wrote: > On 25/05/21 2:59 pm, hw wrote: >> Then what is 'float' in the case of isinstance() as the second >> parameter, and why can't python figure out what 'float' refers to in >> this case? > > You seem to be asking for names to be interpreted differently > when they are used as parameters to certain functions. Sure, why not. Since python allows me to use the name of a variable type as a name for a variable, it could at least figure out which, the type or the variable, to use as parameter for a function that should specify a variable type when the name is given. Obviously, python knows what's expected, so why not chose that. > Python doesn't do that sort of thing. The way it evaluates > expressions is very simple and consistent, and that's a good > thing. It means there aren't any special cases to learn and > remember. Ok, that's certainly a valid point. It could be a general case that python picks for functions what is expected of their parameters when their parameters have ambigous names. > Maybe you're not aware that isinstance is just a function, > and not any kind of special syntax? > >> Perhaps type names should be keywords to avoid confusion. > > Python has quite a lot of built-in types, some of them in > the builtin namespace, some elsewhere. Making them all keywords > would be impractical, even if it were desirable. > > And what about user-defined types? Why should they be treated > differently to built-in types? Or are you suggesting there > should be a special syntax for declaring type names? I don't know; how many different types does it have? Maybe a special syntax for declaring type names which then can not become ambigous so easily would be a good thing? I already wondered that the scope of variables is not limited to the context they are declared within: for number in something: # do stuff # do more stuff or not ... print(number) When you do something like that in perl, the variable you declared is out of scope outside the loop whereas python surprises me by keeping it around. Somehow, the more I learn about python, the harder it becomes for me to read. Maybe that changes over time, yet keeping variables around like that is not something I would prefer. From hw at adminart.net Wed May 26 03:48:27 2021 From: hw at adminart.net (hw) Date: Wed, 26 May 2021 09:48:27 +0200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> Message-ID: <13034d97-9e3c-5e2f-7f0c-2d49bbfa0582@adminart.net> On 5/25/21 10:32 AM, Chris Angelico wrote: > On Tue, May 25, 2021 at 1:00 PM hw wrote: >> >> On 5/24/21 3:54 PM, Chris Angelico wrote: >>> You keep using that word "unfinished". I do not think it means what >>> you think it does. >> >> What do you think I think it means? > > I think it means that the language is half way through development, > doesn't have enough features to be usable, isn't reliable enough for > production, and might at some point in the future become ready to use. Right, that is what it seemed. > None of which is even slightly supported by evidence. That's not true. Remember the change from version 2 to 3 and ask yourself how likely it is that breaking things like that happens again. You may find a statement from developers about a policy that changes are to be announced a year before they go in, and that is evidence enough. What you make of this policy and what it means to you is for you to decide, but the evidence is clearly there. >>> Python has keywords. C has keywords. In Python, "None" is a keyword, >>> so you can't assign to it; in C, "int" is a keyword, so you can't >>> assign to it. There is no fundamental difference here, and the two >>> languages even have roughly the same number of keywords (35 in current >>> versions of Python; about 40 or 50 in C, depending on the exact >>> specification you're targeting). The only difference is that, in >>> Python, type names aren't keywords. You're getting caught up on a >>> trivial difference that has happened to break one particular test that >>> you did, and that's all. >> >> Then what is 'float' in the case of isinstance() as the second >> parameter, and why can't python figure out what 'float' refers to in >> this case? Perhaps type names should be keywords to avoid confusion. > > It's a name. In Python, any name reference is just a name reference. > There's no magic about the language "knowing" that the isinstance() > function should take a keyword, especially since there's no keywords > for these things. When I look at the error message, it seems to indicate that python knows very well what kind of parameter is expected. >>>> Maybe you can show how this is a likeable feature. I already understood >>>> that you can somehow re-define functions in python and I can see how >>>> that can be useful. You can do things like that in elisp as well. But >>>> easily messing up built-in variable types like that is something else. >>>> Why would I want that in a programming language, and why would I want to >>>> use one that allows it? >>> >>> Because all you did was mess with the *name* of the type. It's not >>> breaking the type system at all. >> >> And how is it a likeable feature? > > You can complain about whether it's likeable or not, but all you're > doing is demonstrating the Blub Paradox. And you remain unable to show how python making it easy to mess up type names is a likeable feature. >>> The C language never says that Python is "unfinished". I'm not making >>> assumptions, I'm reading your posts. >> >> I never said it is unfinished, I said it /seems/ unfinished. In any >> case, there is nothing insulting about it. Python is still being worked >> on (which is probably a good thing), and the switch from version 2 to >> version 3 has broken a lot of software, which doesn't help in making it >> appear as finished or mature. > > It's been around for thirty years. Quit fudding. You're getting very > close to my killfile. I take it you can't stand it when someone thinks differently than you do. Good for you that you have a kill file to protect you from different thoughts and ideas. > Python 3 has been around since 2009. Are you really telling me that > Python looks unfinished because of a breaking change more than a > decade ago? It looked unfinished to me because it doesn't even give an error message when I assign something to a type name as if it was a variable. Breaking things like that doesn't help, and it doesn't matter that it happened a while ago because I still have to deal with the issues it caused. That something has been around for a while doesn't have anything to do with how finished or unfinished it may appear. > The Go language didn't even *exist* before Python 3 - does > that mean that Go is also unfinished? Go is one of the games I never learned to play, though it seems kinda interesting. >> Just look at what the compiler says when you try to compile these >> examples. In the first example, you can't defeat a built-in data type >> by assigning something to it, and in the second one, you declare >> something as an instance of a build-in data type and then try to use it >> as a function. That is so because the language is designed as it is. > > Yes, because C uses keywords for types. That's the only difference > you're seeing here. You keep getting caught up on this one thing, one > phenomenon that comes about because of YOUR expectations that Python > and C should behave the same way. If you weren't doing isinstance > checks, you wouldn't even have noticed this! It is *NOT* a fundamental > difference. When it doesn't make a difference, then why doesn't python just use keywords for types and avoids all this ambiguity? > Also, you keep arguing against the language, instead of just using it > the way it is. It really sounds to me like you'd do better to just > give up on Python and go use some language that fits your brain > better. If you won't learn how a language works, it's not going to > work well for you. I'm not arguing against the language but discussing it with people who are trying to defend it. I tried to use it yesterday and failed because the documentation of a library I wanted to use it with is bad, and because maybe it wasn't such a good library. I would use it with another library for another purpose, but there is no documentation for that library at all, so I can't use it. So currently, it's not looking good for learning python. From rosuav at gmail.com Wed May 26 03:54:54 2021 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 26 May 2021 17:54:54 +1000 Subject: learning python ... In-Reply-To: <13034d97-9e3c-5e2f-7f0c-2d49bbfa0582@adminart.net> References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> <13034d97-9e3c-5e2f-7f0c-2d49bbfa0582@adminart.net> Message-ID: On Wed, May 26, 2021 at 5:49 PM hw wrote: > > On 5/25/21 10:32 AM, Chris Angelico wrote: > > On Tue, May 25, 2021 at 1:00 PM hw wrote: > >> > >> On 5/24/21 3:54 PM, Chris Angelico wrote: > >>> You keep using that word "unfinished". I do not think it means what > >>> you think it does. > >> > >> What do you think I think it means? > > > > I think it means that the language is half way through development, > > doesn't have enough features to be usable, isn't reliable enough for > > production, and might at some point in the future become ready to use. > > Right, that is what it seemed. And that's where you're insulting (a) the Python devs, (b) the Python user community, and (c) everyone who dares to use such a language in production. Without evidence. > > None of which is even slightly supported by evidence. > > That's not true. Remember the change from version 2 to 3 and ask > yourself how likely it is that breaking things like that happens again. > You may find a statement from developers about a policy that changes > are to be announced a year before they go in, and that is evidence enough. > > What you make of this policy and what it means to you is for you to > decide, but the evidence is clearly there. Ah yes. A breaking change *a decade ago*, and which has been clearly stated as not being repeated, is cause for you to be scared. Can you quit fudding please? > > You can complain about whether it's likeable or not, but all you're > > doing is demonstrating the Blub Paradox. > > And you remain unable to show how python making it easy to mess up type > names is a likeable feature. Exactly what I'm saying about Blub. You assume that every language has to treat type names as keywords, because that's the only model that fits inside your brain. > It looked unfinished to me because it doesn't even give an error message > when I assign something to a type name as if it was a variable. That's because a type name IS a variable, yet you can't understand that this is a good thing. > > Yes, because C uses keywords for types. That's the only difference > > you're seeing here. You keep getting caught up on this one thing, one > > phenomenon that comes about because of YOUR expectations that Python > > and C should behave the same way. If you weren't doing isinstance > > checks, you wouldn't even have noticed this! It is *NOT* a fundamental > > difference. > > When it doesn't make a difference, then why doesn't python just use > keywords for types and avoids all this ambiguity? Because Python has a lot of types, and lets you create your own. Fundamentally it *cannot* use keywords for every type name that you might create. > > Also, you keep arguing against the language, instead of just using it > > the way it is. It really sounds to me like you'd do better to just > > give up on Python and go use some language that fits your brain > > better. If you won't learn how a language works, it's not going to > > work well for you. > > I'm not arguing against the language but discussing it with people who > are trying to defend it. I tried to use it yesterday and failed because > the documentation of a library I wanted to use it with is bad, and > because maybe it wasn't such a good library. I would use it with > another library for another purpose, but there is no documentation for > that library at all, so I can't use it. So currently, it's not looking > good for learning python. Yes, you are arguing against the language. I'm done arguing with you. Clearly you do not want to use Python - you want to warp it to fit inside your own brain. Go use something else that actually works for you, and let the rest of us be productive with languages that are more powerful than you dare imagine. ChrisA From alan.gauld at yahoo.co.uk Wed May 26 03:18:48 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Wed, 26 May 2021 08:18:48 +0100 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 25/05/2021 23:23, Terry Reedy wrote: > In CPython's Flexible String Representation all characters in a string > are stored with the same number of bytes, depending on the largest > codepoint. I'm learning lots of new things in this thread! Does that mean that if I give Python a UTF8 string that is mostly single byte characters but contains one 4-byte character that Python will store the string as all 4-byte characters? If so, doesn't that introduce a pretty big storage overhead for large strings? > > >>> sys.getsizeof('\U00011111') > 80 > >>> sys.getsizeof('\U00011111'*2) > 84 > >>> sys.getsizeof('a\U00011111') > 84 Which is what this seems to be saying. I confess I had just assumed the unicode strings were stored in native unicode UTF8 format. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From greg.ewing at canterbury.ac.nz Wed May 26 06:54:26 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 26 May 2021 22:54:26 +1200 Subject: learning python ... In-Reply-To: References: <143d4163-faf5-3794-095d-f28e85a18c58@adminart.net> <6730da2c-1440-ad59-7494-b5ce5b5bccae@adminart.net> <5cec7f52-a66b-608c-4816-a3d8816658b2@adminart.net> <6ad46670-a0b4-d556-3b03-284ffa451c89@adminart.net> <2aa42ad6-8a22-b7d4-5fc7-a589b361cad5@adminart.net> <2752cfc2-fadb-a5f0-4d31-7fda393ff217@adminart.net> Message-ID: On 26/05/21 7:15 pm, hw wrote: > it could at least figure out which, the > type or the variable, to use as parameter for a function that should > specify a variable type when the name is given.? Obviously, python knows > what's expected, so why not chose that. It knows, but not until *after* the function is called. Not when the parameters are being evaluated. Note that not even C does what you're asking for. If you use a type name where a variable name is expected or vice versa in C, you get a compile-time error. It doesn't try to automagically figure out what you mean. The only difference is that Python gives you the error at run time. Also, you seem to be thinking only of the case where the type name appears directly in the call. But what about this: int = 42 type = int if isinstance(something, type): ... Would you expect Python to auto-correct this as well? > Maybe a special > syntax for declaring type names which then can not become ambigous so > easily would be a good thing? The fact that types are treated as a form of data is a useful feature. It means you can use the full power of the language on them. Dividing names into two kinds, types and non-types, would severely diminish that power. > I already wondered that the scope of variables is not limited to the > context they are declared within: > > for number in something: > ??? # do stuff This has been a subject of debate for quite a long time. Many people feel that a for-loop variable should be local to the loop, but Guido deliberately didn't make it that way. He felt it was useful to be able to refer to the loop variable after the loop finishes. That way you can do things like search for something in a loop, break out early when it's found, and the loop variable then contains the thing you found. It also has the benefit of being simple and consistent with the way scoping and assignments work in the rest of the language. There are other ways to code a search, of course, but it's been the way it is from the beginning, and changing it now would be massively disruptive. -- Greg From rosuav at gmail.com Wed May 26 08:31:41 2021 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 26 May 2021 22:31:41 +1000 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On Wed, May 26, 2021 at 10:04 PM Alan Gauld via Python-list wrote: > > On 25/05/2021 23:23, Terry Reedy wrote: > > > In CPython's Flexible String Representation all characters in a string > > are stored with the same number of bytes, depending on the largest > > codepoint. > > I'm learning lots of new things in this thread! > > Does that mean that if I give Python a UTF8 string that is mostly single > byte characters but contains one 4-byte character that Python will store > the string as all 4-byte characters? Nitpick: It won't be "a UTF-8 string"; it will be "a Unicode string". UTF-8 is a scheme for representing Unicode as a series of bytes, so if something is UTF-8, it'll be like b'Stra\xc3\x9fe' (with two bytes representing one non-ASCII character), whereas the corresponding Unicode string is 'Stra\xdfe' with a single character. Or, if it were beyond the first 256 characters, '\u2026' is an ellipsis, b'\xe2\x80\xa6' is a UTF-8 representation of that same character. And if it's beyond the BMP, then '\U0001F921' is one of the few non-ASCII characters that you can legitimately write off as a "funny character", and b'\xf0\x9f\xa4\xa1' is the UTF-8 byte sequence that would carry that. So. Yes, if you give Python a large ASCII string with a single non-BMP character, the entire string *will* be stored as four-byte characters. (Or, to nitpick against myself: CPython will do this. Other Python implementations are free to do differently, and for instance, uPy actually uses UTF-8 like you were predicting. For the rest of this post, when I say "Python", I actually mean "CPython 3.3 or later".) > If so, doesn't that introduce a pretty big storage overhead for > large strings? > > > > > >>> sys.getsizeof('\U00011111') > > 80 > > >>> sys.getsizeof('\U00011111'*2) > > 84 > > >>> sys.getsizeof('a\U00011111') > > 84 Correct. Each additional character is going to cost you four bytes. > Which is what this seems to be saying. > > I confess I had just assumed the unicode strings were stored > in native unicode UTF8 format. > UTF-8 isn't native any more than any other encoding. It's a good compact format for transmission, but it's quite inefficient for manipulation. Python opts to spend some memory in order to improve time, because that's usually the correct tradeoff to make - it means that indexing in a large string is fast, slicing a large string is fast, etc, etc, etc. Also, the truth is that, *in practice*, very few strings will pay this sort of penalty. If you have a whole lot of (say) Chinese text, there's going to be a small proportion of ASCII text, but most of the text is going to be wider characters. Working with most European languages will require the use of the BMP (which means 16-bit text), but not anything beyond. And if someone's going to use one emoji from the supplemental planes (which would require 32-bit text), it's fairly likely that they'll use multiple. And if you look at all strings in the Python interpreter, the vast majority of them will be ASCII-only, getting optimized all the way down to a single byte. Remember, every module-level variable is stored in that module's dictionary, keyed by its name - and *most* variable names in Python are ASCII. So while it's true that, in theory, a single wide character can cost you a lot of memory... in practice, this is still a lot more compact, overall, than storing all strings in UCS-2. ChrisA From python.list at tim.thechases.com Wed May 26 09:09:01 2021 From: python.list at tim.thechases.com (Tim Chase) Date: Wed, 26 May 2021 08:09:01 -0500 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: <20210526080901.0fd1f042@bigbox.attlocal.net> On 2021-05-26 08:18, Alan Gauld via Python-list wrote: > Does that mean that if I give Python a UTF8 string that is mostly > single byte characters but contains one 4-byte character that > Python will store the string as all 4-byte characters? As best I understand it, yes: the cost of each "character" in a string is the same for the entire string, so even one lone 4-byte character in an otherwise 1-byte-character string is enough to push the whole string to 4-byte characters. Doesn't effect other strings though (so if you had a pure 7-bit string and a unicode string, the former would still be 1-byte-per-char?it's not a global aspect) If you encode these to a UTF8 byte-string, you'll get the space savings you seek, but at the cost of sensible O(1) indexing. Both are a trade-off, and if your data consists mostly of 7-bit ASCII characters, or lots of small strings, the overhead is less pronounced than if you have one single large blob of text as a string. > If so, doesn't that introduce a pretty big storage overhead for > large strings? Yes. Though such large strings tend to be more rare, largely because they become unweildy for other reasons. -tkc From __peter__ at web.de Wed May 26 10:40:18 2021 From: __peter__ at web.de (Peter Otten) Date: Wed, 26 May 2021 16:40:18 +0200 Subject: exit() builtin, was Re: imaplib: is this really so unwieldy? In-Reply-To: References: <14hqag1k3ujs43uij6rig68vckqo97j386@4ax.com> Message-ID: On 26/05/2021 01:02, Cameron Simpson wrote: > On 25May2021 15:53, Dennis Lee Bieber wrote: >> On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the >> following: >>> Oh ok, it seemed to be fine. Would it be the right way to do it with >>> sys.exit()? Having to import another library just to end a program >>> might not be ideal. >> >> I've never had to use sys. for exit... >> >> C:\Users\Wulfraed>python >> Python ActivePython 3.8.2 (ActiveState Software Inc.) based on >> on win32 >> Type "help", "copyright", "credits" or "license" for more information. >>>>> exit() > > !!!!!!!! > > I have learned a new thing today. > > Regardless, hw didn't call it, just named it :-) exit() is inserted into the built-ins by site.py. This means it may not be available: PS D:\> py -c "exit('bye ')" bye PS D:\> py -S -c "exit('bye ')" Traceback (most recent call last): File "", line 1, in NameError: name 'exit' is not defined I have no idea if this is of any practical relevance... From jon+usenet at unequivocal.eu Wed May 26 08:11:35 2021 From: jon+usenet at unequivocal.eu (Jon Ribbens) Date: Wed, 26 May 2021 12:11:35 -0000 (UTC) Subject: string storage [was: Re: imaplib: is this really so unwieldy?] References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 2021-05-26, Alan Gauld wrote: > On 25/05/2021 23:23, Terry Reedy wrote: >> In CPython's Flexible String Representation all characters in a string >> are stored with the same number of bytes, depending on the largest >> codepoint. > > I'm learning lots of new things in this thread! > > Does that mean that if I give Python a UTF8 string that is mostly single > byte characters but contains one 4-byte character that Python will store > the string as all 4-byte characters? > > If so, doesn't that introduce a pretty big storage overhead for > large strings? Memory is cheap ;-) > I confess I had just assumed the unicode strings were stored > in native unicode UTF8 format. If you do that then indexing and slicing strings becomes very slow. From mstemper at gmail.com Wed May 26 10:13:54 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Wed, 26 May 2021 09:13:54 -0500 Subject: Turtle module Message-ID: I recently discovered the turtle module and have been playing around with it for the last few days. I've started writing some functions for turtles, and would like to make them a bit more robustly than what I currently have. In particular, I'd like the state of the turtle to be more or less the same after the function return as it was before the function invocation. In order to turn the turtle, I need to select a way to represent angles. I could use either degrees or radians (or, I suppose, grads). However, for my functions to work, I need to set the turtle to that mode. This means that I could possibly mess up things for the caller. What I would like to do is capture the angle-representation mode on entry and restore it on return. However, looking through the methods of turtle.Turtle(), I can't find any means of capturing this information. Similarly, I'd like to return with the pen in the same state (up or down) as when my functions were called. Again, I can't find any way to query the pen state. How can my function get this information? Or do I need to be sloppy and let the callers beware? -- Michael F. Stemper 2 Chronicles 19:7 From veekm at foo.com Wed May 26 10:45:42 2021 From: veekm at foo.com (Veek M) Date: Wed, 26 May 2021 14:45:42 -0000 (UTC) Subject: Pandas: How does df.apply(lambda work to create a result Message-ID: t = pd.DataFrame([[4,9],]*3, columns=['a', 'b']) a b 0 4 9 1 4 9 2 4 9 t.apply(lambda x: [x]) gives a [[1, 2, 2]] b [[1, 2, 2]] How?? When you 't' within console the entire data frame is dumped but how are the individual elements passed into .apply()? I can't do lambda x,y: [x,y] because only 1 arg is passed so how does [4] generate [[ ]] Also - this: t.apply(lambda x: [x], axis=1) 0 [[139835521287488, 139835521287488]] 1 [[139835521287488, 139835521287488]] 2 [[139835521287488, 139835521287488]] vey weird - what just happened?? In addition, how do I filter data eg: t[x] = t[x].apply(lambda x: x*72.72) I'd like to remove numeric -1 contained in the column output of t[x]. 'filter' only works with labels of indices, i can't do t[ t[x] != -1 ] because that will then generate all the rows and I have no idea how that will be translate to within a .apply(lambda x... (hence my Q on what's going on internally) Could someone clarify please. (could someone also tell me briefly the best way to use NNTP and filter out the SPAM - 'pan' and 'tin' don't work anymore afaik [eternal-september] and I'm using slrn currently - the SLang regex is weird within the kill file - couldn't get it to work - wound up killing everything when I did Subject: [A-Z][A-Z][A-Z]+ ) From rosuav at gmail.com Wed May 26 12:07:19 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 27 May 2021 02:07:19 +1000 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On Thu, May 27, 2021 at 1:59 AM Jon Ribbens via Python-list wrote: > > On 2021-05-26, Alan Gauld wrote: > > On 25/05/2021 23:23, Terry Reedy wrote: > >> In CPython's Flexible String Representation all characters in a string > >> are stored with the same number of bytes, depending on the largest > >> codepoint. > > > > I'm learning lots of new things in this thread! > > > > Does that mean that if I give Python a UTF8 string that is mostly single > > byte characters but contains one 4-byte character that Python will store > > the string as all 4-byte characters? > > > > If so, doesn't that introduce a pretty big storage overhead for > > large strings? > > Memory is cheap ;-) > This is true, but sometimes memory translates into time - either direction. When the Flexible String Representation came in, it was actually an alternative to using four bytes per character on ALL strings (not just those that contain non-BMP characters), and it actually improved performance quite notably, despite some additional complications. Performance optimization is a funny science :) ChrisA From rosuav at gmail.com Wed May 26 12:17:27 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 27 May 2021 02:17:27 +1000 Subject: Turtle module In-Reply-To: References: Message-ID: On Thu, May 27, 2021 at 1:59 AM Michael F. Stemper wrote: > In order to turn the turtle, I need to select a way to represent > angles. I could use either degrees or radians (or, I suppose, > grads). However, for my functions to work, I need to set the > turtle to that mode. This means that I could possibly mess up > things for the caller. What I would like to do is capture the > angle-representation mode on entry and restore it on return. > However, looking through the methods of turtle.Turtle(), I > can't find any means of capturing this information. > > Similarly, I'd like to return with the pen in the same state > (up or down) as when my functions were called. Again, I can't > find any way to query the pen state. > > How can my function get this information? Or do I need to be > sloppy and let the callers beware? For the most part, this is what you want: https://docs.python.org/3/library/turtle.html#turtle.pen It doesn't seem to include the fullcircle state (which is what .degrees() and .radians() set), and I'm not sure why. Worst case, it is technically available as the ._fullcircle member, but I would advise against using that if you can help it! ChrisA From mstemper at gmail.com Wed May 26 12:57:17 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Wed, 26 May 2021 11:57:17 -0500 Subject: Turtle module In-Reply-To: References: Message-ID: On 26/05/2021 11.17, Chris Angelico wrote: > On Thu, May 27, 2021 at 1:59 AM Michael F. Stemper wrote: >> What I would like to do is capture the >> angle-representation mode on entry and restore it on return. >> However, looking through the methods of turtle.Turtle(), I >> can't find any means of capturing this information. >> >> Similarly, I'd like to return with the pen in the same state >> (up or down) as when my functions were called. Again, I can't >> find any way to query the pen state. >> >> How can my function get this information? Or do I need to be >> sloppy and let the callers beware? > > For the most part, this is what you want: > > https://docs.python.org/3/library/turtle.html#turtle.pen Just found the same thing myself and came back to report it. But, immediately after your link is: which seems even better for up/down. > It doesn't seem to include the fullcircle state (which is what > .degrees() and .radians() set), and I'm not sure why. Worst case, it > is technically available as the ._fullcircle member, but I would > advise against using that if you can help it! Well, I'll take your advice and not use it. Seems really sloppy to change an attribute of an object as a side-effect, but I guess that I'll have to be sloppy. Thanks -- Michael F. Stemper Deuteronomy 10:18-19 From tjreedy at udel.edu Wed May 26 13:26:53 2021 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 26 May 2021 13:26:53 -0400 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 5/26/2021 12:07 PM, Chris Angelico wrote: > On Thu, May 27, 2021 at 1:59 AM Jon Ribbens via Python-list > wrote: >> >> On 2021-05-26, Alan Gauld wrote: >>> On 25/05/2021 23:23, Terry Reedy wrote: >>>> In CPython's Flexible String Representation all characters in a string >>>> are stored with the same number of bytes, depending on the largest >>>> codepoint. >>> >>> I'm learning lots of new things in this thread! >>> >>> Does that mean that if I give Python a UTF8 string that is mostly single >>> byte characters but contains one 4-byte character that Python will store >>> the string as all 4-byte characters? Note that while unix uses utf-8, Windows uses utf-16. >>> If so, doesn't that introduce a pretty big storage overhead for >>> large strings? >> >> Memory is cheap ;-) >> > > This is true, but sometimes memory translates into time - either > direction. When the Flexible String Representation came in, it was > actually an alternative to using four bytes per character on ALL > strings (not just those that contain non-BMP characters), Except on Windows, where CPython used 2 bytes/char + surrogates for non-BMP char. This meant that indexing did not quite work on Windows and that applications that allowed astral chars and wanted to work on all systems had to have separate code for Windows and unix-based systems. > and it > actually improved performance quite notably, despite some additional > complications. And it made CPython text manipulation code work on all CPython system. > Performance optimization is a funny science :) -- Terry Jan Reedy From alan.gauld at yahoo.co.uk Wed May 26 13:43:30 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Wed, 26 May 2021 18:43:30 +0100 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: <20210526080901.0fd1f042@bigbox.attlocal.net> References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <20210526080901.0fd1f042@bigbox.attlocal.net> Message-ID: On 26/05/2021 14:09, Tim Chase wrote: >> If so, doesn't that introduce a pretty big storage overhead for >> large strings? > > Yes. Though such large strings tend to be more rare, largely because > they become unweildy for other reasons. I do have some scripts that work on large strings - mainly produced by reading an entire text file into a string using file.read(). Some of these are several MB long so potentially now 4x bigger than I thought. But you are right, even a 100MB string should still be OK on a modern PC with 8GB+ RAM!... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From mstemper at gmail.com Wed May 26 15:15:30 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Wed, 26 May 2021 14:15:30 -0500 Subject: Turtle module In-Reply-To: References: Message-ID: On 26/05/2021 13.24, Stefan Ram wrote: > "Michael F. Stemper" writes: >> What I would like to do is capture the >> angle-representation mode on entry and restore it on return. > another one: > > def f( turtle_ ): > my_turtle = turtle_.clone() > # now work with my_turtle only Oooh, I like this. It's proof against other types of bullets that might come along. > All of the above ideas have *not* been tested. My first test found me with two arrows (turtle icons?) upon return. I immediately realized what caused it, and put t.hideturtle() at the end of my testbed function. Thanks, -- Michael F. Stemper Economists have correctly predicted seven of the last three recessions. From rosuav at gmail.com Wed May 26 17:02:16 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 27 May 2021 07:02:16 +1000 Subject: Turtle module In-Reply-To: References: Message-ID: On Thu, May 27, 2021 at 6:51 AM Michael F. Stemper wrote: > > On 26/05/2021 11.17, Chris Angelico wrote: > > On Thu, May 27, 2021 at 1:59 AM Michael F. Stemper wrote: > > > >> What I would like to do is capture the > >> angle-representation mode on entry and restore it on return. > >> However, looking through the methods of turtle.Turtle(), I > >> can't find any means of capturing this information. > >> > >> Similarly, I'd like to return with the pen in the same state > >> (up or down) as when my functions were called. Again, I can't > >> find any way to query the pen state. > >> > >> How can my function get this information? Or do I need to be > >> sloppy and let the callers beware? > > > > For the most part, this is what you want: > > > > https://docs.python.org/3/library/turtle.html#turtle.pen > > Just found the same thing myself and came back to report it. But, > immediately after your link is: > > which seems even better for up/down. Yeah, if that's the only thing you need. > > It doesn't seem to include the fullcircle state (which is what > > .degrees() and .radians() set), and I'm not sure why. Worst case, it > > is technically available as the ._fullcircle member, but I would > > advise against using that if you can help it! > > Well, I'll take your advice and not use it. Seems really sloppy to > change an attribute of an object as a side-effect, but I guess that > I'll have to be sloppy. > If this matters to you, here's what I'd recommend: Propose that the fullcircle state be added to what pen() returns and can update, and also possibly propose a context manager, so you can do something like this: def f(): with turt.local(): turt.pendown() ... .... # once we get here, the turtle's pen state will have been restored I'm not the person to ask about these, as I don't use the turtle module, but those would seem fairly plausible enhancements. ChrisA From python.list at tim.thechases.com Wed May 26 17:15:38 2021 From: python.list at tim.thechases.com (Tim Chase) Date: Wed, 26 May 2021 16:15:38 -0500 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <20210526080901.0fd1f042@bigbox.attlocal.net> Message-ID: <20210526161538.3e6f018c@bigbox.attlocal.net> On 2021-05-26 18:43, Alan Gauld via Python-list wrote: > On 26/05/2021 14:09, Tim Chase wrote: >>> If so, doesn't that introduce a pretty big storage overhead for >>> large strings? >> >> Yes. Though such large strings tend to be more rare, largely >> because they become unweildy for other reasons. > > I do have some scripts that work on large strings - mainly produced > by reading an entire text file into a string using file.read(). > Some of these are several MB long so potentially now 4x bigger than > I thought. But you are right, even a 100MB string should still be > OK on a modern PC with 8GB+ RAM!... If you don't decode it upon reading it in, it should still be 100MB because it's a stream of encoded bytes. It would only 2x or 4x in size if you decoded that (either as a parameter of how you opened it, or if you later took that string and decoded it explicitly, though now you have the original 100MB byte-string **plus** the 100/200/400MB decoded unicode string). You don't specify what you then do with this humongous string, but for most of my large files like this, I end up iterating over them piecewise rather than f.read()'ing them all in at once. Or even if the whole file does end up in memory, it's usually chunked and split into useful pieces. That could mean that each line is its own string, almost all of which are one-byte-per-char with a couple strings at sporadic positions in the list-of-strings where they are 2/4 bytes per char. -tkc From robertvstepp at gmail.com Wed May 26 19:28:57 2021 From: robertvstepp at gmail.com (boB Stepp) Date: Wed, 26 May 2021 18:28:57 -0500 Subject: Turtle module In-Reply-To: References: Message-ID: On Wed, May 26, 2021 at 10:59 AM Michael F. Stemper wrote: > In order to turn the turtle, I need to select a way to represent > angles. I could use either degrees or radians (or, I suppose, > grads). However, for my functions to work, I need to set the > turtle to that mode. This means that I could possibly mess up > things for the caller. What I would like to do is capture the > angle-representation mode on entry and restore it on return. > However, looking through the methods of turtle.Turtle(), I > can't find any means of capturing this information In the "Tell Turtle's state" section (https://docs.python.org/3/library/turtle.html#tell-turtle-s-state) I would think that you could roll your own function by using your knowledge of the coordinates of where the turtle is at and the turtle.towards(0, 0). By computing your own angle (knowing what units you are using) and comparing with what is returned you should be able to determine what angular units are currently set. HTH! boB Stepp From greg.ewing at canterbury.ac.nz Wed May 26 18:52:40 2021 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 27 May 2021 10:52:40 +1200 Subject: Turtle module In-Reply-To: References: Message-ID: On 27/05/21 4:17 am, Chris Angelico wrote: > Worst case, it > is technically available as the ._fullcircle member, but I would > advise against using that if you can help it! If you're worried about that, you could create your own turle subclass that tracks the state how you want. -- Greg From alan.gauld at yahoo.co.uk Wed May 26 19:17:10 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Thu, 27 May 2021 00:17:10 +0100 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: <20210526161538.3e6f018c@bigbox.attlocal.net> References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <20210526080901.0fd1f042@bigbox.attlocal.net> <20210526161538.3e6f018c@bigbox.attlocal.net> Message-ID: On 26/05/2021 22:15, Tim Chase wrote: > If you don't decode it upon reading it in, it should still be 100MB > because it's a stream of encoded bytes. I usually convert them to utf8. > You don't specify what you then do with this humongous string, Mainly I search for regex patterns which can span multiple lines. I could chunk it up if memory was an issue but a single read is just more convenient. Up until now it hasn't been an issue and to be honest I don't often hit multi-byte characters so mostly it will be single byte character strings. They are mostly research papers and such from my university days written on a Commodore PET and various early DOS computers with weird long-lost word processors. Over the years they've been exported/converted/reimported and then re-xported several times. A very few have embedded text or "graphics"/equations which might have some unicode characters but its not a big issue for me in practice. I was more just thinking of the kinds of scenario where big strings might become a problem if suddenly consuming 4x the storage you expect. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From cs at cskk.id.au Wed May 26 23:54:57 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Thu, 27 May 2021 13:54:57 +1000 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: Message-ID: On 26May2021 12:11, Jon Ribbens wrote: >On 2021-05-26, Alan Gauld wrote: >> I confess I had just assumed the unicode strings were stored >> in native unicode UTF8 format. > >If you do that then indexing and slicing strings becomes very slow. True, but that isn't necessarily a show stopper. My impression, on reflection, is that most slicing is close to the beginning or end of a string, and that _most strings are small. (Alan has exceptions at least to the latter.) In those circumstances, the cost of slicing a variable width encoding is greatly mitigated. Indexing is probably more general (in my subjective hand waving guesstimation). But... how common is indexing into large strings? Versus, say, iteration over a large string? I was surprised when getting introduced to Golang a few years ago that it stores all Strings as UTF8 byte sequences. And when writing Go code, I found very few circumstances where that would actually bring performance issues, which I attribute in part to my suggestions above about when, in practical terms, we slice and index strings. If the internal storage is UTF8, then in an ecosystem where all, or most, text files are themselves UTF8 then reading a text file has zero decoding cost - you can just read the bytes and store them! And to write a String out to a UTF8 file, you just copy the bytes - zero encoding! Also, UTF8 is a funny thing - it is deliberately designed so that you can just jump into the middle of an arbitrary stream of UTF8 bytes and find the character boundaries. That doesn't solve slicing/indexing in general, but it does avoid any risk of producing mojibake just by starting your decode at a random place. Cheers, Cameron Simpson From rosuav at gmail.com Thu May 27 05:32:04 2021 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 27 May 2021 19:32:04 +1000 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] In-Reply-To: References: Message-ID: On Thu, May 27, 2021 at 1:56 PM Cameron Simpson wrote: > > On 26May2021 12:11, Jon Ribbens wrote: > >On 2021-05-26, Alan Gauld wrote: > >> I confess I had just assumed the unicode strings were stored > >> in native unicode UTF8 format. > > > >If you do that then indexing and slicing strings becomes very slow. > > True, but that isn't necessarily a show stopper. My impression, on > reflection, is that most slicing is close to the beginning or end of a > string, and that _most strings are small. (Alan has exceptions at least > to the latter.) In those circumstances, the cost of slicing a variable > width encoding is greatly mitigated. > > Indexing is probably more general (in my subjective hand waving > guesstimation). But... how common is indexing into large strings? > Versus, say, iteration over a large string? Common enough that, when all this was originally discussed, O(1) indexing and slicing was mandated. It wasn't until MicroPython came along that it was even entertained as a possibility that O(n) slicing could be reasonable. > I was surprised when getting introduced to Golang a few years ago that > it stores all Strings as UTF8 byte sequences. And when writing Go code, > I found very few circumstances where that would actually bring > performance issues, which I attribute in part to my suggestions above > about when, in practical terms, we slice and index strings. > > If the internal storage is UTF8, then in an ecosystem where all, or > most, text files are themselves UTF8 then reading a text file has zero > decoding cost - you can just read the bytes and store them! And to write > a String out to a UTF8 file, you just copy the bytes - zero encoding! True. IF everything is indeed in the same encoding. > Also, UTF8 is a funny thing - it is deliberately designed so that you > can just jump into the middle of an arbitrary stream of UTF8 bytes and > find the character boundaries. That doesn't solve slicing/indexing in > general, but it does avoid any risk of producing mojibake just by > starting your decode at a random place. Yes, that's true, you can avoid mojibake. But you still can't easily say "which is the 505005th character". The only way for it to work is to have some kind of string reference type that carries both the character index and the byte position, and is capable of arithmetic; and now we're into the messes of pointer manipulation. Whichever way you do it, you're just moving the mess around. ChrisA From hw at adminart.net Thu May 27 12:42:43 2021 From: hw at adminart.net (hw) Date: Thu, 27 May 2021 18:42:43 +0200 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: Message-ID: On 5/26/21 12:25 AM, Cameron Simpson wrote: > On 25May2021 19:21, hw wrote: >> On 5/25/21 11:38 AM, Cameron Simpson wrote: >>> On 25May2021 10:23, hw wrote: >>>> if status != 'OK': >>>> print('Login failed') >>>> exit >>> >>> Your "exit" won't do what you want. I expect this code to raise a >>> NameError exception here (you've not defined "exit"). That _will_ abort >>> the programme, but in a manner indicating that you're used an unknown >>> name. You probably want: >>> >>> sys.exit(1) >>> >>> You'll need to import "sys". >> >> Oh ok, it seemed to be fine. Would it be the right way to do it with >> sys.exit()? Having to import another library just to end a program >> might not be ideal. > > To end a programme early, yes. (sys.exit() actually just raises a > particular exception, BTW.) > > I usually write a distinct main function, so in that case one can just > "return". After all, what seems an end-of-life circumstance in a > standalone script like yours is just an "end this function" circumstance > when viewed as a function, and that also lets you _call_ the main > programme from some outer thing. Wouldn't want that outer thing > cancelled, if it exists. > > My usual boilerplate for a module with a main programme looks like this: > > import sys > ...... > def main(argv): > ... main programme, return like any other function ... > .... other code for the module - functions, classes etc ... > if __name__ == '__main__': > sys.exit(main(sys.argv)) > > which (a) puts main(0 up the top where it can be seen, (b) makes main() > an ordinary function like any other (c) lets me just import that module > elsewhere and (d) no globals - everything's local to main(). > > The __name__ boilerplate at the bottom is the magic which figures out if > the module was imported (__name__ will be the import module name) or > invoked from the command line like: > > python -m my_module cmd-line-args... > > in which case __name__ has the special value '__main__'. A historic > mechanism which you will convince nobody to change. Thanks, that seems like good advice. > You'd be surprised how useful it is to make almost any standalone > programme a module like this - in the medium term it almost always pays > off for me. Even just the discipline of shoving all the formerly-global > variables in the main function brings lower-bugs benefits. What do you do with it when importing it? Do you somehow design your programs as modules in some way that makes them usable as some kind of library funktion? >>> I've done little with IMAP. What's in msgnums here? Eg: >>> print(type(msgnums), repr(msgnums)) >>> just so we all know what we're dealing with here. >> >> [b''] >> >>>> message_uuids = [] >>>> for number in str(msgnums)[3:-2].split(): >>> >>> This is very strange. [...] >> Yes, and I don't understand it. 'print(msgnums)' prints: >> >> [b''] >> >> when there are no messages and >> >> [b'1 2 3 4 5'] > > Chris has addressed this. msgnums is list of the data components of the > IMAP response. By going str(msgnums) you're not getting "the message > numbers as text" you're getting what printing a list prints. Which is > roughly Python code: the brakcets and the repr() of each list member. Well, of course I exepect to get message numbers returned from such a library function, not the raw imap response. What is the library for when I have to figure it all out by myself anyway. > Notice that the example code accessed msgnums[0] - that is the first > data component, a bytes. That you _can_ convert to a string (under > assumptions about the encoding). And of course, I don't want to randomly convert bytes into strings ... > By getting the "str" form of a list, you're forced into the weird [3:-2] > hack to ttrim the ends. But it is just a hack for a transcription > mistake, not a sane parse. Right, thats why I don't like it and is part of what makes it so unwieldy. >> So I was guessing that it might be an array containing a single a >> string and that refering to the first element of the array turns into >> a string with which split() can used. But 'print(msgnums[0].split())' >> prints >> >> [b'1', b'2', b'3', b'4', b'5'] > > msgnums[0] is bytes. You can do most str things with bytes (because that > was found to be often useful) but you get bytes back from those > operations as you'd hope. As someone unfamiliar with python, I was wondering what this output means. It could be items of an array that are bytes containing numbers, like, in binary, 00000001, 00000010, and so on. That's more like what I would expect and not something I would want to convert into a string. >> so I can only guess what that's supposed to mean: maybe an array of >> many bytes? The documentation[1] clearly says: "The message_set >> options to commands below is a string [...]" > > But that is the parameter to the _call_: your '(UID)' parameter. No, it's not a uid. With library, I haven't found a way to get uids. The function to call reqires a string, not bytes or an array of bytes. The included example contradicts the documentation and leaves potential users of the library to guessing. >> I also need to work with message uids rather than message numbers >> because the numbers can easily change. There doesn't seem to be a way >> to do that with this library in python. > > By asking for UIDs you're getting uids. Do they not work in subsequent > calls? How do you force the library to give uids instead of message numbers, and how do you make it do something with a particular message by uid? >> So it's all guesswork, and I gave up after a while and programmed what >> I wanted in perl. The documentation of this library sucks, and there >> are worlds between it and the documentation for the libraries I used >> with perl. > > I think you're better of looking for another Python imap library. The > imaplib was basic functionality to (a) access the rpotocol in basic form > and (b) conceal the async stuff, since IMAP is an asynchronous protocol. > > You can in fact subclass it to do better things. Other library might do > thatm or they might have written their own protocol implementations. I haven't really found a better one. >> That doesn't mean I don't want to understand why this is so unwieldy. >> It's all nice and smooth in perl. > > But using what library? Something out of CPAN? Those are third party > libraries, not Perl's presupplied stuff. The libraries I used with perl all come with Fedora, so they are presupplied and only need to be installed. You can find them on cpan as well. It's very convenient. > The equivalent for Python is > pypi.org. Look there. Yes, someone pointed it out, and I did. They have an imap-tools library which looks most promising at first, and its documentation tells me that you do can some IMAP operations with messages --- and nothing with messages themselves, like getting from the server. So it seems that IMAP support through python is virtually non-existent. >>> It is just breaking apart data[0] into strings which were separated by >>> whitespace in the response. And then using those same strings as keys >>> for the .fecth() call. That doesn't seem complex, and in fact is blind >>> to the format of the "message numbers" returned. It just takes what it >>> is handed and uses those to fetch each message. >> >> That's not what the documentation says. > > The _example code_ is blind to them, whatever the semantics of the docs. > It just gets the uids and fetches with them. Aside from .split(), > there's no parsing or deep understanding of the uid. There is no telling what might happen to the messages when using functions that randomly convert bytes in weird ways and that contradict the documentation. Why would I trust this library not to accidentially delete all my emails or to not do other harmful things? >>> IMAP's quite complex. Have you read RFC2060? >>> >>> https://datatracker.ietf.org/doc/html/rfc2060.html >> >> Yes, I referred to it and it didn't become any more clear in >> combination with the documentation of the python library. > > IMAP's like that :-) IMAP seems fine :) >>> The imaplib library is probably a fairly basic wrapper for the >>> underlying protocol which provides methods for the basic client requests >>> and conceals the asynchronicity from the user for ease of (basic) use. >> >> Skip Montanaro seems to say that the byte problem comes from the >> change from python 2 to 3 and there is a better library now: >> https://pypi.org/project/IMAPClient/ > > And someone mentioned imaplib2. There are several choices. Does that exist? pypi.org says the project description is unknown, so I didn't look closer. ... Hm, ok there's git repo that seems to be alive and it even has some documentation. >> But the documentation seems even more sparse than the one for imaplib. >> Is it a general thing with python that libraries are not well >> documented? > > That depends on the library - it is of course at the whim of the > developer. Heavily used powerful libraries are usually well documented, > eg numpy. A random hacker's published module? Might have nothing. Well, gajim seems to be using an xmpp library for which there is no documentation ... Other than that, is there a documented xmpp library for python which is useful? In particular, I'd like to have an xmpp library that implements HTTP file upload because that's missing from the perl libraries, and I haven't been able to figure out how to implement it myself. > Wrappers for protocols like IMAP might have a bit of doco and expect the > useful to infer stuff from knowledge of the protocol itself. The perl libraries do that. > [...] >>> Anyway, the IMAP response are bytes containing text. You get a lot of >>> bytes. >> >> Well, ok, but it's not helpful that b is being inserted like >> everywhere, > > Only when you _print_ them. That "b" is an idicator that this is a bytes > object being printed in a stringlike form because that is often a useful > representation. Nothings inserting a "b" in the data itself. I was just trying to do something to get the return of one function of the library usable as the input for another function of the same library, and that involved random conversations of bytes into strings (which may work in one case and can go wrong at any time) ... I can't help thinking that a library which is incompatible with itself isn't really a good library ... >> and I have to keep asking myself what I'm looking at because bytes are >> bytes. > > If you've got b'abc', that is a printout of a 3 byte string. _Not_ the > string itself. Who says it's a string? RFC 3501 is quite specific in section 2.2: "All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF.", and it describes what strings are in section 4.3. I would say a library that gives me responses from an IMAP server as bytes --- which could be anything --- rather than strings is not giving me what I can expect and probably does something wrong. Of course, I could read the source code of the library, but that pretty much defeats the point of using a library. >> Since the documentation is so bad, I had to figure it out by trial and >> error and by printing stuff and making guesses and assumptions. >> That's just not the way to program something. > > No. But _many_ modules are what the original author needed to get > something done, and neither complete nor perfectly documented. Life's > too short. Well used module tend to become more complete, elegant and > documented over time, _if_ people other than the author use them. Right. Fortunately, perl offers good libraries for the purpose, so I used those instead. >>> When you go: >>> >>> text = str(data) >>> >>> that is _assuming_ a particular text encoding stored in the data. You >>> really ought to specify an encoding here. If you've not specified the >>> CHARSET for things, 'ascii' would be a conservative choice. The IMAP RFC >>> talks about what to expect in section 4 (Data Formats). There's quite a >>> lot of possible response formats and I can understand imaplib not >>> getting deeply into decoding these. >> >> UTF8 is the default since quite a while now. Why doesn't it just use that? > > "since quite a while now" is pretty vague. Look at the date on RFC2060, > and remember that that is version 4 of the protocol, _after_ a time > consuming standardisation process. So subtract several years from that. > > Regardless, _assuming_ that arbitrary bytes are UTF8 is error prone and > foolhardy and will lead to mojibake. If a protocol specifies a UTF8 > encoding, you're good. Otherwise you need to find out what is actually > going on. Some protocols are old enough to assume the world is ASCII. > Some take a less rigid view that they're processing "text" at all, for > all that their contents are effectively text. > > Notice that the RFC specifies that strings are 7-bit text except in > certain circumstances. And those strings are probably ASCII. Fortunately, the perl libraries just gave me uids when I asked for them, and I didn't have to worry about anything :) >> Then its documentation should at least specify what the library does. > > It mostly does, and that doing is relatively basic. Does it say it > provides high level post parsed data structures? No. It describes what > it gets back from tehh IMAP responses, and further/deeper parse is up to > the user. Who is free to subclass the IMAP class and add such parsing. > Or to find or write a more Pythonic module (==> one with more normal > Python idoms and working in Python classes like str more than in bytes). > But the _protocol_ passes bytes data around. It doesn't really ... >>> So having passed '(UID)' to the SEARCH request, you now need to parse >>> the response. >> >> First I have to guess what the response might be ... And once I >> manged that, there's still no way to do something with a message by >> its uid. > > You can print the response, then look at the RFC to understand what it > is and how to parse it. > > But this is grittiness you're not interested in, which means you need to > look for a higher level library. Right, and this isn't good for someone who has just begun to learn python and has no idea what he does. Maybe I'll find something better suited to learning. From jimpoulopoulos at gmail.com Thu May 27 02:22:09 2021 From: jimpoulopoulos at gmail.com (=?UTF-8?B?zpTOl86czpfOpM6hzpnOn86jIM6gzp/Opc6bzp/OoM6fzqXOm86fzqM=?=) Date: Thu, 27 May 2021 09:22:09 +0300 Subject: Problem with pip installation Message-ID: Good morning. I have o Windows 10 system and i can install pip. I try to follow the instruction that i find on internet but the did not work. Also itry to write the command pip install pip but again did not work. Also the command py..... did not work. Thank you! -- Yours sincerely Dimitris From loris.bennett at fu-berlin.de Thu May 27 05:28:11 2021 From: loris.bennett at fu-berlin.de (Loris Bennett) Date: Thu, 27 May 2021 11:28:11 +0200 Subject: Data structure for plotting monotonically expanding data set Message-ID: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> Hi, I currently a have around 3 years' worth of files like home.20210527 home.20210526 home.20210525 ... so around 1000 files, each of which contains information about data usage in lines like name kb alice 123 bob 4 ... zebedee 9999999 (there are actually more columns). I have about 400 users and the individual files are around 70 KB in size. Once a month I want to plot the historical usage as a line graph for the whole period for which I have data for each user. I already have some code to extract the current usage for a single from the most recent file: for line in open(file, "r"): columns = line.split() if len(columns) < data_column: logging.debug("no. of cols.: %i less than data col", len(columns)) continue regex = re.compile(user) if regex.match(columns[user_column]): usage = columns[data_column] logging.info(usage) return usage logging.error("unable to find %s in %s", user, file) return "none" Obviously I will want to extract all the data for all users from a file once I have opened it. After looping over all files I would naively end up with, say, a nested dict like {"20210527": { "alice" : 123, , ..., "zebedee": 9999999}, "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9}, "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 9999999}, "20210524": { "alice" : 123, ..., "zebedee": 9}, "20210523": { "alice" : 123, ..., "zebedee": 9999999}, ...} where the user keys would vary over time as accounts, such as 'bob', are added and latter deleted. Is creating a potentially rather large structure like this the best way to go (I obviously could limit the size by, say, only considering the last 5 years)? Or is there some better approach for this kind of problem? For plotting I would probably use matplotlib. Cheers, Loris -- This signature is currently under construction. From edmondo.giovannozzi at gmail.com Thu May 27 11:55:11 2021 From: edmondo.giovannozzi at gmail.com (Edmondo Giovannozzi) Date: Thu, 27 May 2021 08:55:11 -0700 (PDT) Subject: Data structure for plotting monotonically expanding data set In-Reply-To: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> References: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> Message-ID: <5b2c8611-a7e2-4d15-8361-d171d8b4acafn@googlegroups.com> Il giorno gioved? 27 maggio 2021 alle 11:28:31 UTC+2 Loris Bennett ha scritto: > Hi, > > I currently a have around 3 years' worth of files like > > home.20210527 > home.20210526 > home.20210525 > ... > > so around 1000 files, each of which contains information about data > usage in lines like > > name kb > alice 123 > bob 4 > ... > zebedee 9999999 > > (there are actually more columns). I have about 400 users and the > individual files are around 70 KB in size. > > Once a month I want to plot the historical usage as a line graph for the > whole period for which I have data for each user. > > I already have some code to extract the current usage for a single from > the most recent file: > > for line in open(file, "r"): > columns = line.split() > if len(columns) < data_column: > logging.debug("no. of cols.: %i less than data col", len(columns)) > continue > regex = re.compile(user) > if regex.match(columns[user_column]): > usage = columns[data_column] > logging.info(usage) > return usage > logging.error("unable to find %s in %s", user, file) > return "none" > > Obviously I will want to extract all the data for all users from a file > once I have opened it. After looping over all files I would naively end > up with, say, a nested dict like > > {"20210527": { "alice" : 123, , ..., "zebedee": 9999999}, > "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9}, > "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 9999999}, > "20210524": { "alice" : 123, ..., "zebedee": 9}, > "20210523": { "alice" : 123, ..., "zebedee": 9999999}, > ...} > > where the user keys would vary over time as accounts, such as 'bob', are > added and latter deleted. > > Is creating a potentially rather large structure like this the best way > to go (I obviously could limit the size by, say, only considering the > last 5 years)? Or is there some better approach for this kind of > problem? For plotting I would probably use matplotlib. > > Cheers, > > Loris > > -- > This signature is currently under construction. Have you tried to use pandas to read the data? Then you may try to add a column with the date and then join the datasets. From hjp-python at hjp.at Thu May 27 13:03:53 2021 From: hjp-python at hjp.at (Peter J. Holzer) Date: Thu, 27 May 2021 19:03:53 +0200 Subject: Data structure for plotting monotonically expanding data set In-Reply-To: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> References: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> Message-ID: <20210527170353.GA1117@hjp.at> On 2021-05-27 11:28:11 +0200, Loris Bennett wrote: > I currently a have around 3 years' worth of files like > > home.20210527 > home.20210526 > home.20210525 > ... > > so around 1000 files, each of which contains information about data > usage in lines like > > name kb > alice 123 > bob 4 > ... > zebedee 9999999 > > (there are actually more columns). I have about 400 users and the > individual files are around 70 KB in size. > > Once a month I want to plot the historical usage as a line graph for the > whole period for which I have data for each user. [...] > Obviously I will want to extract all the data for all users from a file > once I have opened it. After looping over all files I would naively end > up with, say, a nested dict like > > {"20210527": { "alice" : 123, , ..., "zebedee": 9999999}, > "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9}, > "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 9999999}, > "20210524": { "alice" : 123, ..., "zebedee": 9}, > "20210523": { "alice" : 123, ..., "zebedee": 9999999}, > ...} > > where the user keys would vary over time as accounts, such as 'bob', are > added and latter deleted. > > Is creating a potentially rather large structure like this the best way > to go (I obviously could limit the size by, say, only considering the > last 5 years)? I don't think that would be a problem. However, I assume that you want to create one graph per user, not a single graph with 400 lines (that would be very cluttered). So I would swap the levels around: { "alice": { "20210527": 123, "20210526": 123, ... }, "bob": { "20210526": 3, "20210525", 1, ... }, "zebedee": { "20210527": 9999999, "20210526": 9, ... } } That way you have the data for each graph grouped together. It might also be a good idea to use actual date objects instead of strings. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hjp-python at hjp.at Thu May 27 14:02:57 2021 From: hjp-python at hjp.at (Peter J. Holzer) Date: Thu, 27 May 2021 20:02:57 +0200 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: <20210527180257.GB1117@hjp.at> On 2021-05-26 08:34:28 +1000, Chris Angelico wrote: > Yes, any given string has a single width, which makes indexing fast. > The memory cost you're describing can happen, but apart from a BOM > widening an otherwise-ASCII string to 16-bit, there aren't many cases > where you'll get a single wide character in a narrow string. A single emoji in a long English text. > Usually, if there are any wide characters, there'll be a good number > of them Oh, right. People who use emoji usually use a lot of them ?. hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rosuav at gmail.com Thu May 27 14:06:01 2021 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 28 May 2021 04:06:01 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: <20210527180257.GB1117@hjp.at> References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> <20210527180257.GB1117@hjp.at> Message-ID: On Fri, May 28, 2021 at 4:04 AM Peter J. Holzer wrote: > > On 2021-05-26 08:34:28 +1000, Chris Angelico wrote: > > Yes, any given string has a single width, which makes indexing fast. > > The memory cost you're describing can happen, but apart from a BOM > > widening an otherwise-ASCII string to 16-bit, there aren't many cases > > where you'll get a single wide character in a narrow string. > > A single emoji in a long English text. > > > Usually, if there are any wide characters, there'll be a good number > > of them > > Oh, right. People who use emoji usually use a lot of them ?. > > Exactly :) I can easily imagine a short block of text with just one (say, a single email), but if you have a gigabyte or even a couple hundred meg of text, the chances of *a single* emoji become vanishingly slim. ChrisA From hw at adminart.net Thu May 27 14:29:31 2021 From: hw at adminart.net (hw) Date: Thu, 27 May 2021 20:29:31 +0200 Subject: learning python ... In-Reply-To: <01b701d7512a$b689cf00$239d6d00$@verizon.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: When the idea is to learn something, it's not exactly helpful to abandon that idea when encountering the first obstacle or when someone tells you you don't like it as much as they do ... On 5/25/21 7:56 AM, Avi Gross via Python-list wrote: > I have studied many programming languages and am amused when people attack python as if every other language is somehow more optimal. > > Cameron and others have provided examples but look at positives AND negatives. > > Yes code like: num = int(num) > > does look a tad off as it reuses the same name for something that is actually in many ways different. You could easily use a new name. But then you would have TWO variables in your name space and the old one would not be garbage collected unless you explicitly removed it. If you follow this path, would you suggest not writing: X = X + 1 either? > > It is actually a fairly common practice in many languages to have code like this: > > Var = read in something from a file and make some structure like a data.frame > Var = remove some columns from the above thing pointed to by Var > Var = make some new calculated columns ditto > Var = remove some rows ... > Var = set some kind of grouping on the above or sort it and so on. > > As you go along you may keep transforming but have no need for earlier results, just the new and improved one. So why keep changing names? Some languages support not having any names for intermediate results by using nested function calls or pipelines. > > The reality is that most languages have a series of what I loosely would call environments or name tables and as they run, new ones regularly get created and removed and even the order of them may change. The algorithm for searching for a name varies and can be in some sense linear or more complex. When looking in context for a function name, you may follow a different trail or the same one as for a variable holding a string and in some implementations the same name shadows and in others does not. Wait till you try to figure out the diamond pattern of inheritance when you create classes that depend on multiple other classes ad nauseum and you try to call a method and it tries to find the one you wanted by searching backwards in an interesting way. Many other languages decided to just not allow multiple inheritance! > > How can you write a recursive function without this kind of variable shadowing? Each invocation of a function places the internal namespace in front of the parent so the meaning of a variable name used within is always backed by all the iterations before it. But with some kinds of closures, a function may be gone and yet variables it had within it persists. Lots of odd examples more make this a complex set of CHOICES. > > So what if you suggest we allow re-use of names but WARN you. OK, Python is a largely interpreted language. Normally if you ask to use a variable called X, it starts a search in the nearest place then the next one and so on till it finds it or fails. In many programs, variables are fairly local and found easily. But if you want, you can search dozens or hundreds of places and find each and every use of X visible at THIS moment and tell the user there are 82 places it can be seen and here they are. Now what? The first 50 places may be in other instances of the recursive function and you have already been warned this way 49 times and soon will be warned a few more as it continues to recurse as it travels down a tree or graph structure quite legitimately. Some of the other places X may be in use are in some package in a part you are not even using indirectly or in middle of a for-loop as a token variable and so on. I suspect that 99.99% of the time re-using a name has no negative consequence. Making someone keep choosing names like X12346 because there is somewhere an X12345 seems a tad silly. But why go to all that expense at run-time versus in some lint program? > > I recently studied a language called GO that goes to some length to protect the user from themselves and often at great expense to getting programming done. It won't compile a program if it declares a variable and does not use it. Fair enough but I often want to write a sort of shell of a program and check as I go to make sure it works before adding more. If I will need 5 variables, I might declare them up-front then work on interactions and calculations that only include some of them and later I plan on connecting the rest. Nope, it won't let me unless I use it as in a print statement or comment it out or just remove it. Ah, but then it is not happy I did not initialize it so I set it to zero or something. Later, when I finally use it as intended, I need to remove the junk. > > Some of this annoyance is so common that they had to come up with a way to shut it up. Consider this line: > > Result, err = functionA(args) > > It returns two arguments. Sometimes it seems silly to worry about the error but you MUST write a line of code like: > > If (err != nil) { > Do_something > } > > Other times you just care if it worked and don't want the result. So placing an _ for one or the other is a signal to shut the darn compiler up that you are DELIBERATELY ignoring the return value you did not want! > > There are many other places the darn thing tries to protect you and insists you write code the hard way. Some are not unreasonable and some I argue are. Their method of trapping errors deliberately chose to not do the fairly common try/catch method lest it make programmers stop worrying about causing a panic, for example, or even depending on it. Their switch statement does not flow through to the next item because they worry people might forget the break statement so instead, they have a way to specify when you want execution to fall through. This last one is an example maybe of something more reasonable. > > So, yes, there are languages with philosophies that may help users avoid some common mistakes. Use them if you wish. But some of these have a longer learning curve and generate lots of frustration and may make some people stop learning to program because it takes forever to get something to compile, let alone run. > > In my experience, often the work-around they supply to do things is far more complex than just providing some freedom and hoping you do not abuse it. In interpreted languages, you can really do some weird things if you know more, including access to the actual names of variables and the ability to change them on the fly and so on and yes, the ability to make weird mistakes. > > There can be a happy medium. Supply a function call a user can place anywhere in the code that asks if there is an "X" defined at this point in time before they use it. And, if there is, tell me about all of them as in if I remove one X, is there now another. But will that work the way you want so you can choose another name if that bothers you? > > My guess is no. The same function containing your test might be called from somewhere else in your code and there is does mask something or is masked deeper. You may be using modules that change with some new release and have variables that now conflict with yours. Some identifiers are so common that the order you load packages/modules may determine which one is uppermost. > > I often program in R and I do get messages when say a function called select() in package B is loaded and shadow the same name in package A or the base. If it matters, I am free to call A::select() or B::select so the names no longer clash at that point or I use other techniques. So dynamic changes as packages are updated are possible even if my lint method once declared things to be fine. So should we force people to use fully qualified names like the above or worse? > > Python is not perfect, Frankly, a good chunk of the features in python added to it as an interpreted language seem to work pretty well in various compiled languages I have studied. Many features do not require the interpreter and can now be done in other ways. Designers make choices and some are a matter of taste. Arguably Python is best for things like prototyping or even learning but arguably it is not as efficient for programs that run fairly simple algorithms constantly where running faster or using less memory can mean major savings. So, yes, often a program written in Python and shown to work, may be rewritten. But the opposite can be true as people give up trying to use a restrictive environment when the needs keep changing and a more flexible scripting language allows rapid changes. > > Python is not designed or planned the way some want and if that bothers them, use something else when told by others that the language was designed to do what it is supposed to and needs no change. > > On another forum someone is asking for R to not have just an NA variable when something is missing, but as many variants as needed to record why it is missing such as ILLEGIBLE or DELAYED or RAN_OUT_OF_TIME and so on. The claim is that many social science applications need this and some other programs/languages sort of support it. Fair enough but again, the design way-back-when saw no need for this and lots of drawbacks and although we brainstormed lots of ideas on how to attach metadata to a vector to support this, it often breaks down as most existing functions toss it away so you may have to redo tons of code very carefully to preserve the data or even reapply it after a change. Something as simple as converting a vector from character strings to their integer values will drop the changes. So, again, if this is that important, use something else and do NOT suggest diddling with unused bits in one implementation of NA to store your additional metadata as there is no guarantee it will get the result you want and it is not a documented guaranteed implementation and may break lots of other existing code. > > I am not discouraging anyone from asking questions and even suggesting changes. I simply suggest when others push back and tell you it was designed this way for darn good reasons and many LIKE IT the way it is, ... > > > -----Original Message----- > From: Python-list On Behalf Of Cameron Simpson > Sent: Monday, May 24, 2021 5:34 AM > To: python-list at python.org > Subject: Re: learning python ... > > On 24May2021 08:21, hw wrote: >> On 5/24/21 12:03 AM, Cameron Simpson wrote: >>> On 23May2021 21:02, Stestagg wrote: >>>> On Sun, 23 May 2021 at 20:37, hw wrote: >>>>> I don't know about shadowing. >>>> >>>> Shadowing is effectively saying ?within this bit of code, (scope) I?m >>>> going to use an already-used name for my own value? >>> >>> An example might make this clearer: >>> >>> x = 1 # global variable >>> >>> def f(a): >>> x = a * 2 >>> return x >>> >>> Inside the function f() the name 'x" shadows the global "x"; >>> references to "x" are to the function's local vairable. Which is very desireable. >> >> If it works that way, I would consider it an entirely different >> variable. Is there a way to access the global x from within a function >> without transferring it through parameters of the function? >> Than can also sometimes be useful. > > Sure. You can declare a name like this: > > def f(a): > global x # find x in the global namespace (the module) > x = a * 2 > return x > > This is pretty rare and usually discouraged. Of there are times when it is useful. > > Note that in this function: > > x = 1 > y = 2 > > def f(a): > x = 3 > print(x, y) > > "x" is local, because the function contains an assignment to it. "y" > comes from an outer scope (in this case, the global scope) because there's no assignment to it. > >>> As Stestagg has mentioned, there are also tools called linters which >>> warn you about issues like this. Tools like pyflakes, pylint, >>> pycodestyle all inspect your code for a wide variety of potential >>> errors and discouraged habits. Not to mention tools like mypy which >>> do type validation. >> >> So you're saying one can't really go without those unless you want to >> take the risk? > > Self restraint and developing good habits does 99% of the work. Linters are great for catching various accidents. > > [...] >> I'm not saying it shouldn't be allowed to defeat or to re-define stuff, >> only that it shouldn't go through quietly. > > Well, most of us use linters to exhibit that noise, rather than requiring the code to be littered with special directives. > > I usually code without much linter fuss until I've got the latest batch of work (eg feature or fix) ready, commit the changes, then lint vigorously and commit that polish before merging with the main line of code. > > Finally, consider this code: > > num = input("Enter a number: ") > num = int(num) > > input() returns a string, which would need converting to a number before some numeric stuff. Plenty of people write the above. To my mind, this is also a kind of shadowing, and I like this instead: > > num_s = input("Enter a number: ") > num = int(num_s) > > where the "_s" indicates quietly that this variable holds a string. > > Is that shadowing to your mind? Or not? If yes, should the language emit noise there, too? Remembering that Python _values_ are strongly typed, though the variables are not (a variable might reference any kind of object, as above). > > I wouldn't say that your opinion would be wrong regardless of what side of this question you come down on, but Python's chosen a side: noise for nonsensical things, but not noise for dubious things. But plenty of linters to complain about dubious things. > > Cheers, > Cameron Simpson > -- > https://mail.python.org/mailman/listinfo/python-list > From torriem at gmail.com Thu May 27 14:56:03 2021 From: torriem at gmail.com (Michael Torrie) Date: Thu, 27 May 2021 12:56:03 -0600 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: Message-ID: <43e286af-360c-1b5d-91a5-1fe17c40df84@gmail.com> On 5/27/21 10:42 AM, hw wrote: > What do you do with it when importing it? Do you somehow design your > programs as modules in some way that makes them usable as some kind of > library funktion? Yes, precisely. Typically I break up my python projects into logical modules, which are each kind of like a library in their own right. The if __name__=="__main__" idiom is really handy for this. It lets me build testing into each module. If I run the module directly, it can execute tests on the functions in that module. If it's imported, the code inside the if __name__=="__main__" block is not executed. Sometimes I'll have a python file that can run standalone, using command-line arguments, or be imported by something else and used that. All depends on my needs at the moment, but this mechanism is very powerful. Note that any py file is loaded and executed when imported. So any module-level initialization code gets run whether a file is imported or run directly (which is why the if __name__=="__main__" idiom works). From hw at adminart.net Thu May 27 14:59:47 2021 From: hw at adminart.net (hw) Date: Thu, 27 May 2021 20:59:47 +0200 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: <9ed3376e-69fc-89f3-2178-6f56e0610fc4@adminart.net> On 5/25/21 3:09 PM, Greg Ewing wrote: > On 25/05/21 5:56 pm, Avi Gross wrote: >> Var = read in something from a file and make some structure like a >> data.frame >> Var = remove some columns from the above thing pointed to by Var >> Var = make some new calculated columns ditto >> Var = remove some rows ... >> Var = set some kind of grouping on the above or sort it and so on. > > As long as all the values are of the same type, this isn't too bad, > although it might interfere with your ability to give the intermediate > results names that help the reader understand what they refer to. > > A variable that refers to things of different *types* at different > times is considerably more confusing, both for a human reader and > for any type checking software you might want to use. How would this matter when the variables are typeless? Often times, it's not very practical to figure out the type of a value before assigning it to a variable ... >> How can you write a recursive function without this kind of variable >> shadowing? Each invocation of a function places the internal namespace >> in front of the parent so the meaning of a variable name used within >> is always backed by? all the iterations before it. > > Um, no. What you're describing is called "dynamic scoping", and > Python doesn't have it. Python is *lexically* scoped, meaning that > only scopes that textually enclose the function in the source are > searched for names. Frames on the call stack don't come into it. > >> So what if you suggest we allow re-use of names but WARN you. ... The >> first 50 places may be in other instances of the recursive function >> and you have already been warned this way 49 times > > If this were to be done, the shadowing would be detected at compile > time, so you would only be warned once. Works fine in perl (and you can have it without warnings if you want to, though that's not recommended): perl -e 'use warnings; my $shadow; my $shadow; my $shadow'; "my" variable $shadow masks earlier declaration in same scope at -e line 1. "my" variable $shadow masks earlier declaration in same scope at -e line 1. "Mask" seems like a much better word for this than "shadow" ... From hw at adminart.net Thu May 27 15:08:22 2021 From: hw at adminart.net (hw) Date: Thu, 27 May 2021 21:08:22 +0200 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: <21fb6c5f-97a4-654b-887f-2c31a549bcbe@adminart.net> Message-ID: On 5/25/21 3:55 PM, Grant Edwards wrote: > On 2021-05-25, hw wrote: > >> I'm about to do stuff with emails on an IMAP server and wrote a program >> using imaplib > > My recollection of using imaplib a few years ago is that yes, it is > unweildy, oddly low-level, and rather un-Pythonic (excuse my > presumption in declaring what is and isn't "Pythonic"). It's good to know that it's not me and that I simply made a bad pick for something to learn python with :) > I switched to using imaplib2 and found it much easier to use. It's a > higher-level wrapper for imaplib. > > I think this is the currently maintained fork: > > https://github.com/jazzband/imaplib2 > > I haven't activly used either for several years, so things may have > changed... > > -- > Grant > From hjp-python at hjp.at Thu May 27 15:16:05 2021 From: hjp-python at hjp.at (Peter J. Holzer) Date: Thu, 27 May 2021 21:16:05 +0200 Subject: learning python ... In-Reply-To: <9ed3376e-69fc-89f3-2178-6f56e0610fc4@adminart.net> References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> <9ed3376e-69fc-89f3-2178-6f56e0610fc4@adminart.net> Message-ID: <20210527191605.GA2304@hjp.at> On 2021-05-27 20:59:47 +0200, hw wrote: > On 5/25/21 3:09 PM, Greg Ewing wrote: > > On 25/05/21 5:56 pm, Avi Gross wrote: > > > Var = read in something from a file and make some structure like a > > > data.frame > > > Var = remove some columns from the above thing pointed to by Var > > > Var = make some new calculated columns ditto > > > Var = remove some rows ... > > > Var = set some kind of grouping on the above or sort it and so on. > > > > As long as all the values are of the same type, this isn't too bad, > > although it might interfere with your ability to give the intermediate > > results names that help the reader understand what they refer to. > > > > A variable that refers to things of different *types* at different > > times is considerably more confusing, both for a human reader and > > for any type checking software you might want to use. > > How would this matter when the variables are typeless? It doesn't matter for Python. It does matter for some people - especially those that think that variables have (or should have) a type. Of course "type checking software" follows that paradigm. > Often times, it's not very practical to figure out the type of a value > before assigning it to a variable ... In statically typed languages (like C, Java, Go, ...) you have to do that. In dynamically typed languages like Python you don't and in general can't. > > > How can you write a recursive function without this kind of variable > > > shadowing? Each invocation of a function places the internal > > > namespace in front of the parent so the meaning of a variable name > > > used within is always backed by? all the iterations before it. > > > > Um, no. What you're describing is called "dynamic scoping", and > > Python doesn't have it. Python is *lexically* scoped, meaning that > > only scopes that textually enclose the function in the source are > > searched for names. Frames on the call stack don't come into it. > > > > > So what if you suggest we allow re-use of names but WARN you. ... > > > The first 50 places may be in other instances of the recursive > > > function and you have already been warned this way 49 times > > > > If this were to be done, the shadowing would be detected at compile > > time, so you would only be warned once. > > Works fine in perl (and you can have it without warnings if you want to, > though that's not recommended): > > > perl -e 'use warnings; my $shadow; my $shadow; my $shadow'; > "my" variable $shadow masks earlier declaration in same scope at -e line 1. > "my" variable $shadow masks earlier declaration in same scope at -e line 1. That's something different. Here you are redeclaring the same variable in the same scope (Note that this cannot happen in Python because you don't declare variables in Python). If you write something like this: -------------------- #!/usr/bin/perl use v5.12; use warnings; my $x = 5; { my $x = 10; say $x; } say $x; -------------------- You won't get a warning, and the program will print -- 10 5 -- But dynamic scope is something different. It's based on the call stack, not syntax. In Perl, you get dynamically scoped variables with local. This is quite deprecated and mostly used to temporarily shadow predefined variables like $/ (although I've occasionally used it for other purposes, too). hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp at hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mats at wichmann.us Thu May 27 18:15:08 2021 From: mats at wichmann.us (Mats Wichmann) Date: Thu, 27 May 2021 16:15:08 -0600 Subject: Problem with pip installation In-Reply-To: References: Message-ID: <08379f4b-d479-28c5-1a3a-4650fbcf13a9@wichmann.us> On 5/27/21 1:08 PM, Dennis Lee Bieber wrote: > On Thu, 27 May 2021 09:22:09 +0300, ????????? ??????????? > declaimed the following: > >> Good morning. I have o Windows 10 system and i can install pip. I try to >> follow the instruction that i find on internet but the did not work. Also >> itry to write the command pip install pip but again did not work. Also the >> command py..... did not work. Thank you! > > "did not work" is meaningless... cut&paste the exact text from your > console window (not an image grab) with the commands you are entering and > the messages that you get... > > Is the location of pip on your Windows PATH environment variable? > > python -m pip Python knows how to find the pip that goes with it - these days it's not at all uncommon to have several Pythons on a system. Windows pythons are always initialized with pip these days so this is reliable. I'm sure you've read every bit of advice on the internet already, but make sure you've looked over this one: https://docs.python.org/3/using/windows.html From cs at cskk.id.au Thu May 27 19:21:41 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Fri, 28 May 2021 09:21:41 +1000 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: Message-ID: On 27May2021 18:42, hw wrote: >On 5/26/21 12:25 AM, Cameron Simpson wrote: >>On 25May2021 19:21, hw wrote: >>>On 5/25/21 11:38 AM, Cameron Simpson wrote: >>>>On 25May2021 10:23, hw wrote: >>You'd be surprised how useful it is to make almost any standalone >>programme a module like this - in the medium term it almost always pays >>off for me. Even just the discipline of shoving all the formerly-global >>variables in the main function brings lower-bugs benefits. > >What do you do with it when importing it? Do you somehow design your >programs as modules in some way that makes them usable as some kind of >library funktion? Michael Torrie addressed this. In short, inspecting __name__ tells you if your module was run as a main programme or imported. That's what the test for '__main__' checks. So modules like this tend to be: module code .... if __name__ == '__main__': run as a command line main programme And I personally spell that last line as: sys.exit(main(sys.argv)) and define a main() function near the top of the module. >>Chris has addressed this. msgnums is list of the data components of >>the >>IMAP response. By going str(msgnums) you're not getting "the message >>numbers as text" you're getting what printing a list prints. Which is >>roughly Python code: the brakcets and the repr() of each list member. > >Well, of course I exepect to get message numbers returned from such a >library function, not the raw imap response. What is the library for >when I have to figure it all out by myself anyway. The library, for this particular library: - conceals the async side, giving you plain request=>response function calls - parses the response in its generic structural form and hands you the components It's a relatively thin shim for the IMAP protocol itself, not a fully fledged mailbox parser. Since the search function can return many many weird and wonderful things depending what you ask it for, this particular library (a) does not parse the search field parameter ('(UID)') or the responses. It passes them through and 9b) correspondingly does not interpret the result beyond unpacking the IMAP response into the data packets provided. What you really want is a "search_uids()" function, which calls .search() with '(UID)' _and_ parses the particular style of ressponse that '(UID)' produces from a server. imaplib doesn't have that, and that is a usability deficiency. It could do with a small suite of convenience/helper functions that call the core IMAP methods in particular commonly used ways. >>Notice that the example code accessed msgnums[0] - that is the first >>data component, a bytes. That you _can_ convert to a string (under >>assumptions about the encoding). > >And of course, I don't want to randomly convert bytes into strings ... Well, you don't need to. Splitting on "whitespace" is enough - you then have a list of individual UID bytes objects, which can probably be passed areound opaquely - you don't ordinarily need to _care_ that they're bytes transcriptions of the server numeric UID _values_ - you can at that point just treat them as tokens. >>By getting the "str" form of a list, you're forced into the weird [3:-2] >>hack to ttrim the ends. But it is just a hack for a transcription >>mistake, not a sane parse. > >Right, thats why I don't like it and is part of what makes it so unwieldy. Bear with me - I'm going to be quite elaborate here. That _particular_ problem is because you transcribed a list-of-bytes-objects as a string (as Python would have printed such a thing with the print() function). It's just the wrong thing to do here, regardless of the language. Consider (at the Python interactive ">>> " prompt): >>> nums = [1, 2, 3] A list of ints. print(nums) outputs: >>> print(nums) [1, 2, 3] print() works by writing out str() of each of its arguments. So the above is a string written to the output. Looking at str(): >>> str(nums) '[1, 2, 3]' It's a string, with a leading '[' character, a decimal transcription of the numeric values with ', ' between those transcriptions, and a trailing ']' character. The single quotes above are the interactive interpreter printing that Python str value using repr(), as you would type it to a Python programme. To do what you did with the msgnums I'd go: str(nums)[1:-1].split(', ') which would get me a list of str values. But that cumbersomeness is because of the str(nums), which turned nums into a string transcription of the list of values. Let's do the equivalent with a made up IMAP search response: msgnums = [b'123 456 789'] The above, I gather, is the source of your [3:-2] thing: trim the "b['" and "']" markers. I'm using msgnums here because you named it that way, but the response from a search() is actually a list of data components. For search('(UID)') that list one has one element, the bytes data component with UIDs transcribed within it. This structured response is what you were not expecting. Any IMAP response, syntacticly, contains multiple data parts. Depending on the call those parts might contain UIDs of messages or parts of messages, etc. So... Your particular .search() returns _one_ response. But the library is handing you a generic form - they _could_ be multiple responses. You did a search for '(UID)', so you get one response with these UIDs: 123 456 789 but it is a bytes object (I'll get to the IMAP standard's "string" term versus a Python str later. They're not synonyms. So the bytes with the UIDs is msgnums[0] in the search) result. You went str(msgnums), which transibes a list as you would write it in Python code. You actually want (a) msgnums[0], which is the bytes containing the UIDs and (b) to parse those bytes into UIDs for use later. So: uids_bs = msgnums[0] # get the data part you want uids = uids_bs.split() # split it on whitespace, pretending it is like ASCII That works because the IMAP RFC specifies that the result of a '(UID)' search is an IMAP string containing space separated UIDs. At this point "uids" is a list of bytes objects, like this: b['123', 'b'456', b'789'] I'm faily sure you don't need to care that these are representations of numbers at this point - you could pass them around as tokens. Let me read from the imaplib module doco: IMAP4 Objects All IMAP4rev1 commands are represented by methods of the same name, either upper-case or lower-case. All arguments to commands are converted to strings, [...] That means you _could_ pass in bytes later - treat the UIDs bytes objects as tokens. _Or_ you could convert them to ints: uid_bses = msgsnums[0].split() uids = [ int(str(uid_bs)) for uid_bs in uid_bses ] Courtesy of the "All arguments to commands are converted to strings" above, probably you can use them as ints in subsequent calls and imaplib will turn them into strs for the protocol, likely using str(). >>>So I was guessing that it might be an array containing a single a >>>string and that refering to the first element of the array turns into >>>a string with which split() can used. But 'print(msgnums[0].split())' >>>prints >>> >>>[b'1', b'2', b'3', b'4', b'5'] Yes. but that's _printed_. It is just an array of bytes values: b'1' b'2' b'3' b'4' b'5' and _those_ are just what they're be as _printed_. They're just single byte values >As someone unfamiliar with python, I was wondering what this output >means. It could be items of an array that are bytes containing >numbers, like, in binary, 00000001, 00000010, and so on. That's more >like what I would expect and not something I would want to convert into >a string. Yeah, this is just transcription, as you would need to express these values in a Python programme. The values themselves _are_ what you think above, but more precisely: 0b00110001 0b00110010 0b00110011 0b00110100 0b00110101 ("0b" is the Python numeric prefix indicating binary notation.) because these bytes are still "text": the decimal digits '1' and so forth in ASCII. Because IMAP itself returns you text (well, bytes containing text, text containing decimal transcriptions of UID numeric values). If you want the numeric values you want this transformation of the .search() response: [0] get the first (and only) data bytes response .split() treat it like ASCII and break it up on spaces, producing a list of bytes objects, one per value [ int(str(uid_bs)) for uid_bs in uid_bses ] this is probably optional - the bytes objects above are probably useable directly later: for each bytes object, convert it to str and convert that str to an int That would get you numeric values from decimal bytes transcriptions. I still suspect you needn't bother with this with the imaplib module. After those, you have a list of UID-as-bytes or UID-as-int depending on whether you did step 3 above. >>>so I can only guess what that's supposed to mean: maybe an array of >>>many bytes? The documentation[1] clearly says: "The message_set >>>options to commands below is a string [...]" >> >>But that is the parameter to the _call_: your '(UID)' parameter. > >No, it's not a uid. With library, I haven't found a way to get uids. I describe this in detail above. I agree a .search_uids() convenience method would be nice, but it's a 3 line function you could write yourself. >The function to call reqires a string, not bytes or an array of bytes. No. The library docs say it converts arguments _to_ strings for you. You could (probably) pass it ints, strs or bytes for UIDs and all would work. >The included example contradicts the documentation and leaves >potential users of the library to guessing. No, you're missing the conversion facility documented right at the top of the IMAP object specs. >>>I also need to work with message uids rather than message numbers >>>because the numbers can easily change. There doesn't seem to be a way >>>to do that with this library in python. >> >>By asking for UIDs you're getting uids. Do they not work in subsequent >>calls? > >How do you force the library to give uids instead of message numbers, >and how do you make it do something with a particular message by uid? You force the _protocol_ to give you UIDs by passing '(UID)' to the seach function: that tells the IMAP _server_ to return UIDs as the search result. You can then pass the UID you receive to other functions which will accept a UID. I seem to recall that the IMAP protocol specifies that UID numbers have a distinct numeric range from message numbers, so probably the server can figure out if it was given a message number or a UID number on its own without more context. So you would not need to specify that you're using message number of UIDs explicitly. >>You can in fact subclass it to do better things. Other library might >>do >>thatm or they might have written their own protocol implementations. > >I haven't really found a better one. That's a shame. Ther'es lots of Python stuff using IMAP out there. For example the getmail, imapsync and mbsync tools all speak IMAP using Python. Maybe look at them. >>>That doesn't mean I don't want to understand why this is so unwieldy. >>>It's all nice and smooth in perl. >> >>But using what library? Something out of CPAN? Those are third party >>libraries, not Perl's presupplied stuff. >The libraries I used with perl all come with Fedora, so they are >presupplied and only need to be installed. You can find them on cpan >as well. It's very convenient. Here you are confused. Fedora is a Linux distro, and supplies many third party CPAN modules _as_ perl-this perl-that packages. You will probably find it _also_ supplies many PyPI modules as python-this python-that etc. They're _still_ third party packages not part of the core Perl or Python languages themselves. Fedora's doing a lot of work here for you. >>The equivalent for Python is >>pypi.org. Look there. > >Yes, someone pointed it out, and I did. They have an imap-tools >library which looks most promising at first, and its documentation >tells me that you do can some IMAP operations with messages --- and >nothing with messages themselves, like getting from the server. > >So it seems that IMAP support through python is virtually non-existent. This still sureprises me, but I've not tried to use IMAP seriously. I read email locally, and collect it with POP instead. With a tool I wrote myself in Python, as it happens. [...] >There is no telling what might happen to the messages when using >functions that randomly convert bytes in weird ways and that contradict >the documentation. Why would I trust this library not to accidentially >delete all my emails or to not do other harmful things? Because you're not calling the .delete() method? Just guessing here. [...] >>>and I have to keep asking myself what I'm looking at because bytes >>>are >>>bytes. >> >>If you've got b'abc', that is a printout of a 3 byte string. _Not_ the >>string itself. > >Who says it's a string? > >RFC 3501 is quite specific in section 2.2: "All interactions >transmitted by client and server are in the form of lines, that is, >strings that end with a CRLF.", and it describes what strings are in >section 4.3. Yeah, but read it again. When the IMAP RFC says strings, it means a sequence of octets suitably delineated. It DOES NOT say the strings are _text_. They come in 2 forms: a "quoted string" delineated by ASCII double quote bytes and a run length encoded form where the length of the string of octets is specified by a leading {length} ASCII length indicator. They are NOT TEXT STRINGS. Many of them _contain_ text. >I would say a library that gives me responses from an IMAP server as >bytes --- which could be anything --- rather than strings is not >giving me what I can expect and probably does something wrong. It isn't giving you what you expect.. But by _not_ deeply parsing the octet strings returned from the server, it AVOIDS doing something wrong - it leaves those accidents to you. Bytes are bytes, but that means they're meaningless without context. IMAP "strings" are strings of octets - arbitrary binary data. The octet strings for particular responses have defined transcriptions of things in them. So when you call .search() you get back a single octet string, and Python represents such a string as a Python bytes object, which is just a string of octets. You only get to decode that as a space seperated ASCII transcription of decimal transcribed UUID numeric values _because_ you passed '(UID)' to the search() call. If you'd passed something else the data response would contain differently shaped binary data requiring different decoding. The imaplib library does not parse the '(UID)' (or whatever) search parameter itself and perform a matching response decode - the possibilities are quite complex. >Right. Fortunately, perl offers good libraries for the purpose, so I >used those instead. And that's perfectly reasonable. >Fortunately, the perl libraries just gave me uids when I asked for >them, and I didn't have to worry about anything :) That is convenient. Good to hear. >Right, and this isn't good for someone who has just begun to learn >python and has no idea what he does. Maybe I'll find something better >suited to learning. Yes, I think so. The fairly basic imaplib module combined with the quite complex IMAP protocol is a poor starting point - there's just too much going on to use it as a starting-to-learn-Python scenario. Oh, when you go to xmpp etc, look at the Python "requests" module (PyPI again). Python has a urllib module shipped, but it again is fairly basic. The 'requests" module is almost universally what people use to do HTTP stuff. "pip install requests" and off you go. Cheers, Cameron Simpson From robertvstepp at gmail.com Thu May 27 20:36:47 2021 From: robertvstepp at gmail.com (boB Stepp) Date: Thu, 27 May 2021 19:36:47 -0500 Subject: imaplib: is this really so unwieldy? In-Reply-To: References: Message-ID: On Thu, May 27, 2021 at 6:22 PM Cameron Simpson wrote: > > On 27May2021 18:42, hw wrote: > >So it seems that IMAP support through python is virtually non-existent. > > This still sureprises me, but I've not tried to use IMAP seriously. I > read email locally, and collect it with POP instead. With a tool I wrote > myself in Python, as it happens. I am out of my league here, but what I found in one of my books might be helpful. Al Sweigart wrote a useful book, "Automate the Boring Stuff in Python". In chapter 16 he considers email. In the "IMAP" section he states: Just as SMTP is the protocol for sending email, the Internet Message Access Protocol (IMAP) specifies how to communicate with an email provider?s server to retrieve emails sent to your email address. Python comes with an imaplib module, but in fact the third-party imapclient module is easier to use. This chapter provides an introduction to using IMAPClient; the full documentation is at http://imapclient.readthedocs.org/. The imapclient module downloads emails from an IMAP server in a rather complicated format. Most likely, you?ll want to convert them from this format into simple string values. The pyzmail module does the hard job of parsing these email messages for you. You can find the complete documentation for PyzMail at http://www.magiksys.net/pyzmail/. Install imapclient and pyzmail from a Terminal window. Appendix A has steps on how to install third-party modules. In the next little section he shows how to retrieve and delete emails with IMAP using the two third-party tools mentioned above. And of course there is more. Apparently this book is now in its second edition. The first edition is available online for free. The link to chapter 16 which discusses email is: https://automatetheboringstuff.com/chapter16/ Hopefully this will prove helpful to the OP. HTH! boB Stepp From PythonList at DancesWithMice.info Thu May 27 20:40:24 2021 From: PythonList at DancesWithMice.info (dn) Date: Fri, 28 May 2021 12:40:24 +1200 Subject: Data structure for plotting monotonically expanding data set In-Reply-To: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> References: <878s40h6fo.fsf@hornfels.zedat.fu-berlin.de> Message-ID: <57afea5c-03dd-c1d2-ca12-ca849107997c@DancesWithMice.info> On 27/05/2021 21.28, Loris Bennett wrote: > Hi, > > I currently a have around 3 years' worth of files like > > home.20210527 > home.20210526 > home.20210525 > ... > > so around 1000 files, each of which contains information about data > usage in lines like > > name kb > alice 123 > bob 4 > ... > zebedee 9999999 > > (there are actually more columns). I have about 400 users and the > individual files are around 70 KB in size. > > Once a month I want to plot the historical usage as a line graph for the > whole period for which I have data for each user. > > I already have some code to extract the current usage for a single from > the most recent file: > > for line in open(file, "r"): > columns = line.split() > if len(columns) < data_column: > logging.debug("no. of cols.: %i less than data col", len(columns)) > continue > regex = re.compile(user) > if regex.match(columns[user_column]): > usage = columns[data_column] > logging.info(usage) > return usage > logging.error("unable to find %s in %s", user, file) > return "none" > > Obviously I will want to extract all the data for all users from a file > once I have opened it. After looping over all files I would naively end > up with, say, a nested dict like > > {"20210527": { "alice" : 123, , ..., "zebedee": 9999999}, > "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9}, > "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 9999999}, > "20210524": { "alice" : 123, ..., "zebedee": 9}, > "20210523": { "alice" : 123, ..., "zebedee": 9999999}, > ...} > > where the user keys would vary over time as accounts, such as 'bob', are > added and latter deleted. > > Is creating a potentially rather large structure like this the best way > to go (I obviously could limit the size by, say, only considering the > last 5 years)? Or is there some better approach for this kind of > problem? For plotting I would probably use matplotlib. NB I am predisposed to use databases. People without such skills will likely feel the time-and-effort investment to learn uneconomic for such a simple, single, example! Because the expressed concern seems to be the size of the data-set, (one assumes) only certain users' data will be graphed (at one time). Another concern may be that every time the routine executes, it repeats the bulk of its regex-based processing. I would establish a DB with (at least, as appropriate) two tables: one the list of files from which the data has been extracted, and the second containing the data currently formatted as a dict. NB The second may benefit from stating in "normal form" or splitting into related tables, and certainly indexing. Thus the process requires two steps: firstly to capture the data (from the files) into the DB, and secondly to graph the appropriate groups or otherwise 'chosen' users. SQL will simplify data retrieval, and feeding into matplotlib (or whichever tool). It will also enable simple improvements both to select sub-sets of users or to project over various periods of time. YMMV! -- Regards, =dn From cs at cskk.id.au Thu May 27 20:45:04 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Fri, 28 May 2021 10:45:04 +1000 Subject: Pandas: How does df.apply(lambda work to create a result In-Reply-To: References: Message-ID: Disclaimer: I haven't actually used pandas. On 26May2021 14:45, Veek M wrote: >t = pd.DataFrame([[4,9],]*3, columns=['a', 'b']) > a b >0 4 9 >1 4 9 >2 4 9 I presume you've printed "t" here. So the above table is str(t). Or possibly repr(t) if you were at the interactive prompt. It is a human readable printout of "t". >t.apply(lambda x: [x]) gives >a [[1, 2, 2]] >b [[1, 2, 2]] >How?? When you 't' within console the entire data frame is dumped but how are >the individual elements passed into .apply()? The doco for .apply seems to be here: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.apply.html When you go "t.apply(....)", the class implementing "t" has its .apply() method called - this is what does the work. So "t" is a DataFrame, so you're calling DataFrame.apply as documented at the above link. From the output, I expect that it takes each row in the DataFrame and passed it to the lambda function, and produces a single column value from the result, in the end creating a new single column DataFrame. The docs suggets you can do more than that, also. >I can't do lambda x,y: [x,y] >because only 1 arg is passed so how does [4] generate [[ ]] Because your lambda: lambda x: [x] is passed the whole row, which is a list. You're returning a single element list containing that list. If you know the rows have exactly 2 values you could do this: lambda x: [x[0]*2, x[1]*3] to get the first column multiplied by 2 and the second by 3. You might do better to write your lambda like this: lambda row: [row] just so that it is clear that you're getting the whole row rather than some single element from the row. >Also - this: > t.apply(lambda x: [x], axis=1) >0 [[139835521287488, 139835521287488]] >1 [[139835521287488, 139835521287488]] >2 [[139835521287488, 139835521287488]] >vey weird - what just happened?? See the docs above for the effect the axis parameter has on _how_ .apply does its work. >In addition, how do I filter data eg: t[x] = t[x].apply(lambda x: x*72.72) I'd >like to remove numeric -1 contained in the column output of t[x]. 'filter' only >works with labels of indices, i can't do t[ t[x] != -1 ] because that will then >generate all the rows and I have no idea how that will be translate to >within a .apply(lambda x... (hence my Q on what's going on internally) It looks like the .fliter method accepts an items parameter indicating which axis labels to keep. Use axis=0 to filter on the rows instead of the columns. Maybe something shaped like this? t.filter(axis=0, items=[ label for label in t.labels if t[label][0] != -1 ]).apply(.....) That looks pretty cumbersome and also requires a way to get the labels of "t", which I just made up as "t.labels". And I'm just guessing that "t[label][0]" might get you the cell value you want to test against -1. I expect there's a cleaner way to do this. >(could someone also tell me briefly the best way to use NNTP and filter >out the SPAM - 'pan' and 'tin' don't work anymore afaik >[eternal-september] and I'm using slrn currently - the SLang regex is >weird within the kill file - couldn't get it to work - wound up killing >everything when I did >Subject: [A-Z][A-Z][A-Z]+ >) I confess I subscribe to the python-list mailing list, not the newsgroup. It has much much less spam, and the two are gatewayed so you can particpate either way. For example, you've posted to the newsgroup and I'm seeing your post in the mailing list. Likewise my reply will be going to the mailing list and copied to the newsgroup. Come on over to the mailing list. It is rumoured to be much quieter. Cheers, Cameron Simpson From mstemper at gmail.com Thu May 27 17:28:50 2021 From: mstemper at gmail.com (Michael F. Stemper) Date: Thu, 27 May 2021 16:28:50 -0500 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: On 27/05/2021 16.13, Christian Gollwitzer wrote: > Am 25.05.21 um 06:08 schrieb hw: >> On 5/25/21 12:37 AM, Greg Ewing wrote: >>> Python does have references to *objects*. All objects live on >>> the heap and are kept alive as long as there is at least one >>> reference to them. >>> >>> If you rebind a name, and it held the last reference to an >>> object, there is no way to get that object back. >> >> Are all names references?? When I pass a name as a parameter to a >> function, does the object the name is referring to, when altered by >> the function, still appear altered after the function has returned?? I >> wouldn't expect that ... > The strange thing, coming from a different language, is the apparent > difference, if instead of a list, you pass an integer: > > def f(a): > ????a=5 > > l=3 > > f(l) > print(l) > > ====> 3 > > Here, the "l" is not changed. The reason is that the statement "a=5" > does NOT modify the object in a, but instead creates a new one and binds > it to a. l still points to the old one. Whereas a.append() tells the > object pointed to by a to change. What was fun in Fortran was that you could do the following: CALL SS(3) PRINT *, 3 END SUBROUTINE SS(K) K = 5 RETURN END The output of this gem would be 5, at least though Fortran 77. It was call by reference, even for constants. (Every manual said not to do this, of course.) -- Michael F. Stemper Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read. From auriocus at gmx.de Thu May 27 17:13:37 2021 From: auriocus at gmx.de (Christian Gollwitzer) Date: Thu, 27 May 2021 23:13:37 +0200 Subject: learning python ... In-Reply-To: References: <2ba5b89e-df8c-df0f-5a18-57852aa3a8bb@adminart.net> Message-ID: Am 25.05.21 um 06:08 schrieb hw: > On 5/25/21 12:37 AM, Greg Ewing wrote: >> Python does have references to *objects*. All objects live on >> the heap and are kept alive as long as there is at least one >> reference to them. >> >> If you rebind a name, and it held the last reference to an >> object, there is no way to get that object back. > > Are all names references?? When I pass a name as a parameter to a > function, does the object the name is referring to, when altered by the > function, still appear altered after the function has returned?? I > wouldn't expect that ... > Yes, it does. It is a common pitfall for newbie Python programmers. def f(a): a.append(2) l=[1, 2, 3] f(l) print(l) ==> [1, 2, 3, 2] The strange thing, coming from a different language, is the apparent difference, if instead of a list, you pass an integer: def f(a): a=5 l=3 f(l) print(l) ====> 3 Here, the "l" is not changed. The reason is that the statement "a=5" does NOT modify the object in a, but instead creates a new one and binds it to a. l still points to the old one. Whereas a.append() tells the object pointed to by a to change. Christian From ethan at stoneleaf.us Thu May 27 23:23:29 2021 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 27 May 2021 20:23:29 -0700 Subject: name for new Enum decorator Message-ID: Greetings! The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements into a decorator instead, and I'm having a hard time thinking up a name. What is the behavior? Well, a name in a flag type can be either canonical (it represents one thing), or aliased (it represents two or more things). To use Color as an example: class Color(Flag): RED = 1 # 0001 GREEN = 2 # 0010 BLUE = 4 # 0100 PURPLE = RED | BLUE # 0101 WHITE = RED | GREEN | BLUE # 0111 The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are aliases for certain flag combinations. But what if we have something like: class Color(Flag): RED = 1 # 0001 BLUE = 4 # 0100 WHITE = 7 # 0111 As you see, WHITE is an "alias" for a value that does not exist in the Flag (0010, or 2). That seems like it's probably an error. But what about this? class FlagWithMasks(IntFlag): DEFAULT = 0x0 FIRST_MASK = 0xF FIRST_ROUND = 0x0 FIRST_CEIL = 0x1 FIRST_TRUNC = 0x2 SECOND_MASK = 0xF0 SECOND_RECALC = 0x00 SECOND_NO_RECALC = 0x10 THIRD_MASK = 0xF00 THIRD_DISCARD = 0x000 THIRD_KEEP = 0x100 Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values that don't exist, but it seems intentional and not an error. So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but I have no idea what to call it. Any nominations? -- ~Ethan~ From 2QdxY4RzWzUUiLuE at potatochowder.com Fri May 28 00:06:13 2021 From: 2QdxY4RzWzUUiLuE at potatochowder.com (2QdxY4RzWzUUiLuE at potatochowder.com) Date: Thu, 27 May 2021 23:06:13 -0500 Subject: name for new Enum decorator In-Reply-To: References: Message-ID: On 2021-05-27 at 20:23:29 -0700, Regarding "name for new Enum decorator," Ethan Furman wrote: > Greetings! > > The Flag type in the enum module has had some improvements, but I find it > necessary to move one of those improvements into a decorator instead, and > I'm having a hard time thinking up a name. > > What is the behavior? Well, a name in a flag type can be either canonical > (it represents one thing), or aliased (it represents two or more things). > To use Color as an example: > > class Color(Flag): > RED = 1 # 0001 > GREEN = 2 # 0010 > BLUE = 4 # 0100 > PURPLE = RED | BLUE # 0101 > WHITE = RED | GREEN | BLUE # 0111 > > The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are > aliases for certain flag combinations. But what if we have something like: > > class Color(Flag): > RED = 1 # 0001 > BLUE = 4 # 0100 > WHITE = 7 # 0111 > > As you see, WHITE is an "alias" for a value that does not exist in the Flag > (0010, or 2). That seems like it's probably an error. But what about this? > > class FlagWithMasks(IntFlag): > DEFAULT = 0x0 > > FIRST_MASK = 0xF > FIRST_ROUND = 0x0 > FIRST_CEIL = 0x1 > FIRST_TRUNC = 0x2 > > SECOND_MASK = 0xF0 > SECOND_RECALC = 0x00 > SECOND_NO_RECALC = 0x10 > > THIRD_MASK = 0xF00 > THIRD_DISCARD = 0x000 > THIRD_KEEP = 0x100 > > Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are > aliasing values that don't exist, but it seems intentional and not an error. > > So, like the enum.unique decorator that can be used when duplicate names > should be an error, I'm adding a new decorator to verify that a Flag has no > missing aliased values that can be used when the programmer thinks it's > appropriate... but I have no idea what to call it. > > Any nominations? Exhaustive? I see two qualitatively different kinds of enums: those that can/should be "or"ed together (e.g., RED, GREEN) and those that cannot (e.g., FIRST_ROUND, FIRST_CEIL, and FIRST_TRUNC). The idea of a "missing" value doesn't seem to apply to the second type (because defining FIRST_TRUNC as FIRST_ROUND | FIRST_CEIL is nonsensical). I don't quite know what that may or may not suggest as far as names go, but it may give someone else an idea. From avigross at verizon.net Fri May 28 00:36:01 2021 From: avigross at verizon.net (Avi Gross) Date: Fri, 28 May 2021 00:36:01 -0400 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: <049901d7537a$f6ad3160$e4079420$@verizon.net> HomeWork, Nobody is suggesting that you change your attitude because of one obstacle. But what if EVERYBODY here gives you similar feedback that python IS the way it is irrelevant of what other language designers have chosen or you expect? Even if you propose a change that might be nice but it would break lots of existing programs, do you think it likely it would be done and time soon when the 2.x to 3.x transition has been so traumatic to some? The reality is that you are here as a potential USER of Python or some other language and probably have not read enough about Python methods and features to be able to make the judgements you make. You do not seem able to handle some aspects of abstraction such as why you might want to write code that allows you to make some arbitrary changes. Wait till you find out how you can use Python to change the meaning of "+" to mean "-" or anything else you want. But that same feature might let you redefine addition of two objects of a string-like nature to mean concatenation with a comma and space between them or whatever. Clearly I can now conclude it is not worth continuing to do more discussion with you. I am not learning anything and neither are you, apparently. So you go do whatever it is you want and I will ignore and do something potentially of minimal use. I have plenty of things in Python I am not thrilled with at times but I see that it is what it is. So, I use other languages for places where I see them as better or easier. But even when I do not love some feature, I do generally know why it is like it is and that generally someone else wanted it that way. It might be for efficiency or because it was easier to program it that way or even that my preferred way has problems I was not aware of. But generally, most languages have been fairly well thought-out with specific ideas in mind and are in many ways FINISHED albeit can often grow later. -----Original Message----- From: Python-list On Behalf Of hw Sent: Thursday, May 27, 2021 2:30 PM To: python-list at python.org Subject: Re: learning python ... When the idea is to learn something, it's not exactly helpful to abandon that idea when encountering the first obstacle or when someone tells you you don't like it as much as they do ... On 5/25/21 7:56 AM, Avi Gross via Python-list wrote: > I have studied many programming languages and am amused when people attack python as if every other language is somehow more optimal. > > Cameron and others have provided examples but look at positives AND negatives. > > Yes code like: num = int(num) > > does look a tad off as it reuses the same name for something that is actually in many ways different. You could easily use a new name. But then you would have TWO variables in your name space and the old one would not be garbage collected unless you explicitly removed it. If you follow this path, would you suggest not writing: X = X + 1 either? > > It is actually a fairly common practice in many languages to have code like this: > > Var = read in something from a file and make some structure like a > data.frame Var = remove some columns from the above thing pointed to > by Var Var = make some new calculated columns ditto Var = remove some > rows ... > Var = set some kind of grouping on the above or sort it and so on. > > As you go along you may keep transforming but have no need for earlier results, just the new and improved one. So why keep changing names? Some languages support not having any names for intermediate results by using nested function calls or pipelines. > > The reality is that most languages have a series of what I loosely would call environments or name tables and as they run, new ones regularly get created and removed and even the order of them may change. The algorithm for searching for a name varies and can be in some sense linear or more complex. When looking in context for a function name, you may follow a different trail or the same one as for a variable holding a string and in some implementations the same name shadows and in others does not. Wait till you try to figure out the diamond pattern of inheritance when you create classes that depend on multiple other classes ad nauseum and you try to call a method and it tries to find the one you wanted by searching backwards in an interesting way. Many other languages decided to just not allow multiple inheritance! > > How can you write a recursive function without this kind of variable shadowing? Each invocation of a function places the internal namespace in front of the parent so the meaning of a variable name used within is always backed by all the iterations before it. But with some kinds of closures, a function may be gone and yet variables it had within it persists. Lots of odd examples more make this a complex set of CHOICES. > > So what if you suggest we allow re-use of names but WARN you. OK, Python is a largely interpreted language. Normally if you ask to use a variable called X, it starts a search in the nearest place then the next one and so on till it finds it or fails. In many programs, variables are fairly local and found easily. But if you want, you can search dozens or hundreds of places and find each and every use of X visible at THIS moment and tell the user there are 82 places it can be seen and here they are. Now what? The first 50 places may be in other instances of the recursive function and you have already been warned this way 49 times and soon will be warned a few more as it continues to recurse as it travels down a tree or graph structure quite legitimately. Some of the other places X may be in use are in some package in a part you are not even using indirectly or in middle of a for-loop as a token variable and so on. I suspect that 99.99% of the time re-using a name has no negative consequence. Making someone keep choosing names like X12346 because there is somewhere an X12345 seems a tad silly. But why go to all that expense at run-time versus in some lint program? > > I recently studied a language called GO that goes to some length to protect the user from themselves and often at great expense to getting programming done. It won't compile a program if it declares a variable and does not use it. Fair enough but I often want to write a sort of shell of a program and check as I go to make sure it works before adding more. If I will need 5 variables, I might declare them up-front then work on interactions and calculations that only include some of them and later I plan on connecting the rest. Nope, it won't let me unless I use it as in a print statement or comment it out or just remove it. Ah, but then it is not happy I did not initialize it so I set it to zero or something. Later, when I finally use it as intended, I need to remove the junk. > > Some of this annoyance is so common that they had to come up with a way to shut it up. Consider this line: > > Result, err = functionA(args) > > It returns two arguments. Sometimes it seems silly to worry about the error but you MUST write a line of code like: > > If (err != nil) { > Do_something > } > > Other times you just care if it worked and don't want the result. So placing an _ for one or the other is a signal to shut the darn compiler up that you are DELIBERATELY ignoring the return value you did not want! > > There are many other places the darn thing tries to protect you and insists you write code the hard way. Some are not unreasonable and some I argue are. Their method of trapping errors deliberately chose to not do the fairly common try/catch method lest it make programmers stop worrying about causing a panic, for example, or even depending on it. Their switch statement does not flow through to the next item because they worry people might forget the break statement so instead, they have a way to specify when you want execution to fall through. This last one is an example maybe of something more reasonable. > > So, yes, there are languages with philosophies that may help users avoid some common mistakes. Use them if you wish. But some of these have a longer learning curve and generate lots of frustration and may make some people stop learning to program because it takes forever to get something to compile, let alone run. > > In my experience, often the work-around they supply to do things is far more complex than just providing some freedom and hoping you do not abuse it. In interpreted languages, you can really do some weird things if you know more, including access to the actual names of variables and the ability to change them on the fly and so on and yes, the ability to make weird mistakes. > > There can be a happy medium. Supply a function call a user can place anywhere in the code that asks if there is an "X" defined at this point in time before they use it. And, if there is, tell me about all of them as in if I remove one X, is there now another. But will that work the way you want so you can choose another name if that bothers you? > > My guess is no. The same function containing your test might be called from somewhere else in your code and there is does mask something or is masked deeper. You may be using modules that change with some new release and have variables that now conflict with yours. Some identifiers are so common that the order you load packages/modules may determine which one is uppermost. > > I often program in R and I do get messages when say a function called select() in package B is loaded and shadow the same name in package A or the base. If it matters, I am free to call A::select() or B::select so the names no longer clash at that point or I use other techniques. So dynamic changes as packages are updated are possible even if my lint method once declared things to be fine. So should we force people to use fully qualified names like the above or worse? > > Python is not perfect, Frankly, a good chunk of the features in python added to it as an interpreted language seem to work pretty well in various compiled languages I have studied. Many features do not require the interpreter and can now be done in other ways. Designers make choices and some are a matter of taste. Arguably Python is best for things like prototyping or even learning but arguably it is not as efficient for programs that run fairly simple algorithms constantly where running faster or using less memory can mean major savings. So, yes, often a program written in Python and shown to work, may be rewritten. But the opposite can be true as people give up trying to use a restrictive environment when the needs keep changing and a more flexible scripting language allows rapid changes. > > Python is not designed or planned the way some want and if that bothers them, use something else when told by others that the language was designed to do what it is supposed to and needs no change. > > On another forum someone is asking for R to not have just an NA variable when something is missing, but as many variants as needed to record why it is missing such as ILLEGIBLE or DELAYED or RAN_OUT_OF_TIME and so on. The claim is that many social science applications need this and some other programs/languages sort of support it. Fair enough but again, the design way-back-when saw no need for this and lots of drawbacks and although we brainstormed lots of ideas on how to attach metadata to a vector to support this, it often breaks down as most existing functions toss it away so you may have to redo tons of code very carefully to preserve the data or even reapply it after a change. Something as simple as converting a vector from character strings to their integer values will drop the changes. So, again, if this is that important, use something else and do NOT suggest diddling with unused bits in one implementation of NA to store your additional metadata as there is no guarantee it will get the result you want and it is not a documented guaranteed implementation and may break lots of other existing code. > > I am not discouraging anyone from asking questions and even suggesting changes. I simply suggest when others push back and tell you it was designed this way for darn good reasons and many LIKE IT the way it is, ... > > > -----Original Message----- > From: Python-list > On Behalf Of > Cameron Simpson > Sent: Monday, May 24, 2021 5:34 AM > To: python-list at python.org > Subject: Re: learning python ... > > On 24May2021 08:21, hw wrote: >> On 5/24/21 12:03 AM, Cameron Simpson wrote: >>> On 23May2021 21:02, Stestagg wrote: >>>> On Sun, 23 May 2021 at 20:37, hw wrote: >>>>> I don't know about shadowing. >>>> >>>> Shadowing is effectively saying ?within this bit of code, (scope) >>>> I?m going to use an already-used name for my own value? >>> >>> An example might make this clearer: >>> >>> x = 1 # global variable >>> >>> def f(a): >>> x = a * 2 >>> return x >>> >>> Inside the function f() the name 'x" shadows the global "x"; >>> references to "x" are to the function's local vairable. Which is very desireable. >> >> If it works that way, I would consider it an entirely different >> variable. Is there a way to access the global x from within a >> function without transferring it through parameters of the function? >> Than can also sometimes be useful. > > Sure. You can declare a name like this: > > def f(a): > global x # find x in the global namespace (the module) > x = a * 2 > return x > > This is pretty rare and usually discouraged. Of there are times when it is useful. > > Note that in this function: > > x = 1 > y = 2 > > def f(a): > x = 3 > print(x, y) > > "x" is local, because the function contains an assignment to it. "y" > comes from an outer scope (in this case, the global scope) because there's no assignment to it. > >>> As Stestagg has mentioned, there are also tools called linters which >>> warn you about issues like this. Tools like pyflakes, pylint, >>> pycodestyle all inspect your code for a wide variety of potential >>> errors and discouraged habits. Not to mention tools like mypy which >>> do type validation. >> >> So you're saying one can't really go without those unless you want to >> take the risk? > > Self restraint and developing good habits does 99% of the work. Linters are great for catching various accidents. > > [...] >> I'm not saying it shouldn't be allowed to defeat or to re-define >> stuff, only that it shouldn't go through quietly. > > Well, most of us use linters to exhibit that noise, rather than requiring the code to be littered with special directives. > > I usually code without much linter fuss until I've got the latest batch of work (eg feature or fix) ready, commit the changes, then lint vigorously and commit that polish before merging with the main line of code. > > Finally, consider this code: > > num = input("Enter a number: ") > num = int(num) > > input() returns a string, which would need converting to a number before some numeric stuff. Plenty of people write the above. To my mind, this is also a kind of shadowing, and I like this instead: > > num_s = input("Enter a number: ") > num = int(num_s) > > where the "_s" indicates quietly that this variable holds a string. > > Is that shadowing to your mind? Or not? If yes, should the language emit noise there, too? Remembering that Python _values_ are strongly typed, though the variables are not (a variable might reference any kind of object, as above). > > I wouldn't say that your opinion would be wrong regardless of what side of this question you come down on, but Python's chosen a side: noise for nonsensical things, but not noise for dubious things. But plenty of linters to complain about dubious things. > > Cheers, > Cameron Simpson > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list From python at mrabarnett.plus.com Fri May 28 10:42:52 2021 From: python at mrabarnett.plus.com (MRAB) Date: Fri, 28 May 2021 15:42:52 +0100 Subject: name for new Enum decorator In-Reply-To: References: Message-ID: On 2021-05-28 04:23, Ethan Furman wrote: > Greetings! > > The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements > into a decorator instead, and I'm having a hard time thinking up a name. > [snip] > > So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator > to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but > I have no idea what to call it. > > Any nominations? > "checked"? From torriem at gmail.com Fri May 28 11:04:11 2021 From: torriem at gmail.com (Michael Torrie) Date: Fri, 28 May 2021 09:04:11 -0600 Subject: learning python ... In-Reply-To: References: <7dc017ca-c0a3-c66e-8b7c-ceea1c786c73@adminart.net> <01b701d7512a$b689cf00$239d6d00$@verizon.net> Message-ID: <99c8b190-a744-08a6-12a4-76aa31386469@gmail.com> On 5/27/21 12:29 PM, hw wrote: > When the idea is to learn something, it's not exactly helpful to abandon > that idea when encountering the first obstacle or when someone tells you > you don't like it as much as they do ... We've had many new users approach the mailing list over the years. Always, early on, one can tell what the chances of success are, and which will end poorly. This is why I questioned whether Python was a good fit for you. Your attitude early on kind of raised alarm bells. We've seen this before. Many people on this list have patiently answered you questions. And while you seem to be holding on longer than many, it's not clear to me you want to learn Python. If your goal is to learn and use python for some purpose, whining about how it acts differently than you think it should, or how you would do something different than Guido did, is not helpful to that purpose. Why would you think it is? My prediction is your attitude will cause you to abandon Python very soon, and you'll go away from this list with a sour taste in your mouth, which is unfortunate, but completely of your own making. Python is a powerful and expressive language and one I really enjoy using, probably more so than any language I've ever used over the decades. It has warts of course. Python makes a very poor C, Java, or even Perl. It's not for everyone or every purpose. From rshepard at appl-ecosys.com Fri May 28 11:34:14 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Fri, 28 May 2021 08:34:14 -0700 (PDT) Subject: Applying winpdb_reborn Message-ID: I'm trying to debug a module of a PyQt5 application using winpdb_reborn. When I invoke the debugger with the module's name I get an empty winpdb window and the console tells me that it cannot find RPDBTERM. The full traceback is attached. Here, rpdb2 is available: $ locate rpdb2.py /usr/lib64/python3.7/site-packages/rpdb2.py /opt/winpdb-master/build/lib/rpdb2.py /opt/winpdb-master/rpdb2.py My only reference to winpdb_reborn is "Norm Matloff's Introduction to the Winpdb Python Debugging Tool (not just for Windows!)" and the text does not contain anything about RPDBTERM. I need advice on debuggng this module (when run only an empty window is displayed) and using winpdb_reborn. TIA, Rich -------------- next part -------------- $ winpdb activitytype.py 08:20:06.052 rpdb2.py:6148 MainThread/140081468266240 __setrecursionlimit(): rl = 1000 08:20:06.348 winpdb.py:3006 MainThread/140081468266240 set_font(): Using font "Monospace" for Console 08:20:06.350 winpdb.py:3006 MainThread/140081468266240 set_font(): Using font "Monospace" for Console (winpdb:5519): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed (winpdb:5519): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 13 and height -22 (winpdb:5519): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed (winpdb:5519): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 13 and height -22 (winpdb:5519): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed (winpdb:5519): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 13 and height -22 *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug Traceback (most recent call last): File "/usr/lib64/python3.7/site-packages/winpdb.py", line 1288, in __wrapper self.m_f(*args, **kwargs) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 197, in launch return self.__smi.launch(fchdir, command_line, interpreter, fload_breakpoints) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1160, in launch self._spawn_server(fchdir, ExpandedFilename, args, rid, interpreter) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1269, in _spawn_server terminal_command = CalcTerminalCommand() File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 2385, in CalcTerminalCommand if RPDBTERM in os.environ: NameError: name 'RPDBTERM' is not defined Traceback (most recent call last): File "/usr/lib64/python3.7/site-packages/winpdb.py", line 1288, in __wrapper self.m_f(*args, **kwargs) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 197, in launch return self.__smi.launch(fchdir, command_line, interpreter, fload_breakpoints) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1160, in launch self._spawn_server(fchdir, ExpandedFilename, args, rid, interpreter) File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1269, in _spawn_server terminal_command = CalcTerminalCommand() File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 2385, in CalcTerminalCommand if RPDBTERM in os.environ: NameError: name 'RPDBTERM' is not defined From python at mrabarnett.plus.com Fri May 28 12:39:47 2021 From: python at mrabarnett.plus.com (MRAB) Date: Fri, 28 May 2021 17:39:47 +0100 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: <8ea990f4-82ea-b691-cc66-c75e2d822db3@mrabarnett.plus.com> On 2021-05-28 16:34, Rich Shepard wrote: > I'm trying to debug a module of a PyQt5 application using winpdb_reborn. > When I invoke the debugger with the module's name I get an empty winpdb > window and the console tells me that it cannot find RPDBTERM. The full > traceback is attached. > > Here, rpdb2 is available: > $ locate rpdb2.py > /usr/lib64/python3.7/site-packages/rpdb2.py > /opt/winpdb-master/build/lib/rpdb2.py > /opt/winpdb-master/rpdb2.py > > My only reference to winpdb_reborn is "Norm Matloff's Introduction to the > Winpdb Python Debugging Tool (not just for Windows!)" and the text does not > contain anything about RPDBTERM. > > I need advice on debuggng this module (when run only an empty window is > displayed) and using winpdb_reborn. > Have you looked at the package's repository? It looks like this is the one: https://github.com/bluebird75/winpdb From rshepard at appl-ecosys.com Fri May 28 14:14:41 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Fri, 28 May 2021 11:14:41 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Fri, 28 May 2021, Schachner, Joseph wrote: > I have no familiarity with this issue, but I think one thing to check is > whether all capitalized RPDBTERM is truly the name you are looking for, > remember that Python is case sensitive. Joseph, According to the only doc I could find, "RPDB2 startup: Say you have a script x.py to debug, with command-lin arguments arg0, arg1 etc. Then to start RPDB2, type python rpdb2.py x.py arg0 arg1 ..." I don't know of any linux utility whose name is in all uppercase letters. Thanks, Rich From rshepard at appl-ecosys.com Fri May 28 14:19:26 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Fri, 28 May 2021 11:19:26 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: <8ea990f4-82ea-b691-cc66-c75e2d822db3@mrabarnett.plus.com> References: <8ea990f4-82ea-b691-cc66-c75e2d822db3@mrabarnett.plus.com> Message-ID: On Fri, 28 May 2021, MRAB wrote: > Have you looked at the package's repository? MRAB, > It looks like this is the one: > https://github.com/bluebird75/winpdb That's where I got it. Thanks, Rich From nospam at please.ty Fri May 28 02:54:00 2021 From: nospam at please.ty (jak) Date: Fri, 28 May 2021 08:54:00 +0200 Subject: string storage [was: Re: imaplib: is this really so unwieldy?] References: Message-ID: Il 27/05/2021 05:54, Cameron Simpson ha scritto: > On 26May2021 12:11, Jon Ribbens wrote: >> On 2021-05-26, Alan Gauld wrote: >>> I confess I had just assumed the unicode strings were stored >>> in native unicode UTF8 format. >> >> If you do that then indexing and slicing strings becomes very slow. > > True, but that isn't necessarily a show stopper. My impression, on > reflection, is that most slicing is close to the beginning or end of a > string, and that _most strings are small. (Alan has exceptions at least > to the latter.) In those circumstances, the cost of slicing a variable > width encoding is greatly mitigated. > > Indexing is probably more general (in my subjective hand waving > guesstimation). But... how common is indexing into large strings? > Versus, say, iteration over a large string? > > I was surprised when getting introduced to Golang a few years ago that > it stores all Strings as UTF8 byte sequences. And when writing Go code, > I found very few circumstances where that would actually bring > performance issues, which I attribute in part to my suggestions above > about when, in practical terms, we slice and index strings. > > If the internal storage is UTF8, then in an ecosystem where all, or > most, text files are themselves UTF8 then reading a text file has zero > decoding cost - you can just read the bytes and store them! And to write > a String out to a UTF8 file, you just copy the bytes - zero encoding! > -------------------------------- > Also, UTF8 is a funny thing - it is deliberately designed so that you > can just jump into the middle of an arbitrary stream of UTF8 bytes and > find the character boundaries. That doesn't solve slicing/indexing in > general, but it does avoid any risk of producing mojibake just by > starting your decode at a random place. > Perhaps you are referring to what the python language does if you jump to an albiter position of an utf8 string. Otherwise, before you start decoding, you should align at the beginning of an utf8 character by discarding the bytes that meet the following test: (byte & 0xc0) == 0x80 /* Clang */ -------------------------------- > Cheers, > Cameron Simpson > From rshepard at appl-ecosys.com Fri May 28 17:49:33 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Fri, 28 May 2021 14:49:33 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Fri, 28 May 2021, Dennis Lee Bieber wrote: > It's apparently looking for some environment variable based upon the > code at > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjfpYmk3-zwAhULI6wKHSPjAFIQFnoECAUQAA&url=http%3A%2F%2Fphault.rhul.ac.uk%2Fpy%2F_spe%2Fplugins%2Fwinpdb%2Frpdb2.py&usg=AOvVaw12BuzlEMVXrEuOFLoQLpFX Thanks, Dennis. It looked like an environment variable but I hadn't seen that with the python2 winpdb. I'll add that to ~/.bash_profile and see what happens. Enjoy the holiday weekend, Rich From cs at cskk.id.au Fri May 28 19:07:52 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Sat, 29 May 2021 09:07:52 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On 28May2021 08:34, Rich Shepard wrote: >I'm trying to debug a module of a PyQt5 application using winpdb_reborn. >When I invoke the debugger with the module's name I get an empty winpdb >window and the console tells me that it cannot find RPDBTERM. The full >traceback is attached. [...] >Traceback (most recent call last): > File "/usr/lib64/python3.7/site-packages/winpdb.py", line 1288, in __wrapper > self.m_f(*args, **kwargs) > File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 197, in launch > return self.__smi.launch(fchdir, command_line, interpreter, fload_breakpoints) > File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1160, in launch > self._spawn_server(fchdir, ExpandedFilename, args, rid, interpreter) > File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 1269, in _spawn_server > terminal_command = CalcTerminalCommand() > File "/usr/lib64/python3.7/site-packages/rpdb/session_manager.py", line 2385, in CalcTerminalCommand > if RPDBTERM in os.environ: >NameError: name 'RPDBTERM' is not defined It looks to me like a straight up bug in rpdb. I'd expect that line to read: if 'RPDBTERM' in os.environ: The easiest fix might be this (in your code, at the top): import builtins builtins.RPDBTERM = os.environ.get('TERM') that way the offending code can at least find the name RPDBTERM in the builtin names (just like "print" can always be found). It's a hack, but will at least make that line work. I do not know if the value of your $TERM environment variable is suitable, I'm just guessing. You'd need to read the code in /usr/lib64/python3.7/site-packages/rpdb/session_manager.py if it seemed unsuitable. Cheers, Cameron Simpson From cs at cskk.id.au Fri May 28 19:12:30 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Sat, 29 May 2021 09:12:30 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On 28May2021 14:49, Rich Shepard wrote: >On Fri, 28 May 2021, Dennis Lee Bieber wrote: >> It's apparently looking for some environment variable based upon the >>code at >>https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjfpYmk3-zwAhULI6wKHSPjAFIQFnoECAUQAA&url=http%3A%2F%2Fphault.rhul.ac.uk%2Fpy%2F_spe%2Fplugins%2Fwinpdb%2Frpdb2.py&usg=AOvVaw12BuzlEMVXrEuOFLoQLpFX > >Thanks, Dennis. It looked like an environment variable but I hadn't seen >that with the python2 winpdb. I'm concerned by the NameError, not in keeping with the fact that there does seem to be a global (module level) variable of the right name. >I'll add that to ~/.bash_profile and see what happens. The NameError suggests that this won't work. Maybe you're module install is an old version? Anyway, try it. There's no need to hack your .profile; you can do things like this at the command prompt for experiments: export RPDBTERM=$TERM then run the programme. BTW, that is statement looks like it is explicitly trying to handle lack of the envvar. Cheers, Cameron Simpson From veekm at foo.com Sat May 29 05:40:35 2021 From: veekm at foo.com (Veek M) Date: Sat, 29 May 2021 09:40:35 -0000 (UTC) Subject: Selenium script - stuck - could someone take a look? Message-ID: Script: http://paste.debian.net/1199271/ It mostly works but line 78 is supposed to extract 100 pieces / lot No matter what I try it's failed and I DON'T KNOW WHY? It's a simple div.classname match.. Could someone take a look and figure it out - I'm stuck. -------------------------------------------------------- import re, sys, time from selenium.common.exceptions import NoSuchElementException from selenium.common.exceptions import StaleElementReferenceException from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.common.keys import Keys from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.desired_capabilities import DesiredCapabilities url = 'https://www.aliexpress.com' caps = DesiredCapabilities().FIREFOX; caps["pageLoadStrategy"] = 'eager' ignored_exceptions=(NoSuchElementException,StaleElementReferenceException,) fh = open('/tmp/log.html', 'w') fh.write(' parts\n\n') def convert(m): money = m.group() return str(round(float(money) * 72.4, 3)) import re def process_fields(txt): if '$' in txt: txt = txt.replace('+', '') txt = txt.replace('$', '') txt = txt.replace('US', '') txt = txt.replace('Shipping:', '') r = re.sub(r'(\s*[0-9]+\.[0-9]+)', convert, txt) return str(r) def ali_search(url, txt): driver.get(url) assert 'AliExpress' in driver.title try: srch_elem = WebDriverWait(driver, 3600, ignored_exceptions=ignored_exceptions).until( EC.presence_of_element_located((By.XPATH, '//div[@class="search-key-box"]'))) print('search') x = driver.find_element_by_id('search-key') if 'input' in x.tag_name: print 'success' finally: for c in list(txt): time.sleep(1) x.send_keys(c) x.send_keys(Keys.RETURN) try: element = WebDriverWait(driver, 3600, ignored_exceptions=ignored_exceptions).until( EC.presence_of_element_located((By.XPATH, '//div[@class="product-container"]'))) finally: print('product-container') x = driver.find_element_by_xpath('//body') x.send_keys(Keys.HOME) for i in range(1,10): print('send END') time.sleep(1) x.send_keys(Keys.PAGE_DOWN) time.sleep(1) #driver.execute_script("window.scrollTo(0, document.body.scrollHeight);") # EC.presence_of_element_located((By.XPATH, '//div[contains(@class, " product-list")]'))) divs = element.find_elements_by_xpath('//li[@class="list-item packaging_sale"]') for c, div in enumerate(divs): fh.write('') for param in ['price-current', 'item-price-row packaging-sale', 'shipping-value', 'store-name']: try: if 'store' in param: fh.write('') elif 'sale' in param: print param lot = div.find_elements_by_class_name(param) fh.write('') else: fh.write('') except Exception as e: fh.write('') fh.write('\n') fh.write('\n
' + div.find_elements_by_class_name(param)[0].text + '' + str(lot) + '' + process_fields(div.find_elements_by_class_name(param).text) + '' + str(e) + '
') fh.close() def part_lookup(): global driver with webdriver.Firefox(executable_path=r'/mnt/sdb1/root/geckodriver', firefox_binary='/mnt/sdb1/firefox/firefox-bin', capabilities=caps) as driver: if len(sys.argv) == 2: ali_search(url, sys.argv[1]) time.sleep(3600) part_lookup() From veekm at foo.com Sat May 29 09:44:56 2021 From: veekm at foo.com (Veek M) Date: Sat, 29 May 2021 13:44:56 -0000 (UTC) Subject: Selenium script - stuck - could someone take a look? References: Message-ID: On 2021-05-29, Veek M wrote: fixed div './/' vs '//' From rshepard at appl-ecosys.com Sat May 29 12:51:04 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sat, 29 May 2021 09:51:04 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Sat, 29 May 2021, Dennis Lee Bieber wrote: > Except the copy of winpdb source I looked at has > > RPDBTERM = 'RPDBTERM' > > near the top. > > Then again, I don't know how up-to-date the OP's copy is -- I just > Googled for a repository with the module. > > Let me check a Linux environment (Debian 10 VM) (Great -- I attempted > to use the default password of a Beaglebone Black ) I've removed winpdb here as recommended by Philippe Fremy. I don't use IDEs other than emacs so I'll stick with pdb. What I find interesting is that every web page I find on 'using pdb' does no more than explain the available commands; they don't explain the debugging process. That's like showing someone what the word processor menus do; it doesn't teach the user how to be a writer. I knew the debugging process with Fortran and C, but haven't learned how to effectively use pdb to find bugs that don't issue a traceback or obvious wrong answer such as my module displaying an empty window with no widgets. Rich From cs at cskk.id.au Sat May 29 19:03:18 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Sun, 30 May 2021 09:03:18 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On 29May2021 09:51, Rich Shepard wrote: >I've removed winpdb here as recommended by Philippe Fremy. I don't use >IDEs other than emacs so I'll stick with pdb. > >What I find interesting is that every web page I find on 'using pdb' does no >more than explain the available commands; they don't explain the debugging >process. That's like showing someone what the word processor menus do; it >doesn't teach the user how to be a writer. > >I knew the debugging process with Fortran and C, but haven't learned how to >effectively use pdb to find bugs that don't issue a traceback or obvious >wrong answer such as my module displaying an empty window with no >widgets. I've only just started with pdb. As of Python 3.7 there's a builtin function named breakpoint() which drops you into the debugger. I've never been a big debugger person, historicly using print() and equivalent. However, this makes it very easy to insert this call into a piece of code instead of having to invoke one's pogramme in a special way. I'd imagine debugging is much like it is in C. Wait for the breakpoint to trip, then inspect the programme variables. In your example above I'd blithely imagine checking that the list of widgets I expected were in fact constructed, etc. But I'd also be littering my window setup with progress print calls :-) Cheers, Cameron Simpson From cs at cskk.id.au Sat May 29 19:07:02 2021 From: cs at cskk.id.au (Cameron Simpson) Date: Sun, 30 May 2021 09:07:02 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On 30May2021 09:03, Cameron Simpson wrote: >>I knew the debugging process with Fortran and C, but haven't learned >>how to effectively use pdb to find bugs that don't issue a traceback or obvious >>wrong answer such as my module displaying an empty window with no >>widgets. Also, searching for "pdb tutorial" seems to find a bunch of links. Cheers, Cameron Simpson From rosuav at gmail.com Sat May 29 19:25:41 2021 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 30 May 2021 09:25:41 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Sun, May 30, 2021 at 9:19 AM Cameron Simpson wrote: > > On 29May2021 09:51, Rich Shepard wrote: > >I knew the debugging process with Fortran and C, but haven't learned how to > >effectively use pdb to find bugs that don't issue a traceback or obvious > >wrong answer such as my module displaying an empty window with no > >widgets. > > I've only just started with pdb. As of Python 3.7 there's a builtin > function named breakpoint() which drops you into the debugger. I've > never been a big debugger person, historicly using print() and > equivalent. However, this makes it very easy to insert this call into a > piece of code instead of having to invoke one's pogramme in a special > way. > > I'd imagine debugging is much like it is in C. Wait for the breakpoint > to trip, then inspect the programme variables. > At its most fundamental level, debugging is the same regardless of the language: make a bug happen, then see as much as you possibly can about what caused it. Whether that's dumping print() calls through the code or using a debug harness, the normal way to figure out what code's doing is to see what your variables hold at different times. Using something like gdb, pdb, etc, etc, is just a shorthand for putting lots and LOTS of print calls into your code. So if you're not comfortable with those tools, there's no shame in using the more obvious/simple way of doing things! (Plus, there's not always an opportunity to use a debug harness. Sometimes you just have to put your prints into production and let it run for two weeks in the hope that the bug will show itself.) ChrisA From alan.gauld at yahoo.co.uk Sat May 29 19:20:40 2021 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Sun, 30 May 2021 00:20:40 +0100 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On 29/05/2021 19:10, Dennis Lee Bieber wrote: > On Sat, 29 May 2021 09:51:04 -0700 (PDT), Rich Shepard > declaimed the following: >> What I find interesting is that every web page I find on 'using pdb' does no >> more than explain the available commands; they don't explain the debugging >> process. That's like showing someone what the word processor menus do; it >> doesn't teach the user how to be a writer. I would point out that my book on learning to program included a chapter on using debugging, half of which was on pdb and how to use it. But that book is now over 20 years old and based on Python 1.5.3! but interestingly nearly all the reviewers specifically praised my inclusion of a chapter on debugging. >> I knew the debugging process with Fortran and C, but haven't learned how to >> effectively use pdb to find bugs that don't issue a traceback or obvious >> wrong answer such as my module displaying an empty window with no widgets. Like most debuggers, set breakpoints, watchpoints and variable traces. > The only debugger I used to be familiar with was that of (Open)VMS. My first job after graduating was writing white-box test scripts for a PABX control system. It was done by writing VMS Debug scripts and then running those scripts with various input files to provide the different initialization settings. I wrote around 100K lines of debug scripts to test around 60K lines of C. It was an amazingly powerful debugger. > I don't even want to think of GDB... I used gdb a few years after VMS DBG and thought it a dreadfully primitive beast by comparison. The scripting and automation features in particular were arcane by comparison. But they are all more similar to pdb than to winpdb. Maybe the OP could consider IDLE, it would at least be closer to an IDE debugger than pdb! And in its latest incarnations Idle is becoming a fairly useful tool once more. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From rshepard at appl-ecosys.com Sat May 29 19:43:05 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sat, 29 May 2021 16:43:05 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Sun, 30 May 2021, Cameron Simpson wrote: > Also, searching for "pdb tutorial" seems to find a bunch of links. Cameron, That's true. All the ones I've read list the various pdb commands. Knowing the commands is different from knowing when and how to apply them. I'll work back to remembering how I debugged code years ago with stubs and print() statements and use pdb with them. Thanks, Rich From rshepard at appl-ecosys.com Sat May 29 19:52:01 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sat, 29 May 2021 16:52:01 -0700 (PDT) Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Sun, 30 May 2021, Chris Angelico wrote: > (Plus, there's not always an opportunity to use a debug harness. Sometimes > you just have to put your prints into production and let it run for two > weeks in the hope that the bug will show itself.) ChrisA, Please excuse my long-winded description of a FORTRAN IV bug in an lake ecosystem energy model I wrote at the University of Illinois in the early 1970s. It is an example of what you wrote above. The program fill two boxes of 80-column Hollerith cards punched on an IBM 29 (if I correctly recall the model) keypuch machine. The output was written on green-barred wide paper on a line printer. Each time I ran the model it would produce one of four different, but wrong, answers for one variable. I closely examined the 1.5" thick fan-folded line printer output many times. I never saw the error, even with diagnostic stubs added. When I took the output to the computer center they looked at it for a week and couldn't find the error, either. Shortly after that, when I again examined the code, line-by-line, I saw the error: a line that should have read FOR I=1 to N actually read FOR I=I to N All of us saw the uppercase I as a 1 because a) that's what we expected to see and b) line printer output on green-barred paper was not that clear, even with fresh ribbons. That lesson has stuck with me ever since. Regards, Rich From rosuav at gmail.com Sat May 29 20:12:50 2021 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 30 May 2021 10:12:50 +1000 Subject: Applying winpdb_reborn In-Reply-To: References: Message-ID: On Sun, May 30, 2021 at 9:53 AM Rich Shepard wrote: > > On Sun, 30 May 2021, Chris Angelico wrote: > > > (Plus, there's not always an opportunity to use a debug harness. Sometimes > > you just have to put your prints into production and let it run for two > > weeks in the hope that the bug will show itself.) > > ChrisA, > > Please excuse my long-winded description of a FORTRAN IV bug in an lake > ecosystem energy model I wrote at the University of Illinois in the early > 1970s. It is an example of what you wrote above. > > The program fill two boxes of 80-column Hollerith cards punched on an IBM > 29 (if I correctly recall the model) keypuch machine. The output was written > on green-barred wide paper on a line printer. > > Each time I ran the model it would produce one of four different, but wrong, > answers for one variable. I closely examined the 1.5" thick fan-folded line > printer output many times. I never saw the error, even with diagnostic stubs > added. When I took the output to the computer center they looked at it for a > week and couldn't find the error, either. > > Shortly after that, when I again examined the code, line-by-line, I saw the > error: a line that should have read > FOR I=1 to N > actually read > FOR I=I to N > > All of us saw the uppercase I as a 1 because a) that's what we expected to > see and b) line printer output on green-barred paper was not that clear, > even with fresh ribbons. > > That lesson has stuck with me ever since. > Good lesson. And it's one of the things we really enjoy with modern editing systems (IDEs, or just smart text editors) - we can use colour to distinguish variable names from numeric literals! Although that can sometimes get disrupted. The editor I use (SciTE) will nicely syntax-highlight JavaScript code if it's in a .js file, but if you're embedding a small amount of code inside a