Re: Applying winpdb_reborn
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Applying winpdb_reborn
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: Applying winpdb_reborn
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: string storage [was: Re: imaplib: is this really so unwieldy?]
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Applying winpdb_reborn
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 -- https://mail.python.org/mailman/listinfo/python-list
RE: Applying winpdb_reborn
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Applying winpdb_reborn
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 -- https://mail.python.org/mailman/listinfo/python-list
Applying winpdb_reborn
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 $ 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: learning python ...
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: name for new Enum decorator
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"? -- https://mail.python.org/mailman/listinfo/python-list
