"grep" database
Hello, I've heard of a software on linux that creates a recursive database of text files and then provides an interface for grep-like queries. I'd like to use it to find procedures/variables in a large code base. Any suggestions appreciated. Thanks, Hilbert -- http://mail.python.org/mailman/listinfo/python-list
Re: "grep" database
thanks! -- http://mail.python.org/mailman/listinfo/python-list
right list for SIGABRT python binary question ?
Hi all, is this the right list to ask for help in debugging a SIGABORT (?) happening on shutdown of a Python 2.7 script ? If not, which one is ? Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Tue, Oct 17, 2017 at 12:04:09PM +1100, Steve D'Aprano wrote: > > is this the right list to ask for help in debugging a > > SIGABORT (?) happening on shutdown of a Python 2.7 script ? > > > > If not, which one is ? > > You should try here first. > > Please ensure you read and follow this first: > > http://sscce.org/ > > and post a *minimum* example of your code. (Sorry for the redundant > instructions if you already know this, but you would be surprised how many > people don't.) Thanks. I'll work towards a postable example. Running a debug build of py27 gave me a first lead: this Debian system (Testing, upgraded all the way from various releases ago) carries an incompatible mxDateTime which I'll take care of. *** You don't have the (right) mxDateTime binaries installed ! Traceback (most recent call last): File "./bootstrap_gm_db_system.py", line 87, in from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N File "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line 34, in from Gnumed.pycommon import gmDateTime File "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", line 52, in import mx.DateTime as mxDT File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 8, in from DateTime import * File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 9, in from mxDateTime import * File "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 13, in raise ImportError, why ImportError: /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: undefined symbol: Py_InitModule4 Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: PEP 249 Compliant error handling
> That's certainly a possibility, if that behavior conforms to the DB API > "standards". My concern in this front is that in my experience working with > other PEP 249 modules (specifically psycopg2), I'm pretty sure that columns > designated as type VARCHAR or TEXT are returned as strings (unicode in python > 2, although that may have been a setting I used), not bytes. The other > complication here is that the 4D database doesn't use the UTF-8 encoding > typically found, but rather UTF-16LE, and I don't know how well this is > documented. So not only is the bytes representation completely unintelligible > for human consumption, I'm not sure the average end-user would know what > decoding to use. > > In the end though, the main thing in my mind is to maintain "standards" > compatibility - I don't want to be returning bytes if all other DB API > modules return strings, or visa-versa for that matter. There may be some > flexibility there, but as much as possible I want to conform to the > majority/standard/whatever The thing here is that you don't want to return data AS IF it was correct despite it having been "corrected" by some driver logic. What might be interesting to users is to set an attribute on the cursor, say, cursor.faulty_data = unicode(faulty_data, errors='replace') or some such in order to improve error messages to the end user. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
OK, here's the first bit which might be part of the puzzle of why my Python script SIGABRT's. When run under "normal" py2.7 it runs all the way through but upon shutdown (*after* sys.exit(0)) faulthandler shows a problem (and returns 134 which made me think of SIGABRT): *** Error in `python': free(): invalid pointer: 0x00770b14 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb7ccc38a] /lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb7cd2fc7] /lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb7cd3806] python(PyObject_Free+0xfb)[0x44affb] python(+0x110b51)[0x534b51] python(+0x110b51)[0x534b51] python(+0x110b51)[0x534b51] python(+0xf3ea7)[0x517ea7] python(PyDict_SetItem+0x201)[0x4d4f81] python(_PyModule_Clear+0x150)[0x539630] python(PyImport_Cleanup+0x61d)[0x53927d] python(Py_Finalize+0x9d)[0x53635d] python(Py_Exit+0x14)[0x55cb24] python(+0x136102)[0x55a102] python(PyErr_PrintEx+0x35)[0x559975] python(+0x3dd41)[0x461d41] python(Py_Main+0x753)[0x4d2c83] python(main+0x1b)[0x4d251b] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7c7d286] python(+0xae3f3)[0x4d23f3] === Memory map: 00424000-00763000 r-xp 08:01 6285092/usr/bin/python2.7 00763000-00764000 r--p 0033e000 08:01 6285092/usr/bin/python2.7 00764000-007c4000 rw-p 0033f000 08:01 6285092/usr/bin/python2.7 007c4000-007d9000 rw-p 00:00 0 026f1000-02921000 rw-p 00:00 0 [heap] b680-b6821000 rw-p 00:00 0 b6821000-b690 ---p 00:00 0 b6995000-b69b r-xp 08:01 8151085 /lib/i386-linux-gnu/libgcc_s.so.1 b69b-b69b1000 r--p 0001a000 08:01 8151085 /lib/i386-linux-gnu/libgcc_s.so.1 b69b1000-b69b2000 rw-p 0001b000 08:01 8151085 /lib/i386-linux-gnu/libgcc_s.so.1 b69f5000-b6b35000 rw-p 00:00 0 b6b35000-b6b4 r-xp 08:01 8151337 /lib/i386-linux-gnu/libnss_files-2.24.so b6b4-b6b41000 r--p a000 08:01 8151337 /lib/i386-linux-gnu/libnss_files-2.24.so b6b41000-b6b42000 rw-p b000 08:01 8151337 /lib/i386-linux-gnu/libnss_files-2.24.so b6b42000-b6b48000 rw-p 00:00 0 b6b48000-b6b53000 r-xp 08:01 8151339 /lib/i386-linux-gnu/libnss_nis-2.24.so b6b53000-b6b54000 r--p a000 08:01 8151339 /lib/i386-linux-gnu/libnss_nis-2.24.so b6b54000-b6b55000 rw-p b000 08:01 8151339 /lib/i386-linux-gnu/libnss_nis-2.24.so b6b64000-b6b6b000 r--p 08:01 6286752 /usr/share/locale/de/LC_MESSAGES/libpq5-10.mo b6b6b000-b6b72000 r--s 08:01 6903281 /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache b6b72000-b6b98000 r--p 08:01 6288754 /usr/share/locale/de/LC_MESSAGES/libc.mo b6b98000-b6c98000 rw-p 00:00 0 b6c9e000-b6cb4000 r-xp 08:01 8151334 /lib/i386-linux-gnu/libnsl-2.24.so b6cb4000-b6cb5000 r--p 00016000 08:01 8151334 /lib/i386-linux-gnu/libnsl-2.24.so b6cb5000-b6cb6000 rw-p 00017000 08:01 8151334 /lib/i386-linux-gnu/libnsl-2.24.so b6cb6000-b6cb8000 rw-p 00:00 0 b6cb8000-b6cc r-xp 08:01 8151335 /lib/i386-linux-gnu/libnss_compat-2.24.so b6cc-b6cc1000 r--p 7000 08:01 8151335 /lib/i386-linux-gnu/libnss_compat-2.24.so b6cc1000-b6cc2000 rw-p 8000 08:01 8151335 /lib/i386-linux-gnu/libnss_compat-2.24.so b6cc2000-b6d02000 rw-p 00:00 0 b6d02000-b6d09000 r-xp 08:01 6899491 /usr/lib/i386-linux-gnu/libffi.so.6.0.4 b6d09000-b6d0a000 r--p 6000 08:01 6899491 /usr/lib/i386-linux-gnu/libffi.so.6.0.4 b6d0a000-b6d0b000 rw-p 7000 08:01 6899491 /usr/lib/i386-linux-gnu/libffi.so.6.0.4 b6d0b000-b6d96000 r-xp 08:01 6899509 /usr/lib/i386-linux-gnu/libgmp.so.10.3.2 b6d96000-b6d97000 r--p 0008a000 08:01 6899509 /usr/lib/i386-linux-gnu/libgmp.so.10.3.2 b6d97000-b6d98000 rw-p 0008b000 08:01 6899509 /usr/lib/i386-linux-gnu/libgmp.so.10.3.2 b6d98000-b6dcc000 r-xp 08:01 6899139 /usr/lib/i386-linux-gnu/libhogweed.so.4.3 b6dcc000-b6dcd000 r--p 00033000 08:01 6899139 /usr/lib/i386-linux-gnu/libhogweed.so.4.3 b6dcd000-b6dce000 rw-p 00034000 08:01 6899139 /usr/lib/i386-linux-gnu/libhogweed.so.4.3 b6dce000-b6e08000 r-xp 08:01 6897991 /usr/lib/i386-linux-gnu/libnettle.so.6.3 b6e08000-b6e09000 ---p 0003a000 08:01 6897991 /usr/lib/i386-linux-gnu/libnettle.so.6.3 b6e09000-b6e0a000 r--p 0003a000 08:01 6897991 /usr/lib/i386-linux-gnu/libnettle.so.6.3 b6e0a000-b6e0b000 rw-p 0003b000 08:01 6897991 /u
Re: PEP 249 Compliant error handling
On Wed, Oct 18, 2017 at 08:32:48AM -0800, Israel Brewster wrote: > actual question, which is "how does the STANDARD (PEP 249 in > this case) say to handle this, or, baring that (since the > standard probably doesn't explicitly say), how do the > MAJORITY of PEP 249 compliant modules handle this?" Not what > is the *best* way to handle it, but rather what is the > normal, expected behavior for a Python DB API module when > presented with bad data? That is, how does psycopg2 behave? > pyodbc? pymssql (I think)? Etc. Or is that portion of the > behavior completely arbitrary and different for every module? For what it is worth, psycopg2 does not give you bad data to the best of my knowledge. In fact, given PostgreSQL's quite tight checking of text data to be "good" psycopg2 hardly has a chance to give you bad data. Most times the database itself will detect the corruption and not even hand the data to psycopg2. IMHO a driver should not hand over to the client any bad data unless explicitely told to do so, which latter case does not seem to be covered by the DB-API specs, regardless of what the majority of drivers might do these days. 2 cent... Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Wed, Oct 18, 2017 at 02:07:46PM +0200, Thomas Jollans wrote: > > When run under a debug build it sayeth right away (simulated > > as a minimal working example): > > > > root@hermes:~/bin# python2.7-dbg > > Python 2.7.14 (default, Sep 17 2017, 18:50:44) > > [GCC 7.2.0] on linux2 > > Type "help", "copyright", "credits" or "license" for more > > information. > > >>> import mx.DateTime > > *** You don't have the (right) mxDateTime binaries installed ! > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", > > line 8, in > > from DateTime import * > > File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", > > line 9, in > > from mxDateTime import * > > File > > "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line > > 13, in > > raise ImportError, why > > ImportError: > > /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: > > undefined symbol: Py_InitModule4 > > I don't really what exactly is going on here, but in general extension > modules compiled for non-debug builds won't work with debug builds. OK, that helps. I found -dbg builds of mx.DateTime in Debian. > > For good measure I have filed a bug with Debian asking for > > recompilation of python-egenix-mxdatetime. > > Even if the maintainers do that, it won't help. Check that the module > works on its own with the regular Python build and then close the bug if > the maintainers don't beat you to it. Done. > > When run under "normal" py2.7 it runs all the way through but > > upon shutdown (*after* sys.exit(0)) faulthandler shows a > > problem (and returns 134 which made me think of SIGABRT): > > We still don't know what "it" is. > > Strip down your script as much as possible. It looks like you're using a > lot of extension modules, and any one of them could (in theory) be > causing problems. I know. However, stripping down isn't quite so easy (it never is, which is a rather lame excuse for not doing so yet :-) The script itself is but a meager 1843 lines (but using lots of Python modules, both stdlib and my own). What it does is take a large number of SQL files (roughly a thousand) and replaying them against PostgreSQL thereby bootstrapping a database layout from scratch up to the current version (21). The abort-on-exit only happens if "enough" SQL scripts have been run (sounds like a resource leak) and the bootstrapper script exits (having encountered a database problem or not makes no difference). Running various parts of the whole procedure does not make a difference as to whether the fault occurs when exiting, if only "enough" SQL scripts are run. I am currently running the bootstrapper with mxdatetime as a dbg build to see what gives. The only other C extension I am aware of that is in use is psycopg2. However, none of these two (nor any other modules) have been added to the bootstrapper (or updated) recently (in fact, this setup has been in use for, what, a decade?) so it is quite unclear why they should be at fault now. The one thing that did change is PostgreSQL going from 9.6 to 10, effecting a libpq5 recompiled against the newer PG client. I wonder whether psycopg2 needs a recompile against that libpq5 (despite there not having been changes advertised by PG). I guess I'll have to downgrade libpq5 to 9.6 and see what happens. I'll report what I find. (oh, and it's all available on github) Thanks, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Thu, Oct 19, 2017 at 07:27:45PM +0200, Karsten Hilbert wrote:
> I am currently running the bootstrapper with mxdatetime as a
> dbg build to see what gives. The only other C extension I am
> aware of that is in use is psycopg2.
So here's the final console output of that:
==> bootstrapping "v20_fixups-pre_v21" ...
==> dropping pre-existing target database [gnumed_v21] ...
==> cloning [gnumed_v20] (72 MB) as target database [gnumed_v21] ...
==> reindexing target database (can take a while) ...
==> transferring users ...
==> bootstrapping "v20-v21-static" ...
==> bootstrapping "v20-v21-dynamic" ...
==> bootstrapping "v21-fixups" ...
==> setting up auditing ...
==> setting up encounter/episode FKs and IDXs ...
==> setting up encounter/episode FK sanity check triggers ...
==> setting up generic notifications ...
==> upgrading reference data sets ...
==> verifying target database schema ...
==> checking migrated data for plausibility ...
Done bootstrapping GNUmed database: We very likely succeeded.
log:
/home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
Debug memory block at address p=0x717b7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x03 *** OUCH
at p-2: 0x4e *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes
requested
may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x717b7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API '', verified using API
'o'
./bootstrap-latest.sh: Zeile 80: 28023 Abgebrochen
./bootstrap_gm_db_system.py --log-file=${LOG} --conf-file=${CONF} --${QUIET}
Bootstrapping "gnumed_v21" did not finish successfully (134). Aborting.
Note there's not faulthandler output here because I don't yet
know how to get a debug build of *that* (Debian does not seem
to have one and neither does pypi to my knowledge).
That'd be needed because of:
root@hermes:~/bin# python2.7-dbg
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
Traceback (most recent call last):
File "", line 1, in
ImportError:
/usr/lib/python2.7/dist-packages/faulthandler.i386-linux-gnu.so: undefined
symbol: Py_InitModule4
[45316 refs]
>>>
Can anyone give more guidance on what the above python debug
output might vaguely point to ?
Thanks,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Sat, Oct 21, 2017 at 07:10:31PM +0200, M.-A. Lemburg wrote: > > Running a debug build of py27 gave me a first lead: this > > Debian system (Testing, upgraded all the way from various > > releases ago) carries an incompatible mxDateTime which I'll > > take care of. > > > > *** You don't have the (right) mxDateTime binaries installed ! > > Traceback (most recent call last): > > File "./bootstrap_gm_db_system.py", line 87, in > > from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N > > File > > "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line > > 34, in > > from Gnumed.pycommon import gmDateTime > > File > > "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", > > line 52, in > > import mx.DateTime as mxDT > > File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line > > 8, in > > from DateTime import * > > File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line > > 9, in > > from mxDateTime import * > > File > > "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line > > 13, in > > raise ImportError, why > > ImportError: > > /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: > > undefined symbol: Py_InitModule4 > > This error suggests that you have 32- and 64-bit versions of > Python and mxDateTime mixed in your installation. > > Py_InitModule4 is only available in the 32-bit build of > Python. With the 64-bit build, it's called Py_InitModule4_64. > > Since you're getting the same error from faulthandler, > this is where I'd start to investigate. > > "nm" will list all exported and required symbols. As first step, > you should probably check the python binary for its symbols and > see whether it exports Py_InitModule* symbols. Thanks for your input ! The python2.7-dbg build is 32 bits: root@hermes:~# nm /usr/bin/python2.7-dbg | grep Py_InitM 00155b9f T Py_InitModule4TraceRefs python2.7-dbg: Installiert: 2.7.14-2 Installationskandidat: 2.7.14-2 Versionstabelle: *** 2.7.14-2 500 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 2.7.13-2 990 500 http://httpredir.debian.org/debian stretch/main i386 Packages 990 http://httpredir.debian.org/debian buster/main i386 Packages The python2.7 build (no -dbg) does not have symbols. mxDateTime really should be 32 bits, too: python-egenix-mxdatetime: Installiert: 3.2.9-1 Installationskandidat: 3.2.9-1 Versionstabelle: *** 3.2.9-1 990 500 http://httpredir.debian.org/debian stretch/main i386 Packages 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status Let me check the .so file: root@hermes:~# nm /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime_d.so | grep Py_InitM U Py_InitModule4TraceRefs It seems it is - hm ... Thanks, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Sun, Oct 22, 2017 at 10:15:51PM +0200, Karsten Hilbert wrote: > The python2.7-dbg build is 32 bits: ... > The python2.7 build (no -dbg) does not have symbols. More to the point: /usr/bin/python2.7: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=91226399fb434d138f166a5c8eca04385ea2e41f, stripped /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f09c7cc78b41421d3cee1f418b4d45772a3db701, stripped Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote: > > Debug memory block at address p=0x717b7c: API '' > > 0 bytes originally requested > > The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): > > at p-3: 0x03 *** OUCH > > at p-2: 0x4e *** OUCH > > at p-1: 0x00 *** OUCH > > Because memory is corrupted at the start, the count of bytes > > requested > >may be bogus, and checking the trailing pad bytes may segfault. > > The 4 pad bytes at tail=0x717b7c are not all FORBIDDENBYTE (0xfb): > > at tail+0: 0x00 *** OUCH > > at tail+1: 0x00 *** OUCH > > at tail+2: 0x00 *** OUCH > > at tail+3: 0x00 *** OUCH > > The block was made by call #0 to debug malloc/realloc. > > Fatal Python error: bad ID: Allocated using API '', verified using API > > 'o' > > ... > > Can anyone give more guidance on what the above python debug > > output might vaguely point to ? > > It points to a memory corruption. > > I would approach the problem by means of debugging: put a write > breakpoint at the corrupted address "0x717b7c" and check what part > of the system accesses it (this assumes you are using a CPU > supporting write breakpoints). > It may be very tedious as the address might be accessed very often > legally before it gets corrupted. > > Another approach may be to use a tool designed for memory debugging, > e.g. "valgrind". Hi Dieter, thanks for your guidance. I fear this approach is out of my class. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Sun, Oct 22, 2017 at 11:10:33PM +0200, Karsten Hilbert wrote: >> It points to a memory corruption. > > thanks for your guidance. I fear this approach is out of my class. For what it's worth I have run a successful overnight memory stress test (memtest86+) so it shouldn't be a bad bit in hardware. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote:
> It points to a memory corruption.
While running valgrind and friends is beyond my capabilitis I
have run the problem through gdb to at least obtain a stack
trace to see what gives:
...
==> verifying target database schema ...
==> checking migrated data for plausibility ...
Done bootstrapping GNUmed database: We very likely succeeded.
log:
/home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
Debug memory block at address p=0x6aab7c: API ' '
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x33 *** OUCH
at p-2: 0x47 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes
requested
may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x6aab7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API ' ', verified using API
'o'
Program received signal SIGABRT, Aborted.
0xb7fd9ce9 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fd9ce9 in __kernel_vsyscall ()
#1 0xb7d6edd0 in __libc_signal_restore_set (set=0xbfffed40) at
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3 0xb7d70297 in __GI_abort () at abort.c:89
#4 0x0055fb74 in Py_FatalError (msg=0xbfffefec "bad ID: Allocated
using API '\037', verified using API 'o'") at ../Python/pythonrun.c:1700
#5 0x00499adb in _PyObject_DebugCheckAddressApi (api=111 'o',
p=0x6aab7c <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1640
#6 0x004997a5 in _PyObject_DebugFreeApi (api=111 'o', p=0x6aab7c
<_Py_ZeroStruct>) at ../Objects/obmalloc.c:1527
#7 0x0049964f in _PyObject_DebugFree (p=0x6aab7c <_Py_ZeroStruct>) at
../Objects/obmalloc.c:1471
#8 0x00471043 in int_dealloc (v=0x6aab7c <_Py_ZeroStruct>) at
../Objects/intobject.c:139
#9 0x00497bee in _Py_Dealloc (op=False) at ../Objects/object.c:2262
#10 0x00489bad in dict_dealloc (mp=0xb7888f34) at
../Objects/dictobject.c:1085
Python Exception 'utf-8' codec can't
decode bytes in position 1-2: unexpected end of data:
#11 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
Python Exception 'utf-8' codec can't
decode bytes in position 1-2: unexpected end of data:
#12 0x004b9ab7 in subtype_dealloc (self=) at
../Objects/typeobject.c:1035
Python Exception 'utf-8' codec can't
decode bytes in position 1-2: unexpected end of data:
#13 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
#14 0x0044dc7a in instancemethod_dealloc (im=0xb78984b4) at
../Objects/classobject.c:2388
#15 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
#16 0x004885d7 in insertdict_by_entry (mp=0xb78880d4, key='_shutdown',
hash=598970216, ep=0x88d6d4, value=None) at ../Objects/dictobject.c:519
#17 0x00488857 in insertdict (mp=0xb78880d4, key='_shutdown',
hash=598970216, value=None) at ../Objects/dictobject.c:556
#18 0x0048910f in dict_set_item_by_hash_or_entry (
op={'current_thread': ,
'_BoundedSemaphore': None, 'currentThread': ,
'_Timer': None, '_format_exc': None, 'Semaphore': , '_deque': None, 'activeCount': ,
'_profile_hook': None, '_sleep': None, '_trace_hook': None, 'ThreadError':
, '_enumerate': None, '_start_new_thread': None,
'BoundedSemaphore': , '_shutdown': None,
'__all__': ['activeCount', 'active_count', 'Condition', 'currentThread',
'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore',
'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local',
'stack_size'], '_Event': , 'active_count': , '__package__': None, '_Condition': , '_RLock': , '_test': , 'local': , '__doc__': "Thread modul...(truncated), key='_shutdown',
hash=598970216, ep=0x0, value=None) at ../Objects/dictobject.c:795
#19 0x00489285 in PyDict_SetItem (
op={'current_thread': ,
'_BoundedSemaphore': None, 'currentThread': ,
'_Timer': None, '_format_exc': None, 'Semaphore': , '_deque': None, 'activeCount': ,
'_profile_hook': None, '_sleep': None, '_trace_hook': None, 'ThreadError':
, '_enumerate': None, '_start_new_thread': None,
'BoundedSemaphore': , '_shutdown': None,
'__all__': ['activeCount', 'active_count', 'Condition', 'currentThread',
'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore',
'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local',
'stack_size'], '_
Re: right list for SIGABRT python binary question ?
On Mon, Oct 23, 2017 at 03:26:18PM +0200, Thomas Jollans wrote: > >> It points to a memory corruption. > > > > While running valgrind and friends is beyond my capabilitis I > > have run the problem through gdb to at least obtain a stack > > trace to see what gives: > > I wouldn't read too much into that. You know that somehow some memory > got corrupted. You know at which point Python trips over the error - but > that doesn't really tell you anything about how the memory initially got > corrupted. Thanks, I know. However, I am grasping for straws here since I am unable to "properly" debug the python binary as such. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Tue, Oct 24, 2017 at 08:47:58PM +0200, M.-A. Lemburg wrote: > >> This error suggests that you have 32- and 64-bit versions of > >> Python and mxDateTime mixed in your installation. > >> > >> Py_InitModule4 is only available in the 32-bit build of > >> Python. With the 64-bit build, it's called Py_InitModule4_64. ... > Could you check whether you have similar import errors with > other modules that have C extensions ? E.g. lxml. > > What you're seeing appears to be a compilation problem > with Python 2.7.14 on Debian. The executable doesn't appear > to export its symbols to the .so files, or only some of them. Let's see: python-lxml: Installiert: 4.0.0-1 Installationskandidat: 4.0.0-1 Versionstabelle: *** 4.0.0-1 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 3.7.1-1 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages python-lxml-dbg: Installiert: (keine) Installationskandidat: 4.0.0-1 Versionstabelle: 4.0.0-1 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 3.7.1-1 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages ncq@hermes:~$ python2.7-dbg Python 2.7.14 (default, Sep 17 2017, 18:50:44) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import lxml [45350 refs] >>> ncq@hermes:~$ python Python 2.7.14 (default, Sep 17 2017, 18:50:44) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import lxml >>> Also, psycogp2 imports just fine. Now that I have python-egenix-mx-base-dbg: Installiert: 3.2.9-1 Installationskandidat: 3.2.9-1 Versionstabelle: *** 3.2.9-1 990 500 http://httpredir.debian.org/debian stretch/main i386 Packages 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status mx.DateTime imports fine as well (but the SIGABRT persists). Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2.ProgrammingError: syntax error at or near "\"
On Fri, Oct 27, 2017 at 08:35:20AM -0700, maheshyadav1...@gmail.com wrote:
> I am using 'psycopg2' library to access my PostgreSQL database from a python.
> I want to pass a variable input in psql query something like this :-
>
> psql>>\set my_user table1
> psql>>select * from :my_user limit 10;
>
> So I am just running these sql commands and getting this error :-
>
> >>> cur.execute("""\set my_user table1""")
> Traceback (most recent call last):
> File "", line 1, in
> psycopg2.ProgrammingError: syntax error at or near "\"
> LINE 1: \set my_user table1
\set is a psql specific pseudo command rather than SQL. Only
SQL code can be run through psycopg2.
You want to read up on query parameter handling in the
psycopg2 docs. Psycopg2 and (/usr/bin/)psql(.exe) are not the
same thing.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
https://mail.python.org/mailman/listinfo/python-list
Re: Repairing Python installation?
On Sat, Oct 28, 2017 at 08:41:34PM +, Martin Schöön wrote: > It seems something is amiss with my Python 2.7 installation. Revisiting > Nikola (static web site generator written in Python) for the first time > in several years the other day I experience some unexpected problems. I > got some help form the Nikola people and the conclusion is something > is broken with my Python 2.7. Pip list throws exceptions at me ... > All this is happening on a Debian machine. Exceptions or crashes of the python interpreter ? Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Invoking return through a function?
> In this specific case, I wanted to invoke a return if the key doesn't > exist (as I wrote in my post). But this is not strictly relevant, my > question was more general. To phrase it in yet another way: is there > *any other way* to invoke return on a function, except by explicitly > writing "return" in its body? Sure: fall off the end of the function. But that's not what you are after. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Mon, Oct 30, 2017 at 02:02:25PM +0100, M.-A. Lemburg wrote: > PS: Please CC me on replies as I don't regularly read c.l.p anymore. Sure. > >> Could you check whether you have similar import errors with > >> other modules that have C extensions ? E.g. lxml. > >> > >> What you're seeing appears to be a compilation problem > >> with Python 2.7.14 on Debian. The executable doesn't appear > >> to export its symbols to the .so files, or only some of them. > > > > Let's see: > > ... using -dbg packages for everything, the imports work ... > > Ah, so you were mixing debug packages with non-debug ones. This > explains the import errors. I am not sure I do. I installed normal and -dbg packages for modules with c extensions, say psycopg2: python-psycopg2: Installiert: 2.7.3-1 Installationskandidat: 2.7.3-1 Versionstabelle: *** 2.7.3-1 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 2.6.2-1 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages python-psycopg2-dbg: Installiert: 2.7.3-1 Installationskandidat: 2.7.3-1 Versionstabelle: *** 2.7.3-1 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 2.6.2-1 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages Now, when running either python2.7 or python2.7-dbg, which are installed alongside python2.7-dbg: Installiert: 2.7.14-2 Installationskandidat: 2.7.14-2 Versionstabelle: *** 2.7.14-2 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 2.7.13-2 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages python2.7: Installiert: 2.7.14-2 Installationskandidat: 2.7.14-2 Versionstabelle: *** 2.7.14-2 990 990 http://httpredir.debian.org/debian buster/main i386 Packages 500 http://httpredir.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status 2.7.13-2 500 500 http://httpredir.debian.org/debian stretch/main i386 Packages the Debian version does (should ?) take care to import either the -dbg or the normal version of modules. It seems it so does because when I got both module versions installed I don't get any import errors. So I don't think I am mixing, at least not to my knowledge. (But I still get the SIGABORT on shutdown regardless.) > Do you just see the SIGABRT when running the debug versions or > also with the production versions (memory management works differently > in Python debug mode) ? Either version fails. Why haven't I tried running this under python3 ? Because the whole shebang is part of a wxPython application (GNUmed) and there are no Debian packages for wxPython/wxPhoenix on py3 as far as I know. > BTW: It would help if you'd post the stack trace with symbols. > The one you posted in one of your earlier emails only includes > addresses. I'd gladly comply if I knew how. This is what apt says about python2.7-dbg: Package: python2.7-dbg Version: 2.7.14-2 Description-en: Debug Build of the Python Interpreter (version 2.7) The package holds two things: . - A Python interpreter configured with --pydebug. Dynamically loaded modules are searched as _d.so first. Third party extensions need a separate build to be used by this interpreter. - Debug information for standard python interpreter and extensions. So from that I conferred it does contain symbols. I am getting a fresh run under gdb with python2.7-dbg. Maybe you can point out where you'd have expected to see symbols and help me figure out which -dbg package is missing on this Debian system: [...] ==> verifying target database schema ... ==> checking migrated data for plausibility ... Done bootstrapping GNUmed database: We very likely succeeded. log: /home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log Debug memory block at address p=0x6aab7c: API ' ' 0 bytes originally requested The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): at p-3: 0x33 *** OUCH at p-2: 0x47 *** OUCH at p-1: 0x00 *** OUCH Because memory is corrupted at the
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 09:21:46AM +0100, dieter wrote: > >> It points to a memory corruption. > > The i386/x64 architecture supports memory access breakpoints > and GDB, too, has support for this. You know the address which > gets corrupted. Thus, the following apporach could have a chance > to succeed: > >Put a "memory write" breakpoint on the address which gets corrupted. >this should stop the program each time this address is written; >Check then the backtrace. As the address forms part of the >address block prologue, it should only be accessed from >Python's "malloc" (and "free") implementation. Any other access >indicates bad behaviour. I understand. Thank you for the explanation. This may seem like a dumb question: the actual address that gets corrupted varies from run to run (it may be the same "place" in the code but that place gets put at a different address each run). Since I don't know the address of a given run, how do I set a break point on that address ? It seems to me I first need to map the "place" to its address before the SIGABRT happens. How do I find out out which "place" needs to be mapped from the output I already have ? (the "place" is the memory block you refer to) Other than that I understand what you are getting at and am willing to try. Thanks, Karsten >Should your program get stopped too often (because the memory >block is reused too often), you must find a good point in your >program to activate the memory access breakpoint in a delayed way. >You could use the Python debugger for this: execute significant >parts of your program in the Python debugger; switching to >GDB, check whether the address is already corrupted - if >so, restart and refine the checks above in the portion of your program >which caused the corruption. If the part in your program >is sufficiently small, you can activate the memory access breakpoint. >This approach may also be feasible, should you use a CPU >without memory access breakpoints. -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 10:27:54AM +0100, Karsten Hilbert wrote: > > >> It points to a memory corruption. > > > > The i386/x64 architecture supports memory access breakpoints > > and GDB, too, has support for this. You know the address which > > gets corrupted. Thus, the following apporach could have a chance > > to succeed: > > > >Put a "memory write" breakpoint on the address which gets corrupted. > >this should stop the program each time this address is written; > >Check then the backtrace. As the address forms part of the > >address block prologue, it should only be accessed from > >Python's "malloc" (and "free") implementation. Any other access > >indicates bad behaviour. > > I understand. Thank you for the explanation. This may seem > like a dumb question: the actual address that gets corrupted > varies from run to run (it may be the same "place" in the > code but that place gets put at a different address each > run). Since I don't know the address of a given run, how do I > set a break point on that address ? It seems to me I first > need to map the "place" to its address before the SIGABRT > happens. How do I find out out which "place" needs to be > mapped from the output I already have ? Or rather: I need to find out which "place" a given address refers to, check whether the changing addresses always belong to the same "place" between runs and _then_ map a "place" to its address and breakpoint that address on yet another run. It might seem gdb> info symbol should give me the "place". Then gdb> info address on another run. Or even just "watch https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 11:14:08AM +0100, Karsten Hilbert wrote:
> Or rather: I need to find out which "place" a given address
> refers to, check whether the changing addresses always belong
> to the same "place" between runs and _then_ map a "place" to
> its address and breakpoint that address on yet another run.
>
> It might seem
>
> gdb> info symbol
>
> should give me the "place".
Given this:
Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x33 *** OUCH
at p-2: 0x47 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes
requested
may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x6aab7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API '', verified using API
'o'
Program received signal SIGABRT, Aborted.
0xb7fd9ce9 in __kernel_vsyscall ()
(gdb) info symbol 0x6aab7c
_Py_ZeroStruct in section .data of /usr/bin/python2.7-dbg
(gdb)
my assumption would be that something clobbers 0x6aab7c,
which seems to be in (?) _Py_ZeroStruct in this run. I'll
re-run a few times to make sure the corruption "reliably"
hits _Py_ZeroStruct.
If so, I'll set a memory write breakpoint on _Py_ZeroStruct.
Am I on the right track ?
Thanks,
Karsten
BTW, the backtrace for this run was ...
(gdb) bt
#0 0xb7fd9ce9 in __kernel_vsyscall ()
#1 0xb7d70dd0 in __libc_signal_restore_set (set=0xbfffee90) at
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3 0xb7d72297 in __GI_abort () at abort.c:89
#4 0x0055fb74 in Py_FatalError (msg=0xb13c "bad ID: Allocated
using API '\037', verified using API 'o'") at ../Python/pythonrun.c:1700
#5 0x00499adb in _PyObject_DebugCheckAddressApi (api=111 'o',
p=0x6aab7c <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1640
#6 0x004997a5 in _PyObject_DebugFreeApi (api=111 'o', p=0x6aab7c
<_Py_ZeroStruct>) at ../Objects/obmalloc.c:1527
#7 0x0049964f in _PyObject_DebugFree (p=0x6aab7c <_Py_ZeroStruct>) at
../Objects/obmalloc.c:1471
#8 0x00471043 in int_dealloc (v=0x6aab7c <_Py_ZeroStruct>) at
../Objects/intobject.c:139
... so I could've known without "info symbol" :-)
#9 0x00497bee in _Py_Dealloc (op=False) at ../Objects/object.c:2262
#10 0x004885d7 in insertdict_by_entry (mp=0xb7fc5674,
key='dont_write_bytecode', hash=591857026, ep=0x7c5c08, value=None) at
../Objects/dictobject.c:519
#11 0x00488857 in insertdict (mp=0xb7fc5674, key='dont_write_bytecode',
hash=591857026, value=None) at ../Objects/dictobject.c:556
#12 0x0048910f in dict_set_item_by_hash_or_entry (
op={
'setrecursionlimit': None,
'dont_write_bytecode': None,
'getfilesystemencoding': ,
'long_info': ,
'path_importer_cache': None,
'stdout': ,
'getprofile': ,
'__stdin__': ,
'version_info': ,
'exc_clear': , 'gettotalrefcount':
, 'getrefcount': , 'byteorder': 'little', '_clear_type_cache': None, 'excepthook':
, 'subversion': ('CPython', '', ''),
'_multiarch': None, 'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info':
None, 'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll
Rights Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights
Reserved.\n\nCopyright (c) 1995-2001 Corporation for Nation...(truncated),
key='dont_write_bytecode', hash=591857026, ep=0x0, value=None
) at ../Objects/dictobject.c:795
#13 0x00489285 in PyDict_SetItem (
op={'setrecursionlimit': None, 'dont_write_bytecode': None,
'getfilesystemencoding': ,
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile
Re: right list for SIGABRT python binary question ?
> my assumption would be that something clobbers 0x6aab7c,
> which seems to be in (?) _Py_ZeroStruct in this run. I'll
> re-run a few times to make sure the corruption "reliably"
> hits _Py_ZeroStruct.
>
> If so, I'll set a memory write breakpoint on _Py_ZeroStruct.
Interestingly, on subsequent runs, it seems to hit the same
address, 0x6aab7c, belonging to the same symbol, _Py_ZeroStruct.
This is what happens:
(gdb) watch *0x6aab7c
Hardware watchpoint 1: *0x6aab7c
(gdb) run
Starting program: /usr/bin/python2.7-dbg ./bootstrap_gm_db_system.py
--log-file=./bootstrap-latest.log --conf-file=bootstrap-latest.conf --
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Hardware watchpoint 1: *0x6aab7c
Old value = 0
New value = -1208182272
_Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70
70 ../Objects/object.c: Datei oder Verzeichnis nicht gefunden.
(gdb)
which means I'll probably have to apply the delayed
breakpoint setting strategy, or else it is just some initial
relocation at startup. Let's see what "cont" brings. The next
hit after the Python script has run until just before it
usually aborts:
Hardware watchpoint 1: *0x6aab7c
Old value = -1208182272
New value = 0
_Py_ForgetReference (op=False) at ../Objects/object.c:2255
2255in ../Objects/object.c
(gdb)
The backtrace at this point says:
(gdb) bt
#0 _Py_ForgetReference (op=False) at ../Objects/object.c:2255
#1 0x00497be0 in _Py_Dealloc (op=False) at ../Objects/object.c:2261
#2 0x004885d7 in insertdict_by_entry (mp=0xb7fc5674,
key='dont_write_bytecode', hash=591857026, ep=0x7c5c08, value=None) at
../Objects/dictobject.c:519
#3 0x00488857 in insertdict (mp=0xb7fc5674, key='dont_write_bytecode',
hash=591857026, value=None) at ../Objects/dictobject.c:556
#4 0x0048910f in dict_set_item_by_hash_or_entry (
op={'setrecursionlimit': None, 'dont_write_bytecode': None,
'getfilesystemencoding': ,
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile': , '__stdin__': , 'version_info': ,
'exc_clear': , 'gettotalrefcount': , 'getrefcount': ,
'byteorder': 'little', '_clear_type_cache': None, 'excepthook': , 'subversion': ('CPython', '', ''), '_multiarch': None,
'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': None,
'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll Rights
Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights Reserved.\n\nCopyright
(c) 1995-2001 Corporation for Nation...(truncated), key='dont_write_bytecode',
hash=591857026, ep=0x0, value=None) at ../Objects/dictobject.c:795
#5 0x00489285 in PyDict_SetItem (
op={'setrecursionlimit': None, 'dont_write_bytecode': None,
'getfilesystemencoding': ,
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile': , '__stdin__': , 'version_info': ,
'exc_clear': , 'gettotalrefcount': , 'getrefcount': ,
'byteorder': 'little', '_clear_type_cache': None, 'excepthook': , 'subversion': ('CPython', '', ''), '_multiarch': None,
'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': None,
'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll Rights
Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights Reserved.\n\nCopyright
(c) 1995-2001 Corporation for Nation...(truncated), key='dont_write_bytecode',
value=None) at ../Objects/dictobject.c:848
#6 0x0049281f in _PyModule_Clear (m=) at
../Objects/moduleobject.c:139
#7 0x0054a3ec in PyImport_Cleanup () at ../Python/import.c:540
#8 0x0055c53c in Py_Finalize () at ../Python/pythonrun.c:458
#9 0x0055fe9c in Py_Exit (sts=1) at ../Python/pythonrun.c:1783
#10 0x0055e0fc in handle_system_exit () at ../Python/pythonrun.c:1151
#11 0x0055e152 in PyErr_PrintEx (set_sys_last_vars=1) at
../Python/pythonrun.c:1161
#12 0x0055dd5b in PyErr_Print () at ../Python/pythonrun.c:1064
#13 0x0055d61f in PyRun_SimpleFileExFlags (fp=0x7ee010,
filename=0xb7e6 "./bootstrap_gm_db_system.py", closeit=1, flags=0xb4f4)
at ../Python/pythonrun.c:952
#14 0x0055cc4e in PyRun_AnyFileExFlags (fp=0x7ee010,
filename=0xb7e6 "./bootstrap_gm_db_system.py", closeit=1, flags=0xb4f4)
at ../Python/pythonrun.c:752
#15 0x00577cb0 in Py_Main (argc=5, argv=0xb684) at
../Modules/main.c:645
#16 0x004259c8 in main (argc=5, argv=0xb684) at
../Modules/python.c:20
And continuing hits the SIGABRT right away:
(gdb) cont
Continuing.
Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBY
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 12:40:56PM +0100, Karsten Hilbert wrote: > Interestingly, on subsequent runs, it seems to hit the same > address, 0x6aab7c, belonging to the same symbol, _Py_ZeroStruct. > > This is what happens: > > (gdb) watch *0x6aab7c > Hardware watchpoint 1: *0x6aab7c > (gdb) run > Starting program: /usr/bin/python2.7-dbg ./bootstrap_gm_db_system.py > --log-file=./bootstrap-latest.log --conf-file=bootstrap-latest.conf -- > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". > > Hardware watchpoint 1: *0x6aab7c > > Old value = 0 > New value = -1208182272 > _Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70 > 70 ../Objects/object.c: Datei oder Verzeichnis nicht gefunden. > (gdb) I forgot the backtrace from this point: (gdb) bt #0 _Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70 #1 0x0051e052 in _PyBuiltin_Init () at ../Python/bltinmodule.c:2708 #2 0x0055bebf in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:233 #3 0x0055c4dd in Py_Initialize () at ../Python/pythonrun.c:381 #4 0x00577805 in Py_Main (argc=5, argv=0xb684) at ../Modules/main.c:551 #5 0x004259c8 in main (argc=5, argv=0xb684) at ../Modules/python.c:20 Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 11:58:53AM -0400, Dennis Lee Bieber wrote: > >I understand. Thank you for the explanation. This may seem > >like a dumb question: the actual address that gets corrupted > >varies from run to run (it may be the same "place" in the > > Since the process virtual memory space should be the same on each run > -- even heap allocations should be deterministic, UNLESS the program is > doing things with external non-deterministic data (the time of day, random > numbers not initialized with a repeatable seed, dynamic web pages, multiple > threads that are non-deterministic due to I/O delays, etc.), Mine doesn't to my knowledge hence I can expect "fixed" addresses -- which is confirmed by what I found during consecutive runs. Thanks for the affirmative explanation. > the only other source for varying addresses would be > OS-level shared libraries that are getting mapped at > different locations due to changes in the order of other > programs running. IOW I should take care I haven't run any relevant amount of Python code before debugging this problem, it seems ? > The physical memory may vary due to paging fragmentation, > but should still be the same virtual addresses. I see. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Wed, Nov 01, 2017 at 04:28:02PM +, Grant Edwards wrote: > >>I understand. Thank you for the explanation. This may seem > >>like a dumb question: the actual address that gets corrupted > >>varies from run to run (it may be the same "place" in the > > > > Since the process virtual memory space should be the same on each run > > Not with modern OS kernels: > > https://en.wikipedia.org/wiki/Address_space_layout_randomization I feared as much. However, I discovered that during subsequent runs the address seems stable due to shared libraries being preloaded: On the first run the affected code is loaded at some randomized address and the corruption is hit at a certain address giving me the value to watch on during subsequent runs, as long as the affected code is not evicted from being preloaded the address is stable. I have posted backtraces taken from the address being watched. Does that help any at all ? Thanks, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Aw: Try: Except: evaluates to True every time
Try in an interactive interpreter: python> "a string" is True Karsten > Gesendet: Samstag, 04. November 2017 um 16:31 Uhr > Von: "brandon wallace" > An: python-list@python.org > Betreff: Try: Except: evaluates to True every time > > > I have this code that tests a server to see if it is listening on port 123 > runs and evaluates to True every time. Even if the server does not exist but > it is not supposed to do that. I am getting no error message at all. What is > going on with this code? > > > > #!/usr/bin/env python > > import socket > > hostname = ["192.168.1.22", "192.168.1.23", "200.168.1.24", "19.0.0.0"] > port = 123 > > def check_udp(hosts, port_num): > '''Test the UDP port on a remove server.''' > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > for host in hosts: > try: > s.connect((host, port_num)) > return "Port 53 is reachable on: %s" % host > except socket.error as e: > return "Error on connect: %s" % e > > check_udp(hostname, port) > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Try: Except: evaluates to True every time
On Sat, Nov 04, 2017 at 05:07:26PM +0100, Karsten Hilbert wrote: > Try in an interactive interpreter: > >python> "a string" is True Or, rather, python> if 'a string': print 'success' Sorry, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: right list for SIGABRT python binary question ?
On Fri, Nov 03, 2017 at 07:31:56AM +0100, dieter wrote: > > I have posted backtraces taken from the address being > > watched. Does that help any at all ? > > Only in the case that the error is "local", i.e. detected > (quite) immediately. > > You might be in this case as you have observed that the address > is stable after library preload. Thus, it might not be a heap > address but one associated with one of the libraries. Such > a memory block should never be "freed". The backtrace would allow > you to determine the library affected. Obtain its source. Recompile > with symbols and try to find out where this memory block comes from. Dieter, thanks for taking the time to explain the general procedure. However, recompiling a library and trying to find out where given block of memory comes from is way beyond skills. I fear I have reached the end of what I can do. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Try: Except: evaluates to True every time
On Sun, Nov 05, 2017 at 11:28:44AM +1100, Steve D'Aprano wrote: > > Try in an interactive interpreter: > > > >python> "a string" is True > > Did you try that yourself? Yes, eventually, which is why I corrected myself publicly. However, while it doesn't return True (as I mistakenly suggested) it does return False, always, which is the very same reason for OP's problem, namely returning a string, doing a logic test on that, and assuming that would tell whether the check succeeded or failed. Unless I am totally mistaken :-) Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Any good explanations on pd.merge(df,df2, on=['Code', 'Region'])
On Wed, Nov 08, 2017 at 09:26:04AM +, David Shi via Python-list wrote: > I am trying to gain a clear understanding on pd.merge(df,df2, on=['Code', > 'Region']). > Can anyone assist? ncq@hermes:~$ python Python 2.7.14 (default, Sep 17 2017, 18:50:44) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> pd.merge(df,df2, on=['Code', 'Region']) Traceback (most recent call last): File "", line 1, in NameError: name 'pd' is not defined >>> You will need to provide more context to get help. Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Shoulid constants be introduced to Python?
On Thu, Nov 16, 2017 at 05:35:59PM -0500, ROGER GRAYDON CHRISTMAN wrote: > Well, pi already does have a value: > import math math.pi > > 3.141592653589793 > > but it's not a constant in the sense you are looking for: And, it's not really a constant at all, it's only got a constant definition :-) > The only PEP I saw that makes any mention of constants is the PEP 8 Style > Guide, > which recommends all constants be named with all caps, such as "math.PI". > (Why the math module doesn't do that beats me, unless it is there for > hyster^H^H^H^H^Historical reasons.) So, import math math.PI = math.pi seems helpful :) Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Thu, Nov 23, 2017 at 08:46:01PM +0100, Thomas Jollans wrote: > > I mean for a real practical situation - for example for an average > > Python programmer or someone who seeks a programmer job. > > And who does not have a 500-key keyboard, > > I don't think it's too much to ask for a programmer to have the > technology and expertise necessary to type their own language in its > proper alphabet. Surely, but it can make reusing code a nightmare. Using function arguments written in Thai script ? Understanding, let alone being able to read, code written in Arabic ? No, thanks. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Thu, Nov 23, 2017 at 05:47:04PM -0700, Ian Kelly wrote: > > Understanding, let alone being able to read, code written in Arabic ? > > People are going to write code in Arabic whether you like it or not, > because not everybody speaks English, and not everybody who does > *wants* to use it. Now, would you prefer to read code where the > variable names are written in Arabic script, or where the variable > names are still in Arabic but transliterated to Latin characters? > Either way, you're not going to be able to understand it, so I'm not > sure why it makes a difference to you. I can visually pattern match "words" based on Latin characters. I can't with Arabic letters. So that answers the "would you prefer" part. However, the main point has been answered - Python already does what is talked about. End of story. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Thu, Dec 07, 2017 at 01:29:11PM +1100, Steve D'Aprano wrote: > Actually, no, the answer to my question is very simple: Lawrence is mistaken > about Linux not doing file associations. It does -- it is merely handled by > the desktop environment (if there is one). We _can_ go one level below that: mailcap is independant of the desktop environment, it does associate file (content) types with suitable (hopefully) applications. The one thing it doesn't "do" that's relevant to OPs post is that it doesn't react to clicks or taps in order to _execute_ those associations. Best, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: we want python software
> > A junior programmer sees the unlimited possibilities of programming. No > > montain is too high to climb. > > > > A seasoned programmer is elated if they can get anything to work at all. Good judgement comes from experience. And a lot of that comes from bad judgement. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: Anything similar to __END__ in perl
On Thu, Dec 07, 2017 at 11:55:48PM -0600, Peng Yu wrote: > Hi, perl has __END__ which ignore all the lines below it. > > Is there anything similar to __END__ in python? Thanks. Something similar is: import sys sys.exit() Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Anything similar to __END__ in perl
On Fri, Dec 08, 2017 at 02:19:13AM -0800, Rustom Mody wrote: > > > Hi, perl has __END__ which ignore all the lines below it. > > > > > > Is there anything similar to __END__ in python? Thanks. > > > > Something similar is: > > > > import sys > > sys.exit() > > That will give syntax (or something) errors for what follows True enough, didn't think of that. However, OP asked for something _similar_ :-) Which proves that any answer needs a definition of "similar" by OP. Or at least: how similar is similar _enough_ to __END__ in Perl. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Where has the practice of sending screen shots as source code come from?
On Sun, Jan 28, 2018 at 03:04:26PM +, Steven D'Aprano wrote: > (The day a programmer posts a WAV file of themselves reading their code > out aloud, is the day I turn my modem off and leave the internet forever.) And the clever hack will be to send a WAV that tricks your modem into surprising things by whistling just the right way ... :-) Best, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: read Unicode characters one by one in python2
On Sat, Feb 24, 2018 at 10:17:35AM -0600, Peng Yu wrote: > Here shows some code for reading Unicode characters one by one in > python2. Is it the best code for reading Unicode characters one by one > in python2? > > https://rosettacode.org/wiki/Read_a_file_character_by_character/UTF8#Python This seems off, because in Python2 you can also specify an encoding. However, you seem to be asking about reading the console which comes with more caveats. So, what is it ? Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Re: Pre-Pre-PEP: The datetime.timedeltacal class
Am Sun, Apr 17, 2022 at 11:10:01AM +1200 schrieb Greg Ewing: > On 17/04/22 9:17 am, Karsten Hilbert wrote: > > Take this medication for 1 month ! > > > >is quite likely to mean "take it for 28 days". > > Except when your doctor prescribes 90 days worth of tablets, It *still* means "take for 28 days" :-) Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: Automatic Gain Control in Python?
Am Mon, Jun 06, 2022 at 02:08:41PM -0400 schrieb Steve GS: > Yes, it is real-time play back of a pre-recorded presentation. ... What all of us around here don't understand is why you insist on not being able to modify the data to your heart's content inbetween this ... > [...] pulling in the programs ... and that ... > and playing them for an audience. ?? IOW, during the "and" phase. Best, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: How to replace characters in a string?
Am Wed, Jun 08, 2022 at 11:09:05AM +0200 schrieb Dave:
> myString = 'Hello'
> myNewstring = myString.replace(myString,'e','a’)
That won't work (last quote) but apart from that:
myNewstring = myString.replace('e', 'a')
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Subtract n months from datetime [Why?]
> What makes sense depends on where you're looking from. > > It's 28 February, you need to keep it for 5 years, therefore you could > reason that you can dispose of it on 28 February, 5 years hence. > > However, that happens to be a leap year. > > Should you still have it on 29 February? Nope because that's *after* the 5 years (they end Feb 28). If it originates on March 1st, however, you shouldn't dispose of it on Feb 29th just yet. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Am Sun, Oct 09, 2022 at 05:37:59AM +0100 schrieb Axy via Python-list: > Python is awesome because it's semantic is clear for the majority, but there > are places > that look odd. In case of "for", "else" looks logically tied with "for" > clause, but > actually it is not. It's tied with "break" statement and I overlooked that > even after > re-reading the language reference. If "else" was named like > "never_broken_loop" or > "nobreak", the semantic would be perfectly clear. But, what's done is done. Or, "eventually". Sadly, "finally" is already taken, and with slightly different semantics... Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: What to use for finding as many syntax errors as possible.
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon: > Op 9/10/2022 om 17:49 schreef Avi Gross: > >My guess is that finding 100 errors might turn out to be misleading. If you > >fix just the first, many others would go away. > > At this moment I would prefer a tool that reported 100 errors, which would > allow me to easily correct 10 real errors, over the python strategy which > quits > after having found one syntax error. But the point is: you can't (there is no way to) be sure the 9+ errors really are errors. Unless you further constrict what sorts of errors you are looking for and what margin of error or leeway for false positives you want to allow. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: What to use for finding as many syntax errors as possible.
Am Sun, Oct 09, 2022 at 07:51:12PM +0200 schrieb Antoon Pardon: > >But the point is: you can't (there is no way to) be sure the > >9+ errors really are errors. > > > >Unless you further constrict what sorts of errors you are > >looking for and what margin of error or leeway for false > >positives you want to allow. > > Look when I was at the university we had to program in Pascal and > the compilor we used continued parsing until the end. Sure there > were times that after a number of reported errors the number of > false positives became so high it was useless trying to find the > remaining true ones, but it still was more efficient to correct the > obvious ones, than to only correct the first one. > > I don't need to be sure. Even the occasional wrong correction > is probably still more efficient than quiting after the first > syntax error. A-ha, so you further defined your context. Under which I can agree to the objective :-) Best, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: for -- else: what was the motivation?
Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram: > I often follow this rule. For me, it's about readability. Compare: > > if not open( disk ): > error( "Can't open disk" ) > else: > printf( "now imagine there's some larger block here" ) ... ad infinitum Should this not be if not open( disk ): error( "Can't open disk" ) else: do_lots_of_things_with(disk) as for readability ? Or even if not open( disk ): error( "Can't open disk" ) return what_needs_to_be_returned do_lots_of_things_with(disk) The latter version may need some code reorganization, though. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: for -- else: what was the motivation?
> which had special combinations for all the BASIC keywords). And if you > go this way, why not go a step further and dissociate the program from > its linear text representation? Add footnotes, different views, > hyperlinks, format mathematical expressions like formulas, etc. http://literateprogramming.com/ Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: A trivial question that I don't know - document a function/method
Am Sat, Oct 22, 2022 at 09:49:55PM -0400 schrieb Thomas Passin: > def make_title_from_headline(self, p, h): > """From node title, return title with over- and underline- strings. ... >RETURNS >a string > """ > def plot(self, stackposition=MAIN, clearFirst=True): > """Plot a 2-D graph. ... > RETURNS > nothing > """ Would it not, these days, be clearer to def make_title_from_headline(self, p, h) -> str: def plot(self, stackposition=MAIN, clearFirst=True) -> None: and use RETURNS (or Returns:) only when what is returned warrants further explanation (say, as to what is returned when). Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: A trivial question that I don't know - document a function/method
Am Sun, Oct 23, 2022 at 05:16:48PM -0400 schrieb Thomas Passin: > > def make_title_from_headline(self, p, h) -> str: > > > > def plot(self, stackposition=MAIN, clearFirst=True) -> None: > 1. Knowing the type of a parameter isn't all you usually want to know; Sure, as I said: > >and use RETURNS (or Returns:) only when what is returned > >warrants further explanation (say, as to what is returned > >when). same for arguments, which *usually* warrant some further explanation, except for rare cases such as def format_a_string(string2format:str=None) -> str: where string2format just might not require further explanation. > 2. If the type information isn't in the docstring, it won't be reported by > reporting > tools that use the docstring. While true such tools could be considered suboptimal (these days, again as I said). > Then there are all those cases where the signature hasn't been type-annotated True but OPs question was *how* to document so there's no perceived problem with having to document. > I would say that if the types are annotated, the method is simple enough, and > the names > are clear enough, sure, go ahead and rely on the type annotations. The most > important > thing is that readers can understand what the arguments and returns are > intended to be, > so some flexibility makes sense. +1 Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
"mailcap" to be removed (3.13) -- suggested replacement ?
Dear list, Python 3.11 marks "mailcap" for removal in 3.13. The documentation speaks about "mimetypes" being a replacement, of sorts. I agree with removing dead batteries. However, I can't really see how "mimetypes" helps in replacing the functionality of "mailcap" ? Put another way: what is the suggested way of replacing that module in existing code ? The use case is "find the viewer for any kind of file (by mimetype), as long as the system knows". Thanks, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
Am Mon, Nov 14, 2022 at 02:13:34AM + schrieb MRAB: > But if it's an expression where it's expecting a statement and it's not a > call, then > it's probably a bug. That "probably" makes it suitable for a linter, as was pointed out. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: Are these good ideas?
Am Mon, Nov 14, 2022 at 05:14:05PM + schrieb Stephen Tucker: > Issue 2 - Passed Parameters > > I am now facing another situation where I am wanting to pass 6 or 7 > parameters down through several layers of logic (function A calling > function B calling ... ) and for results to be passed back. > > Having had the idea described above, I am considering using it again to > save all the parameter-and-results passing. > > I see nothing wrong with doing that, but I may well be missing something! Maybe pass and return a class ? Maybe even a data class ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
pylint scoping question
Dear readers, I have a pylint scoping (or how-to) question. pylint 2.7.2 astroid 2.5.1 Python 3.9.2 (default, Feb 28 2021, 17:03:44) Objective: to disable all pylint errors/warnings starting from a particular source line until EOF (that part contains to-be-run-manually scratch/test code for that file) As an MWE consider this code: #--- usr/bin/python3 """MWE""" print(does_not_exist_1) # Xpylint: disable=undefined-variable # Xpylint: disable=all print(does_not_exist_2) print(does_not_exist_3) #--- Pylint docs say that disables are per-scope. Thusly a # pylint: disable=undefined-variable inside the file-global scope should (?) disable undefined-variable for the entire (?) file-global scope. It does not, however, but rather seems to disable it inside the file-global scope *from the line of occurrence onwards*. To see this, remove the X from the relevant disable in the MWE. This is the behaviour I desire to achieve. However, when using the "disable=all" it *does* disable all output, including the x.py:4:6: E0602: Undefined variable 'does_not_exist_1' (undefined-variable) despite the # pylint: disable=all sitting *after* the print(does_not_exist_1) So: Am I doing something wrong ? Am I misinterpreting the docs ? Do the docs explain this difference in disable-scoping ? How should I properly go about my objective (apart from fixing my code, of course :-D ) ? Thanks for insights, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: pylint scoping question
Am Wed, Feb 08, 2023 at 12:20:48PM +0100 schrieb Karsten Hilbert: > I have a pylint scoping (or how-to) question. ... > Objective: > > to disable all pylint errors/warnings starting from a > particular source line until EOF (that part contains > to-be-run-manually scratch/test code for that file) This https://stackoverflow.com/questions/66914050/what-is-the-scope-of-pylint-comments BTW, is the seemingly closest related information I could find but it does not explain the difference in scoping between disable=something and disable=all. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
Am Sun, Feb 26, 2023 at 08:56:28AM -0800 schrieb Hen Hanna: > so far, i think Paul Rubin's post (in another thread) was > esp. concise, informative, --- but he's also made a comment > about 'shunting' beginners (questions) to a > concentration camp, and sounded a bit like a cold-hearted > (or warm-hearted) Nazi officer / scientist. Now, I have a lot of sympathy -- not least from a professional point of view -- and see quite some leeway for people acting neuro-atypically, but the last line of the above really isn't necessary to be read on this list. Best, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Python 3.10 Fizzbuzz
> > I've never tried Black or any other code formatter, but I'm sure we > > wouldn't get on. > > Does this suggest, that because Black doesn't respect other people's > opinions and feelings, that it wouldn't meet the PSF's Code of Conduct? That much depends on The Measure Of A Man. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Standard class for time *period*?
> No, it doesn't. I already know about timedelta. I must have explained > the issue badly, because everyone seems to be fixating on the > formatting, which is not a problem and is incidental to what I am really > interested in, namely: > > 1. Is there a standard class for a 'period', i.e. length of time >specified by a start point and an end point? The start and end >points could obviously be datetimes and the difference a timedelta, >but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be >different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the >*duration* of both periods is the same. Not that I know, within the constraints of the standard library. However: class CalendarPeriod: def __init__(self, start, end): self.start = start self.end = end ? For this to be *useful* more needs need to be explained. Until then - YAGNI. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Windows Gui Frontend
> The real time consuming stuff in building GUIs is getting > the basic design right and keeping all the controls, > keyboard bindings and menus in sync. State management > in other words. And cominmg up with sensible design choices _at all_. > I did a deep dive examination of GUI builders back around > v2.6 and came away less than enthused. Things may have > improved since then but I've seen no real evidence of > that. Is this available anywhere ? What GUI builders do (for me) is to make creating the GUI in a WYSIWYM way. Like LyX for LaTeX. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: open sentinel-2image python
Am Sun, Jan 17, 2021 at 02:20:24AM -0800 schrieb omid mohammadi: > When I open the sentinel-2 image in Python, I get the following error: > > MemoryError: Unable to allocate 115. MiB for an array with shape (5490, 5490) > and data type float32 > > How can I fix it? You can install more RAM. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: Python cannot count apparently
Am Sun, Feb 07, 2021 at 08:34:34PM +0100 schrieb Philipp Daher via Python-list: > I recently coded this snippet of code: > myString=„hello“ I doubt you have (coded *this* snippet of code) -- because those quotes wouldn't work. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: Python cannot count apparently
Am Sun, Feb 07, 2021 at 07:47:03PM + schrieb Paul Bryan: > That's not the only problem with the code. There's a missing close- > paren and a reference to "string" which I presume was meant to be > "myString". I know. I wasn't going to spoil everything right away. The sort of response we would get from OP would tell us what sort of help might be most suitable :-) Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
Am Mon, Mar 22, 2021 at 09:22:51AM + schrieb Robert Latest via Python-list: > >> I agree with everything you say. Especially the open source part. But > >> wouldn't you agree that .title() with all its arbitrary specificity to > >> appear in the very core of a general purpose language is quite an oddity? > > > > No, because it book ends the issue. > > > > Upper - Converts everything to uppercase Lower - Converts everything to > > lowercase > > > > Title - Covers the cases in-between upper/lower. > > My only issue is that I completely fail to see how this function would be > useful enough to warrant the inclusion into the *core* of a general-purpose > language, including its misleading name. The fact that the function's behavior > is correctly documented doesn't make its very existence less bewildering to > me. Its naming may be unfortunate, its existence may be bewildering. However, it's now there, and for historical reasons, supposedly. It won't be removed or renamed in all likelihood. The best one can do is to suggest a documentation patch (not fix) like so: The algorithm uses a simple language-independent [...] and context-naive, not locale related, [...] definition of a word [...] and life with that wart. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Aw: not able to download PyAudio
The same as with speech recognition. Research. Karsten > Gesendet: Freitag, 02. April 2021 um 10:40 Uhr > Von: "ᗷᑌᑎᑎY" > An: "Igor Korot" > Cc: "python-list@python.org" > Betreff: not able to download PyAudio > >Hello everyone >I am not able to download PyAudio. I tried by typing pip install in >PyAudio in cmd but it show's no compatible version availbale. What should >I do? . > > > >Y > > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: googletrans in python
Am Mon, Apr 12, 2021 at 12:48:23PM -0400 schrieb Quentin Bock: > Can someone explain the basics of googletrans in python? > I want to make a program that translates stories into English, but I'm not > sure how to get a translation printed. Also, is this needed to be done in > an HTML file inside python? > If so can someone provide basic code for a translation and how that should > be written and work? You might want to post the entire homework assignment verbatim. That way people might better understand which part of it to help you with in what way. As to your description of what you want to achieve -- what did you already try ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
Am Fri, Sep 24, 2021 at 08:59:23PM +0200 schrieb Peter J. Holzer: > JSON: Has a few primitive data types (bool, number, string) and a two > compound types (list, dict(string -> any)). Still missing many > frequently used data types (e.g. dates) But that (dates) at least has a well-known mapping to string, which makes it usable within JSON. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
Am Tue, Sep 28, 2021 at 12:53:49PM -0500 schrieb Michael F. Stemper:
> This sounds like a suggestion that I hard-code the data into a
> module. I suppose that I could have half-a-dozen modules with
> different data sets and ln them as required:
>
> $ rm GenData.py* FuelData.py*
> $ ln gendata1.py GenData.py
> $ ln fueldata3.py FuelData.py
vi data.py
generators = {}
generators['name1'] = {'fuel': ..., ...}
generators['name2'] = {...}
...
vi simulation.py
import sys
import data
generator = data.generators[sys.argv[1]]
run_simulation(generator)
or some such ?
Your data "format" is ... Python code.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: Definitive guide for Regex
Am Thu, Sep 30, 2021 at 12:29:16PM +0100 schrieb Shaozhong SHI: > I am trying to look for a definitive guide for Regex in Python. > Can anyone help? If you tell us what you tried in order to look we can perhaps guide you on how to take a better look. Spoonfeeding doesn't seem to be a well-liked activity, neither here nor on the PostgreSQL lists. Best, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > Many operations in computing are fully reversible. After you do > something, you can undo it. After you assign, you can unassign. And > after you ite, you can unite! I wonder whether Japanese programmers would agree. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > xyzzy = lambda x: 2 * x > > . Sometimes, this can even lead to "naming paralysis", where > one thinks excessively long about a good name. To avoid this > naming paralysis, one can start out with a mediocre name. In > the course of time, often a better name will come to one's mind. In that situation, is it preferable to choose a nonsensical name over a mediocre one ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico: > > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico: > > > > > Many operations in computing are fully reversible. After you do > > > something, you can undo it. After you assign, you can unassign. And > > > after you ite, you can unite! > > > > I wonder whether Japanese programmers would agree. > > Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate? ite is the -te form (in some uses like a gerundium) of aru (to go, to walk) so, to un-go, revert-the-having-gone-ness, I genuinely wonder ... On the other hand, Japanese is full of wondrous word-play at levels undreamt of by us ASCIInarians. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: The task is to invent names for things
Am Wed, Oct 27, 2021 at 12:41:56PM +0200 schrieb Karsten Hilbert: > Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram: > > > xyzzy = lambda x: 2 * x > > > > . Sometimes, this can even lead to "naming paralysis", where > > one thinks excessively long about a good name. To avoid this > > naming paralysis, one can start out with a mediocre name. In > > the course of time, often a better name will come to one's mind. > > In that situation, is it preferable to choose a nonsensical > name over a mediocre one ? That one was a genuine question, BTW, not a snark remark. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: The task is to invent names for things
> > I don't know. A mediocre name conveys at least some information, and > > that seems to be better than none. On the other hand it might be just > > enough to lead the reader astray which wouldn't happen with a > > non-sensical name. I was thinking that a nonsensical name might lead readers to go beyond the name when trying to understand code, and would prompt me to improve upon the name upon reading my own code (and having acquired, likely, a better understanding of the concept that's to be named). Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: The task is to invent names for things
> Karsten Hilbert writes:
> >ite is the -te form (in some uses like a gerundium) of aru
> >(to go, to walk)
>
> This form, "行って", is written with two "t", as "itte",
> in many transcriptions to convey the gemination (っ) of
> the "t". There is, however, "ite", "居て", the -te form of
> "居る" ("iru" - "to be"), which usually is transcribed "ite".
I stand corrected, thanks. Not the first time that ite/itte
slipped :-/
At any rate, it, eh, is rather malleable to word play.
Karsten
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to apply a self defined function in Pandas
Am Sun, Oct 31, 2021 at 07:52:18PM + schrieb Shaozhong SHI:
> Well, can you expand the the simplicity?
Not sure how expanding is going to help but here's one way to
do it:
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> list('simplicity')
['s', 'i', 'm', 'p', 'l', 'i', 'c', 'i', 't', 'y']
>>>
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
Am Thu, Dec 30, 2021 at 03:57:25PM -0800 schrieb hongy...@gmail.com: > > > Then what cases/scenarios can demonstrate the beauty of recursion? > > > > > Walking a tree. > > There are many type of trees. Do you mean all of them? Palm trees don't lend themselves to recursion all that much. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Best way to check if there is internet?
> Or the internet acquires a new protocol that's designed > for very-long-latency connections. That's being worked on already https://en.wikipedia.org/wiki/NASA_Deep_Space_Network Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Long running process - how to speed up?
> > I have a cvs file of 932956 row and have to have time.sleep in a Python > > script. It takes a long time to process. > > > > How can I speed up the processing? Can I do multi-processing? > > > Remove the time.sleep()? He's attesting to only having "time.sleep" in there... I doubt removing that will help much ;-) Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: PYT - How can I subscribe to a topic in the mailing list?
> Betreff: PYT - How can I subscribe to a topic in the mailing list? Mailing lists don't subdivide by topic. Your mailer may allow you to filter by Subject:. > And h*ow do I set the topic in my messages?* not applicable The equivalent would be the Subject: header. Karsten -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Best way to check if there is internet?
> Is there any value whatsoever in a lie? Do we _know_ it's a lie ? Does a lie become a Falsed Truth once it becomes known ? Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: Pre-Pre-PEP: The datetime.timedeltacal class
Am Sat, Apr 16, 2022 at 07:35:51PM +0200 schrieb Peter J. Holzer: > So I'll start by gathering some feedback > here with a rough sketch. > [TODO: Research how other systems handle overflow > (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't exist)], That is context dependant: Take this medication for 1 month ! is quite likely to mean "take it for 28 days". This standing order (Dauerauftrag) is to be run every months from now on. will mean "every 1st of the month, regardless of how many days passed". Karsten GNUmed -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyDDF Python Spring Sprint 2018
> * mxDateTime Portierung auf Python 3.6 +1 !! Karsten Hilbert -- -- https://mail.python.org/mailman/listinfo/python-list
Re: beacons and geofences
On Thu, Apr 12, 2018 at 12:33:39AM +0200, ElChino wrote: > Rafal Sikora wrote: > > > Hi! I want users’ devices to be able to monitor the maximum amount of POIs > > at > > once (geo-fences/beacons) and I need to prepare an algorithm solution for > > monitoring the POIs. How should it be implemented in Python? > > What? You'll have to describe the problem in more details > if you want any sensible answers. I just might so happen that the homework assignment did not contain much more in terms of description. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: why does list's .remove() does not return an object?
> On 5/17/18 11:57 AM, Abdur-Rahmaan Janhangeer wrote: > > x = [0,1] > > x.remove(0) > > new_list = x > > > > instead i want in one go > > > > x = [0,1] > > new_list = x.remove(0) # here a way for it to return the modified list by > > adding a .return() maybe ? > > There isn't a way to do that in one line. new_list = list(x.remove(0)) new_list = x.remove(0)[:] ? No one said x can't be modified, only that new_list is to contain the modified list after one line of code :) kh -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: why does list's .remove() does not return an object?
>new_list = list(x.remove(0)) >new_list = x.remove(0)[:] Please disregard :) kh -- https://mail.python.org/mailman/listinfo/python-list
Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to
On Sun, May 20, 2018 at 04:59:12AM -0700, bellcanada...@gmail.com wrote: > On Saturday, 19 May 2018 19:48:20 UTC-4, Skip Montanaro wrote: > > As Chris indicated, you'll have to figure out the correct encoding. You > > might want to check out the chardet module (available on PyPI, I believe) > > and see if it can come up with a better guess. I imagine there are other > > encoding guessers out there. That's just one I'm familiar with. > > thank you for the reply, but how exactly am i supposed to find oout what is > the correct encodeing?? One CAN NOT. The best you can do is to go ask the canonical source of the file what encoding the file is _supposed_ to be in. Then go from there and allow for errors. Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: '_' and '__'
On Sun, May 27, 2018 at 10:36:30AM +1000, Ben Finney wrote: > Nick also explains that, because the name ‘_’ has too many conventional > meanings already, the name ‘__’ is better for “don't need this value but > I am required to specify a name”. _() is often bound to gettext.gettext() in the global namespace, so we'd better avoid that or else ... [ _(_) for _ in '123' ] ... will fail :-) Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Re: The PIL show() method looks for the default viewer. How do I change this to a different viewer (of my choice)?
On Wed, May 30, 2018 at 11:01:17PM +0200, Peter J. Holzer wrote:
> On 2018-05-30 22:08:45 +0200, Paul St George wrote:
> > Ha! No, my question was clumsy.
> >
> > If I know the name of the viewer that I want to use (say for example:
> > ‘ImageMagick’), where do I find the argument that should be used in a line
> > of code such as this:
> >
> > ImageShow.register(MyViewer("gwenview"), -1)
$> man -k ImageMagick
$> man whatever_you_found_with_the_above
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
https://mail.python.org/mailman/listinfo/python-list
Re: your mail
On Sun, Jun 10, 2018 at 06:58:17PM +0530, sagar daya wrote: > Couldn't install any module from pip > Plz help??? https://duckduckgo.com kh -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Question : Input after all prompts in python
On Mon, Jun 11, 2018 at 01:44:19AM -0700, moha...@gmail.com wrote: > I am very new to python. I am trying to achieve the below in it, but i am > unable to find suitable documentation to guide me on the same. > > I want to prompt 3 questions together and then get input for the first > question next to question as below. > > 1. Enter your name : _ > 2. Enter your age : > 3. Enter your gender : > > After showing the below prompts, the cursor waits in first question for an > input. > > How to achieve this in python. Please help on the same. The builtin way is with the tkinter module: https://docs.python.org/3/library/tkinter.html There's also a builtin way to get input from the user without resorting to a UI toolkit https://docs.python.org/3/library/functions.html#input but it will not allow you to (easily) prompt 3 questions *together* and *then* get input for the *first* question *next* to question (emphasis mine) Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Question : Input after all prompts in python
On Mon, Jun 11, 2018 at 11:16:39AM +, Steven D'Aprano wrote:
> > I want to prompt 3 questions together and then get input for the first
> > question next to question as below.
> >
> > 1. Enter your name : _
> > 2. Enter your age :
> > 3. Enter your gender :
> >
> > After showing the below prompts, the cursor waits in first question for
> > an input.
>
> How else do you expect to tell the three inputs apart?
>
> But okay.
>
>
> print("1. Enter your name :")
> print("2. Enter your age :")
> print("3. Enter your gender :")
> name = input("")
> age = input("")
> gender = input("")
That doesn't solve the "next to" part in
get input for the first question next to question
:)
Karsten
--
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question : Input after all prompts in python
On Mon, Jun 11, 2018 at 02:14:26PM +0200, Peter Otten wrote:
> >> print("1. Enter your name :")
> >> print("2. Enter your age :")
> >> print("3. Enter your gender :")
> >> name = input("")
> >> age = input("")
> >> gender = input("")
> >
> > That doesn't solve the "next to" part in
> >
> > get input for the first question next to question
>
> Easy:
>
> def up(n):
> print("\u001b[{}A".format(n), flush=True, end="")
>
> def right(n):
> print("\u001b[{}C".format(n), flush=True, end="")
>
> print("1. Enter your name:")
> print("2. Enter your age:")
> print("3. Enter your gender:")
> up(3)
> right(22)
> name = input("")
> right(22)
> age = input("")
> right(22)
> gender = input("")
>
> If it doesn't work you are using the wrong terminal ;)
Sure, but notice how I said "(easily)" in the original answer ?
The above is NOT easy for an OP who has to ask the original question.
Karsten
--
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question : Input after all prompts in python
On Mon, Jun 11, 2018 at 02:52:53PM +0200, Peter Otten wrote: > If the above hack works in the OP's environment it's certainly as easy as it > can get; he just has to copy the up() and right() functions, and maybe adapt > the arguments. > > The learning curve for tkinter or curses is steep by comparison. Agreed. Note that I had a lurking suspicion this whole thing amounts to a homework assignment (which I didn't say, however) ... ;-) Karsten -- -- https://mail.python.org/mailman/listinfo/python-list
Re: error in os.chdir
On Sat, Jun 30, 2018 at 04:05:22AM -0700, Sharan Basappa wrote:
> I need to change directory to my local working directory in windows and then
> open a file for processing.
> Its just a 3 lines code, as below:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
> The error is as follows:
> WindowsError: [Error 123] The filename, directory name, or volume label
> syntax is incorrect: 'D:\Projects\Initiatives\machine
> learning\programs\x07ssertion'
> Notice x07 character that has replaced character x07.
> I have a similar code but that goes through fine:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs')
>
> with open('example.csv') as csvfile:
> readCSV = csv.reader(csvfile, delimiter=',')
> The only difference is directory assertion in the problematic code.
> I have tried single quoting, double quoting etc. for the chdir directive but
> nothing helps. I have also tried escaping as \assertion but that is not the
> issue
The quick fix:
put an r in front of the directory string: r'...'
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: error in os.chdir
On Sat, Jun 30, 2018 at 05:46:59AM -0700, Sharan Basappa wrote: > > >> The quick fix: > > >> > > >> put an r in front of the directory string: r'...' > > > > Please don't do that. It's the wrong solution -- all you are doing is > > postponing failure. It will *seem* to work, until one day you will write > > something like this: > > > > directory = r'D:\directory\' > > > > and you will get a mysterious failure. Chris gave you the right solution: > > use forward slashes instead of backslashes for all paths. > > alright. I will do that but still I don't have an answer why I got the error > in the first place. For that you'll have to read up on strings and escaping. https://docs.python.org/2/tutorial/introduction.html#strings Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: error in os.chdir
On Sat, Jun 30, 2018 at 07:34:46AM -0700, Sharan Basappa wrote:
> sorry. I mean why my code worked in one case but did not in the other one.
>
> This worked - os.chdir('D:\Projects\Initiatives\machine learning\programs')
>
> This did not work - os.chdir('D:\Projects\Initiatives\machine
> learning\programs\assertion')
>
> only difference is, I added an additional directory in the problematic case.
The answer lies in the (inadvertant) use of escaping.
Which is the very reason _why_ forward slashes were favoured
over backward ones.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logger option
On Sat, Jun 30, 2018 at 10:02:13AM -0700, Sharan Basappa wrote: > I have tried both logging and trace in Canopy and both are not working. You will have to be more specific. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: File names with slashes [was Re: error in os.chdir]
Eryk, thanks for your to-the-point in-depth posts. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
