[issue39490] Python Uninstaller fails to clean up the old path variables when uninstalling
New submission from CJ Long : I had Python 3.7 installed on my machine. However, I started having issues with it, so I uninstalled Python. However, when I reinstalled and attempted to run pip from Powershell, the old path was still in my variable, and therefore, could not run pip. Python still works. -- components: Installation messages: 360984 nosy: brucelong priority: normal severity: normal status: open title: Python Uninstaller fails to clean up the old path variables when uninstalling type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue39490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: Will do, thanks for the input! -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: Yeah, I'd wondered that too (re: a separate function) but it seemed like an awful lot of duplicated code. The PR I'd put through just changes the datatypes within the `filenames` and `dirnames` lists... I'd been thinking that'd be sufficient since you wouldn't get that without specifying the optional boolean, but perhaps not. -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: I've started up a Github PR for this, btw, though IMO it's not really in a mergeable state yet: 1) I wasn't sure what to do about os.fwalk(), since that *doesn't* already generate DirEntry objects, and this change would introduce a small inconsistency between the two, functionalitywise. 2) Also wasn't sure what to do about unit tests, though I'll ponder that some more once I've got some time later. 3) The actual implementation is pretty trivial, but could perhaps be handled differently. The systems's still processing my CLA signature, as well, so there's that too. :) -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
New submission from CJ Kucera : It'd be nice to have an option to os.walk which would return DirEntry objects in its return tuple, as opposed to just the string filenames/dirnames. (Or failing that, an alternate function which does so.) The function already uses os.scandir() internally, so the DirEntry objects already exist -- I assume it'd be a pretty easy change. At the moment, if I want to be efficient and use os.scandir() myself, I've got to basically reimplement os.walk(), which seems silly since os.walk is already calling scandir itself. -- components: Library (Lib) messages: 341210 nosy: apocalyptech priority: normal severity: normal status: open title: Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
CJ Kucera added the comment: Ah, well, actually I suppose I'll rescind that a bit - other pages about this bug around the internet had been claiming that the 'requests' module uses urllib in the backend and was subject to this bug as well, but after experimenting myself, it seems like if that IS the case, they're working around it somehow, because using requests makes this succeed 100% of the time. I probably should've tried that first! So anyway, there's a reasonable workaround, at least. Sorry for the bugspam! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
CJ Kucera added the comment:
I've just encountered this problem on Python 3.6, on a different URL. The
difference being that it's not encountered with EVERY page load, though I'd say
it happens with at least half:
import urllib.request
html = urllib.request.urlopen('http://www.basicinstructions.net/').read()
print('Succeeded!')
I realize that the root problem here may be an HTTP server doing something
improper, but I've got no way of fixing someone else's webserver. It'd be
really nice if there was a reasonable way of handling this in Python itself.
As mentioned in the original report, other methods of retreiving this URL work
without fail (curl/wget/etc). As it is, the only way for me to be sure of
retreiving the entire page contents is by looping until I don't get an
IncompleteRead, which is hardly ideal.
--
nosy: +apocalyptech
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14044>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: Okay, I've got a reproducible testcase of this available up here: http://apocalyptech.com/pygtk-zlib/ I'm no longer *totally* convinced that it's a zlib issue... zlib's call actually returns a valid string, and the error happens later in the app. Hello, again, list. One last update on this, in case anyone happened to be curious about it. After talking with the PyCairo folks, it looks like this *was* a PyCairo issue after all, and the changes to the zlib call which had apparently fixed the issue were just incidental, basically, because of how the memory allocation ended up changing because of the modified vars. Anyway, a recent fix in PyCairo CVS seems to take care of it. zlib, as probably should have been expected, is vindicated! -CJ -- WOW: Flemmy| Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria! 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
bieff...@gmail.com wrote: If you have worked with C/C++, you know that memory-related bugs can be very tricky. More than once - working with C code - I had crashes that disappeared if I just added a 'printf', because the memory allocation scheme changed and the memory corrupted was not anymore relevant. Well, you turned out to be dead right about this, as I suppose should have been pretty obvious given the nature of the problems I was having. Anyway, the issue turned out to be zlib.decompress() - for larger sets of data, if I wasn't specifying bufsize, the malloc()s that it was doing behind-the-scenes must have been clobbering memory. As soon as I specified bufsize, everything was totally kosher. Once I'm a bit more awake tomorrow I'll put together a testcase and send it in to the bug tracker. This does bring up one question: for larger chunks of data, is it More Appropriate to use a zlib decompression object instead of just passing it all through zlib.decompress()? Thanks, everyone... -CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: Anyway, the issue turned out to be zlib.decompress() - for larger sets of data, if I wasn't specifying bufsize, the malloc()s that it was doing behind-the-scenes must have been clobbering memory. As soon as I specified bufsize, everything was totally kosher. Okay, I've got a reproducible testcase of this available up here: http://apocalyptech.com/pygtk-zlib/ I'm no longer *totally* convinced that it's a zlib issue... zlib's call actually returns a valid string, and the error happens later in the app. I've yet to be able to engineer a crash using anything other than that cairo.ImageSurface.create_from_png() function, so it's possible that specifying bufsize in zlib.decompress() merely allocates memory in such a way that a bug in PyCairo doesn't come to light in that case. So, I'm not really sure if I should submit this to Python or PyGTK's tracker yet. Could someone check it out and let me know what you think? That'd be great. Thanks! As I mention on that page, removing import os and import sys will fix the issue on XP, though you can remove them on win2k and still see the crash. Thanks, CJ -- WOW: Flemmy| The ships hung in the sky in much the same p...@apocalyptech.com |way that bricks don't. - Douglas Adams, 24.24.2.3171 | _The Hitchhiker's Guide To The Galaxy_ -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
CJ Kucera wrote: Okay, I've got a reproducible testcase of this available up here: http://apocalyptech.com/pygtk-zlib/ Hello, two brief notes here: 1) Someone on the PyGTK list mentioned that I should really be using StringIO instead of my own hacky attempt at one, in there, and of course he was right. Replacing my class with StringIO doesn't result in any changed behavior, at least, so I can definitely rule out any weirdness that my own file-like class could have introduced. I've uploaded a new version of run.py to the above URL which includes that change. 2) It looks like specifying bufsize isn't actually the totally magic bullet for this. I had put in that fix to my application, so it was using bufsize, and things seemed to be working all right, but after four or five data loads, I got that Windows crash again, regardless. The fix does make the application stable enough that I'm not that worried about it, at least, but it doesn't seem to have totally bypassed whatever bug I'm running into. -CJ -- WOW: Flemmy| Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria! 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] Re: Strange crash issue on Windows w/ PyGTK, Cairo...
bieff...@gmail.com wrote: It looks like some of the C extension you are using is causing a segfault or similar in python interpreter (or it could be a bug in the interpreter itself, but it is a lot less likely). Okay... I assume by C extension you'd include the PyGTK stuff, right? (ie: pycairo, pygobject, and pygtk) Those are the only extras I've got installed, otherwise it's just a base Python install. Would a bad extension really cause this kind of behavior though? Specifically the working-the-first-time and crash-subsqeuent-times? Do C extensions contribute to the bytecode generated while compiling? I would suggest to fill the startup portion of your code with trace statements to try to understand which module function is the troublesome one, then go looking in the big tracking system of the module, try the newest version and ask on the dedicated mailing list if any. Are you talking about just throwing in various print statements, to find out where exactly it's dying? Or I see that there is an actual trace module in Python... I did do the former awhile ago and didn't find anything conclusive really. It was when approaching it from that angle that I stumbled across the case that if I simply renamed one of my functions, everything started working again. I'll do this a bit more once I've gotten the program down to a more manageable level. Making a small script that cabn reproduce the bug is also a very good idea, and will help speed-up the problem solution. Right, that's the goal. Right now it's still pretty unwieldy, still. I'll keep on it. Thanks for the response! -CJ -- WOW: Flemmy| Happiness isn't good enough for me! I p...@apocalyptech.com | demand euphoria! 24.24.2.3171 | - Calvin -- http://mail.python.org/mailman/listinfo/python-list
Strange crash issue on Windows w/ PyGTK, Cairo...
Hello list! I'm having a strange issue, and I'm not entirely certain yet where the actual problem is (ie, Python, PyGTK, or gtk+), but I figure I'll start here. Bear with me, this'll probably be a long explanation... I've been building an app which is meant to be run on both Linux and Windows. It uses PyGTK for its GUI, and the main area of the app is a gtk.DrawingArea which I draw on using PyCairo. I've been developing on Linux, and it works great on that platform, with no issues that I'm aware of. When running on Windows, though, the app exhibits the following behavior: 1) When the .py of the main file which runs the application GUI first gets compiled to a .pyc (ie: the first time it's run, or the first time after .py modification), the application runs totally fine, with no apparent problems. 2) Any attempt AFTER that, the application will start up, *start* to do its data-loading, but then almost immediately crash with an enigmatic python.exe has generated errors and will be closed by Windows. When it does so, there is no output whatsoever to the console that the application was launched from, and the crash doesn't always happen in exactly the same place. The pattern remains the same, though - if the .pyc needs to be compiled, the application works fine, but if not: boom. I've been steadily stripping the program down to what I hoped would be a small, reproducible app that I could post here, and I do intend to do so still, but it's rather slow going. For now, I was hoping to see if anyone's ever heard of behavior like this before, and might know what to do about it, or at least a possible avenue of attack. As I've been reducing the program down, I've encountered even stranger (IMO) behavior... In one instance, changing a function name seemed to make the program work. I took out the handler which draws my app's About box, and suddenly my problem went away. Occasionally I would remove a function and the app would suddenly *always* fail with that Windows crash error, and I'd have to put the function back in. Keep in mind, these are functions which *aren't being called anywhere.* Sometimes I could replace a function's entire contents with just pass and the app would suddenly behave properly, or not behave at all. It's almost as if whatever's doing the byte-compilation is getting screwed up somehow, and really small changes to parts of the file which aren't even being touched are having a huge impact on the application as a whole. It's seriously vexing, and certainly the oddest problems I've seen in Python. Windows versions I can reproduce this on: XP and win2k Python versions I've reproduced this on: Python 2.5.4 with: PyGTK 2.12.1-2-win32-py2.5 PyGObject 2.14.1-1.win32-py2.5 PyCairo 1.4.12-1.win32-py2.5 Python 2.6.1 with: PyGTK 2.12.1-3-win32-py2.6 PyGObject 2.14.2-2.win32-py2.6 PyCairo 1.4.12-2.win32-py2.6 gtk+ 2.12.9-win32-2 (from http://sf.net/projects/gladewin32 , which is the version linked to from pygtk.org) The 2.6 Python stuff I've actually only tried on win2k so far, not XP, though given my history with this, I suspect that that wouldn't make a difference. Since gtk+ is the one bit of software that hasn't been swapped out for another version, I suppose that perhaps that's where the issue is, but it seems like Python should be able to at least throw an Exception or something instead of just having a Windows crash. And having it work the FIRST time, when the .pyc's getting compiled, is rather suspicious. Anyway, I'll continue trying to pare this app down to one manageable script which I can post here, but until then I'd be happy to hear ideas from anyone else about this. Thanks! -CJ -- http://mail.python.org/mailman/listinfo/python-list
Python, SOAP SSL
Was this ever solved? I'm running into the same problem right now. Any help is much appreciated. -cjb -- http://mail.python.org/mailman/listinfo/python-list
Re: Here I am again, same old arguments
Wow, thanks alot. I pretty much (due to my own desire to get the program to )(@#T(=!!! work and be done with it) just turned the list into a function that returns a list that isn't attached to anything but the function itself, but I've taken the advice to heart. Most of what you posted makes sense, and is in fact easier than what I was doing, but I have three questions: 1) Why no global variables? I'm taking your word for it that they're bad. Far be it from me to argue with you, but why are they bad ideas to begin with? Most of the languages I've used up to this point have been reliant on globals, so I'm not entirely sure why they shouldn't be used. 2) Why no for loop with an index? Again, far be it from me to argue, but it seemed perfect for my program. 3) Where do I find a command list, with syntax and all that fun stuff for Python? I've explored the python site to no end, but I can't seem to find a list. Again, thanks to everyone who put my crappy noob proggie through the blender :D I really did learn alot. Like how my 60 line program got turned into a 15 line code snippet. (I'm not being sarcastic, really, thanks) - Wait a minute. I can use my PSP to play GAMES?!? Steven D'Aprano [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On Sun, 09 Oct 2005 07:02:52 +, CJ wrote: Okay, same program, different issue. Thanks to the help that I was given I was able to complete my program to find variables in a list that were repeated, and display them once, and how many times they appeared in the list. And it worked great! But, being the perfectionist that I am, I wanted to make the proggie allow any size of list, and not have to be recoded every time. So step one was to not make the program reliant on the list itself being of X length all the time. First off -- don't use a for loop with an index as you are doing. #setup variables grub=[3,25,3,5,3,a,a,BOB,3,3,45,36,26,25,a,3,3,3,bob,BOB,6 7] grubrpt=grub cntro=0 cntrt=0 rpt=0 skipped=0 You are doing too much manual work! Let Python do the lion's share of the work for you! #set up for variable length of grub ttllen=len(grub)-1 Why are you subtracting one from the length of the list? print The heck is this for loop doing? for point in range(0,ttllen,1): Using point as a loop index is generally a bad idea. The result coming from range is not a point, it is an integer, so why call it a point? You are also over-specifying the input arguments to range. If the step size is one, you don't need to specify it -- that's the default. You just make it harder to read, for no reason. Likewise the initial starting value of zero. Just use range(ttllen). This, by the way, will return a list [0, 1, 2, ... , length of list - TWO] because you already subtracted one from the length. print Here's Grub=,grub print And grubrpt=,grubrpt grubrpt[point]=blk As others have pointed out, grub and grubrpt are both names for the same list. Changing one changes the other. #Makes sure that there are not multiple prints. def alrdy_dn(grub,grubrpt): if grub[cntro] in grubrpt: Ew!!! Global variables!!! Bad programmer! No biscuit!!! *wink* Global variables are almost always a BAD idea. return grubrpt else: print grub[cntro],appears in list,rpt,times. grubrpt[grubrpt.index(blk)]=grub[cntro] return grubrpt This is a strange function. What exactly is it meant to do? It combines user interface (printing the number of times each item appears) and functionality (counting the number of times each item appears) and side effects (changing the list), before returning one of the input arguments again. At least two of those things (counting the items, and printing the results) should be separated into different functions for ease of comprehension. I'm going to skip the rest of your code, because I don't understand it and am too lazy, er, I mean busy, to spend the time trying to decipher it. Especially since the function you are trying to duplicate manually is so easy to do if you work with Python instead of against it. def count_item(L, item): Count the number of times item appears in list L. return L.count(item) Or wait... that's too easy :-) If you want to roll your own, then do it like this: def count_item(L, item): Count the number of times item appears in list L by reinventing the wheel. n = 0 for obj in L: if obj == item: n += 1 return n Notice that we don't change the list at any time. Why change it? That just adds complexity to our program and adds extra places to make bugs. Of which you have many :-) Now you use it like this: grub=[3,25,3,5,3,a,a,BOB,3,3,45,36,26,25,a,3,3,3,bob,BOB,67 ] for item in grub: n = count_item(grub, item) print item, appears in list, n, times. And you are done
Here I am again, same old arguments
Okay, same program, different issue. Thanks to the help that I was given I was able to complete my program to find variables in a list that were repeated, and display them once, and how many times they appeared in the list. And it worked great! But, being the perfectionist that I am, I wanted to make the proggie allow any size of list, and not have to be recoded every time. So step one was to not make the program reliant on the list itself being of X length all the time. Well, for some reason, the FOR loop is altering two of my lists. Using PRINT magic, I was able to narrow down the lines that were causing it. But the question remains: Why is it doing this? I'm sure there's a simple answer that I just overlooked in the manual or something. So without further ado, the code: #setup variables grub=[3,25,3,5,3,a,a,BOB,3,3,45,36,26,25,a,3,3,3,bob,BOB,67] grubrpt=grub cntro=0 cntrt=0 rpt=0 skipped=0 #set up for variable length of grub ttllen=len(grub)-1 print The heck is this for loop doing? for point in range(0,ttllen,1): print Here's Grub=,grub print And grubrpt=,grubrpt grubrpt[point]=blk #Makes sure that there are not multiple prints. def alrdy_dn(grub,grubrpt): if grub[cntro] in grubrpt: return grubrpt else: print grub[cntro],appears in list,rpt,times. grubrpt[grubrpt.index(blk)]=grub[cntro] return grubrpt #removes display of variables not repeated def no_rpts(skipped,grubrpt): if rpt==0: skipped=skipped+1 else: grubrpt=alrdy_dn(grub,grubrpt) return skipped #Main body of code print The List is:,grub while cntrolen(grub)-1: if grub[cntro]==grub[cntrt]: rpt=rpt+1 cntrt=cntrt+1 else: cntrt=cntrt+1 if cntrt==len(grub): skipped=no_rpts(skipped,grubrpt) cntro=cntro+1 cntrt=0 rpt=-1 print skipped,list elements are unique. And the award winning Output: The heck is this for loop doing? Here's Grub= [3, 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] And grubrpt= [3, 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] Here's Grub= ['blk', 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] And grubrpt= ['blk', 25, 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] Here's Grub= ['blk', 'blk', 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] And grubrpt= ['blk', 'blk', 3, 5, 3, 'a', 'a', 'BOB', 3, 3, 45, 36, 26, 25, 'a', 3, 3, 3, 'bob', 'BOB', 67] It goes on like that, I'm not going to put all of it here for obvious reasons. But, if I take out the whole for loop and the lines relating to it and statically assign grubrpt as [blk,blk...] then the program runs wonderfully. From what I understand, you can never have too many functions, so I tried to make the grub blk a function and got the same result. I'm still nailing them down, so if my functions look a little weird you know why. Also, I do realize that there is an easier way to do this, I just created a little project for myself to learn the basics of the language. Thanks for all the help! -CJ -- http://mail.python.org/mailman/listinfo/python-list
Re: While and If messing up my program?
CJ [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Thanks! I think I've nailed it. I appreciate all the input! -- http://mail.python.org/mailman/listinfo/python-list
While and If messing up my program?
Hey, I'm new to the Python world, but I do have experience in several other languages. I've been running through a tutorial, and I decided that I'd make a program that runs through a list, finds if there are any duplicates. The program, doesn't work, but since its a first build I wasn't too worried about it. I'd be highly impressed if I got the program to run correctly in the first build, I want to debug it myself later. What does worry me, is that I can't seem to get the program by a certain spot. It keeps giving me the same error, and I don't know why. The code: ttllst=[4,3,45,3] cnto=0 cntt=1 rept=-1 print cnto print cntt print ttllst[cnto] print ttllst[cntt] choice=raw_input(Begin? ) if choice == yes or choice == y: while cntolen(ttllst)+1: if ttllst[cnto]==ttllst[cntt]: rept=rept+1 if cntt==len(ttllst): print ttllst[cnto],appears in the list,rept,times. cntt=-1 cnto=cnto+1 rept=-1 cntt=cntt+1 print done. After running the program I get error: Traceback (most recent call last): File C:\Python24\Projects\repeatfinderlist, line 13, in -toplevel- if ttllst[cnto]==ttllst[cntt]: IndexError: list index out of range Now, if I remove the while, and the If/choice lines like so: ttllst=[4,3,45,3] cnto=0 cntt=1 rept=-1 print cnto print cntt print ttllst[cnto] print ttllst[cntt] if ttllst[cnto]==ttllst[cntt]: rept=rept+1 if cntt==len(ttllst): print ttllst[cnto],appears in the list,rept,times. cntt=-1 cnto=cnto+1 rept=-1 cntt=cntt+1 print done. I get no errors. The program doesn't work, granted, but I get no errors. Can anyone tell me what I'm missing? Thanks! -CJ -- http://mail.python.org/mailman/listinfo/python-list
