Re: Objects with __name__ attribute
ast wrote: > Hi, > > I know two Python's objects which have an intrinsic > name, classes and functions. > > def f(): > pass > f.__name__ > 'f' g = f g.__name__ > 'f' > > class Test: > pass > Test.__name__ > 'Test' Test2 = Test Test2.__name__ > 'Test' > > Are there others objects with a __name__ attribute > and what is it used for ? > > Regards It was used for the object's repr(): $ python Python 2.7.6 (default, Oct 26 2016, 20:30:19) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def f(): pass ... >>> f.__name__ = "spanish inquisition" >>> f But this has changed: $ python3 Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def f(): pass ... >>> f.__name__ = "spanish inquisition" >>> f >>> f.__qualname__ = "spanish inquisition" >>> f You should be aware that the module name is used to detect the main module: if __name__ == "__main__": print("this is run as a script") -- https://mail.python.org/mailman/listinfo/python-list
Re: h5py.File() gives error message
Oh, I was running a debug file, that's why the path is different. The file is here, https://www.dropbox.com/s/6jx4rzyg9xwl95m/train_catvnoncat.h5?dl=0 Is anyone able to get it working? Thank you! On Tue, Oct 24, 2017 at 10:37 PM, Dennis Lee Bieber wrote: > On Tue, 24 Oct 2017 18:02:26 -0700, Rob Gaddi > declaimed the following: > > Whoops, I may have gotten the wrong level of quoting -- my > apologies if > so (I did have agent fetch the original posting, but might not have had > that active when I hit "reply") > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
Steve D'Aprano wrote: - Encrypted data looks very much like random noise. There's actually a practical use for that idea. If you can feed the output of an encryption algorithm through a compressor and make it smaller, it means there is a cryptographic weakness in the algorithm that could potentially be exploited. Good encryption algorithms produce output that looks almost completely random to anyone who doesn't know how to decrypt it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
Ben Bacarisse wrote: The trouble is a pedagogic one. Saying "you can't compress random data" inevitably leads (though, again, this is just my experience) to endless attempts to define random data. It's more about using terms without making sure everyone agrees on the definitions being used. In this context, "random data" really means "uniformly distributed data", i.e. any bit sequence is equally likely to be presented as input. *That's* what information theory says can't be compressed. I think "arbitrary data" (thereby including the results of compression by said algorithm) is the best way to make progress. I'm not sure that's much better, because it doesn't home in on the most important thing, which is the probability distribution. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
Lele Gaifax wrote: That's simple enough: of course one empty file would be "music.mp3.zip.zip.zip", while the other would be "movie.avi.zip.zip.zip.zip.zip"... some sort of https://en.wikipedia.org/wiki/Water_memory applied to file system entries :-) If you're allowed to alternate between two compression methods, then the way you decompress music.mp3.zip.zip.tgz.zip...tgz.zip.tgz is to output 0 each time zip was applied and 1 each time tar/gz was applied. You may be able to take some shortcuts in some cases, e.g. anything beginning with "movie.flv" almost certainly contains a cute kitten video. (Unless it's found inside an encrypted disk partition, in which case it contains porn.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Sockets but calling from different programs
On 23Oct2017 05:33, T Obulesu wrote: I'm new to python3 and scratching my head to write a program for this logic: The tutor list might be a better place for such questions, but since we're here... classA.py Class A: # class for socket communication basic init method that initializes port, address, connection method send(message): # for sending any message through the given port method receive(): # will be keep on listening for incoming messages classB.py Class B: import the send method from class A send the messages from this class classC.py Class C: import the receive method from the class A receive all the messages from the same socket from here. Note: classA.py, classB.py, ClassC.py are saved in different locations. Can someone help me in writing the code and how can I create a single object and use it in multiple classed? That is a pretty normal arrangement. Class A might look like this: class A: def __init__(self, port, address): self.connection = ... make your connection to (address, port) def send(self, msg): send msg using self.connection ... Since classes B and C seem expected to share tha same connection, the natural thing is to set up the connection _separately_ from setting up B and C, and pass the established connection to each. So class B might commence: class B: def __init__(self, conn, ...): self.conn = conn ... whatever other initialisation ... def speak(self, something): self.conn.send(something) You'll notice here that we're _not_ importing anything about class A here. Class B does not need to know class A's name to use it. Because Python uses duck typing, you could pass _any_ object which has a .send() method as "conn" to the class B setup. This allows you to write some other class A2 with those same methods, but using some different type of connection, and pass that in to classes B and C. So a main programme might set things up like this: from classA import A from classB import B from classC import C conn = A(address, port) sender = B(conn, other-stuff...) receiver = C(conn, other-stuff...) B.speak("foo") and so forth. Cheers, Cameron Simpson (formerly c...@zip.com.au) -- https://mail.python.org/mailman/listinfo/python-list
Re: h5py.File() gives error message
C W wrote: > Oh, I was running a debug file, that's why the path is different. > > The file is here, > https://www.dropbox.com/s/6jx4rzyg9xwl95m/train_catvnoncat.h5?dl=0 > > Is anyone able to get it working? Thank you! Hm, that file seems to contain HTML and that causes an OSError here, too: $ head -n3 datasets/train_catvnoncat.h5 $ python3 Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import h5py >>> train_dataset = h5py.File('datasets/train_catvnoncat.h5', "r") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/h5py/_hl/files.py", line 207, in __init__ fid = make_fid(name, mode, userblock_size, fapl) File "/usr/lib/python3/dist-packages/h5py/_hl/files.py", line 79, in make_fid fid = h5f.open(name, h5f.ACC_RDONLY, fapl=fapl) File "h5f.pyx", line 71, in h5py.h5f.open (h5py/h5f.c:1806) OSError: unable to open file (File accessibilty: Unable to open file) It's not exactly what you see, but that may be due to differing software versions. When I replace the HTML file with its namesake found at https://github.com/lalxyy/NEU-MCM-Training-4/blob/master/code/datasets/train_catvnoncat.h5 I can open it: $ file datasets/train_catvnoncat.h5 datasets/train_catvnoncat.h5: Hierarchical Data Format (version 5) data $ python3 Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import h5py >>> train_dataset = h5py.File('datasets/train_catvnoncat.h5', "r") >>> -- 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
Let's talk about debuggers!
Hi, I just wanted to know what tools everyone used for debugging Python applications - scripts / backend / desktop apps / notebooks / whatever. Apart from the usual dance with log files and strategically inserted print() calls, that is. Of course we all know and mildly dislike pdb. Personally, in practice, I'm most likely to need a debugger when prototyping a function in a Jupyter notebook. There, ipdb, summoned with the %%debug magic incantation, does the trick. Sometimes, though, I miss having a visual debugger. You know, the kind that Visual Basic has had for decades. There's one in Chrome dev tools if you ever have the misfortune of writing JavaScript. What options are there for Python (that work)? What text editors (and IDEs) have a decent integrated debugger or debugging plugin? (Is there anything for Sublime?) Does anyone use them? (How do YOU debug?) I vaguely remember WinPDB, but that hasn't seen a release in more than seven years... -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
On 10/24/17, Richard Damon wrote: > My understanding of the 'Random Data Comprehensibility' challenge is > that is requires that the compression take ANY/ALL strings of up to N > bits, and generate an output stream no longer than the input stream, and > sometime less. That's incorrect, at least of the challenge being discussed. Here's the link: http://marknelson.us/2012/10/09/the-random-compression-challenge-turns-ten/ The challenge is just to take a single known file of a million random digits and make it smaller, including the size of the decompresser and without hiding data. So far in 15 years nobody has succeeded even at this, and nobody knows whether it's impossible. For instance it may be the case that the data in the file happens to be the nth prime, in which case it could simply be compressed to the number n with a decompresser that calculates process. > It admits that given no-uniformly distributed data, it is > possible to compress some patterns, the common ones, and expand others, > the uncommon ones, to lower the net average length. What it says can't > be done is to have a compression method that compresses EVERY input > pattern. That is where the 'Pigeon Hole' principle comes into play which > the people who claim to be able to compress random data like to ignore > or just attempt to say doesn't apply. There is a second challenge on that page that is as you state, but the page admits that this second challenge is a bit of a troll since this is provably impossible. -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On 10/25/2017 03:07 PM, Thomas Jollans wrote: What options are there for Python (that work)? PyCharm's debugger is fine (also available in the community edition) Cheers, Fabien -- https://mail.python.org/mailman/listinfo/python-list
Re: h5py.File() gives error message
wow, thanks so much! I don't know how you figured that it's HTML, but that's awesome! Mike On Wed, Oct 25, 2017 at 5:20 AM, Peter Otten <__pete...@web.de> wrote: > C W wrote: > > > Oh, I was running a debug file, that's why the path is different. > > > > The file is here, > > https://www.dropbox.com/s/6jx4rzyg9xwl95m/train_catvnoncat.h5?dl=0 > > > > Is anyone able to get it working? Thank you! > > Hm, that file seems to contain HTML and that causes an OSError here, too: > > $ head -n3 datasets/train_catvnoncat.h5 > > > > > $ python3 > Python 3.4.3 (default, Nov 17 2016, 01:08:31) > [GCC 4.8.4] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import h5py > >>> train_dataset = h5py.File('datasets/train_catvnoncat.h5', "r") > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/h5py/_hl/files.py", line 207, in > __init__ > fid = make_fid(name, mode, userblock_size, fapl) > File "/usr/lib/python3/dist-packages/h5py/_hl/files.py", line 79, in > make_fid > fid = h5f.open(name, h5f.ACC_RDONLY, fapl=fapl) > File "h5f.pyx", line 71, in h5py.h5f.open (h5py/h5f.c:1806) > OSError: unable to open file (File accessibilty: Unable to open file) > > It's not exactly what you see, but that may be due to differing software > versions. > When I replace the HTML file with its namesake found at > > https://github.com/lalxyy/NEU-MCM-Training-4/blob/master/cod > e/datasets/train_catvnoncat.h5 > > I can open it: > > $ file datasets/train_catvnoncat.h5 > datasets/train_catvnoncat.h5: Hierarchical Data Format (version 5) data > > $ python3 > Python 3.4.3 (default, Nov 17 2016, 01:08:31) > [GCC 4.8.4] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import h5py > >>> train_dataset = h5py.File('datasets/train_catvnoncat.h5', "r") > >>> > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On Wednesday, October 25, 2017 at 6:37:47 PM UTC+5:30, Thomas Jollans wrote: > Hi, > > I just wanted to know what tools everyone used for debugging Python > applications - scripts / backend / desktop apps / notebooks / whatever. > Apart from the usual dance with log files and strategically inserted > print() calls, that is. > > Of course we all know and mildly dislike pdb. > > Personally, in practice, I'm most likely to need a debugger when > prototyping a function in a Jupyter notebook. There, ipdb, summoned with > the %%debug magic incantation, does the trick. > > Sometimes, though, I miss having a visual debugger. You know, the kind > that Visual Basic has had for decades. There's one in Chrome dev tools > if you ever have the misfortune of writing JavaScript. > > What options are there for Python (that work)? What text editors (and > IDEs) have a decent integrated debugger or debugging plugin? (Is there > anything for Sublime?) Does anyone use them? (How do YOU debug?) > > I vaguely remember WinPDB, but that hasn't seen a release in more than > seven years... pdb inside emacs works (to a fashion) And it shows the arrow for current line so its at least quasi-gui I believe idle too is much more usable than a few years earlier -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On 10/25/17 9:07 AM, Thomas Jollans wrote: Hi, I just wanted to know what tools everyone used for debugging Python applications - scripts / backend / desktop apps / notebooks / whatever. Apart from the usual dance with log files and strategically inserted print() calls, that is. Of course we all know and mildly dislike pdb. Personally, in practice, I'm most likely to need a debugger when prototyping a function in a Jupyter notebook. There, ipdb, summoned with the %%debug magic incantation, does the trick. Sometimes, though, I miss having a visual debugger. You know, the kind that Visual Basic has had for decades. There's one in Chrome dev tools if you ever have the misfortune of writing JavaScript. What options are there for Python (that work)? What text editors (and IDEs) have a decent integrated debugger or debugging plugin? (Is there anything for Sublime?) Does anyone use them? (How do YOU debug?) I vaguely remember WinPDB, but that hasn't seen a release in more than seven years... pudb is a visual terminal debugger: https://pypi.python.org/pypi/pudb It uses the same commands as pdb, so it's easy to get started, but it gives you a variables pane, with customizable presentation, and so on. One of my favorite features: you can add a set_trace line in your program, and then if during the debugging session you realize you don't want to stop there every time, you can disable that breakpoint even though it's an explicit line of code telling the debugger to stop. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
pdb plus plus: https://pypi.python.org/pypi/pdbpp -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
Fabien wrote: On 10/25/2017 03:07 PM, Thomas Jollans wrote: What options are there for Python (that work)? PyCharm's debugger is fine (also available in the community edition) +1 Cheers, Fabien -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
Whatever you do, you'll find that *on average* you will need *at least* 34 bits to be able to represent all possible 10-digit decimal numbers. Some might be shorter, but then others will be longer, and the average won't be less than 34. The theoretical limit for arbitrary numbers 0 - 9 must be viewed as an average not as an impossibility to, in some cases be able to compress to or under 34. This is obvious by the decimal to binary function. -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
> On Oct 25, 2017, at 9:07 AM, Thomas Jollans wrote: > > [byte] > What options are there for Python (that work)? What text editors (and > IDEs) have a decent integrated debugger or debugging plugin? I rather like WingIDE (the name is a coincidence). It allows insertion/removal of break points while the code is running. While execution is stopped, it allows direct inspection of the stack (no surprise), but in addition allows execution of python statements or program elements typed into an auxiliary window - including importing things like matplotlib and plotting the current state of data arrays. Its editor is syntax-aware and highlights accidental syntax errors as they are typed. Lots of other features, those just happen to be the ones I use most often. Bill -- https://mail.python.org/mailman/listinfo/python-list
Test Bank for Campbell Biology 11th Edition by Urry, Cain
Where it didnt come -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On 2017-10-25 15:57, Rustom Mody wrote: > > pdb inside emacs works (to a fashion) > And it shows the arrow for current line so its at least quasi-gui > > I believe idle too is much more usable than a few years earlier I haven't used IDLE in years (if ever), partly because Tkinter is so incredibly ugly, and feels so out-of-place on a modern PC (maybe it's tolerable on Windows, I wouldn't know). In any case I just tried it out and good lord that's terrible. You can set breakpoints in the editor (good), it shows locals (excellent), but it doesn't show you what line you're at when stepping through (seriously?). I'll go back to not even touching IDLE with a ten-foot pole now. -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On Wednesday, October 25, 2017 at 9:07:47 AM UTC-4, Thomas Jollans wrote: > Hi, > > I just wanted to know what tools everyone used for debugging Python > applications - scripts / backend / desktop apps / notebooks / whatever. > Apart from the usual dance with log files and strategically inserted > print() calls, that is. > > Thomas Jollans One more vote for pudb. Somehow it fits my brain better than most. -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
Il 25/10/2017 15:07, Thomas Jollans ha scritto: Hi, I just wanted to know what tools everyone used for debugging Python applications - scripts / backend / desktop apps / notebooks / whatever. Apart from the usual dance with log files and strategically inserted print() calls, that is. Of course we all know and mildly dislike pdb. Personally, in practice, I'm most likely to need a debugger when prototyping a function in a Jupyter notebook. There, ipdb, summoned with the %%debug magic incantation, does the trick. Sometimes, though, I miss having a visual debugger. You know, the kind that Visual Basic has had for decades. There's one in Chrome dev tools if you ever have the misfortune of writing JavaScript. What options are there for Python (that work)? What text editors (and IDEs) have a decent integrated debugger or debugging plugin? (Is there anything for Sublime?) Does anyone use them? (How do YOU debug?) I vaguely remember WinPDB, but that hasn't seen a release in more than seven years... I use the PyDev extension to Eclipse IDE, with the standard one at work (directly as a plugin to Eclipse) and with LiCplise (a bundle with eclipse, pydev and some other plugins) at home. You can put breakpoint in the code, see all the variables and so forth. Daniele Forghieri -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On 10/25/2017 12:12 PM, Thomas Jollans wrote: On 2017-10-25 15:57, Rustom Mody wrote: pdb inside emacs works (to a fashion) And it shows the arrow for current line so its at least quasi-gui I believe idle too is much more usable than a few years earlier I haven't used IDLE in years (if ever), partly because Tkinter is so incredibly ugly, and feels so out-of-place on a modern PC (maybe it's tolerable on Windows, I wouldn't know). On Windows, it uses native widgets when possible, so the look and feel of IDLE's editor is the same as some other apps, such as Notepad++. We are in the process of switching to the ttk widget set, which improve the look on Linux and even more so on Macs. The settings dialog was redone, in part, for 3.6.3 and 3.7. Which version are you using? In any case I just tried it out and good lord that's terrible. The debugger UI has not gotten its badly needed makeover yet; there is a issue and patch to do so. You can set breakpoints in the editor (good), it shows locals (excellent), but it doesn't show you what line you're at when stepping through (seriously?). Seriously, you either did not look, or you have a broken IDLE installation, or you ran into a severe bug I would like to know about. Rather than never, the next line is shown 2 or 3 times. 1.The module, line number, and code of the next line is shown immediately below the header of buttons and checkboxes. 2. The box below shows the complete stack of Python lines in the process of being run, including (again) the one that will be executed next. For each, it shows the module, line number, and text of the line. Bug: code and line number are reversed on the last line, which is the repeat of the next line. Enhancement: make list more readable with module, number, and code in neat columns. The window will have to be much wider, or each line split as in tracebacks, to do this. 3. If one checks the '[X] source' box at the top, the 'next' line is highlighted in an IDLE editor window. This is currently not checked by default because the debugger would currently open *every* file stepped into. When opening new windows is made optional, source will be checked by default. In summary, I think debugger should rate at least 'good' rather than 'fail' when it comes to showing you the next line. I'll go back to not even touching IDLE with a ten-foot pole now. Do as you want, but please report accurately. There are bugs around the debugger, but not, that I know of, the one you claim. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
W dniu 25.10.2017 o 15:53, Ned Batchelder pisze: > On 10/25/17 9:07 AM, Thomas Jollans wrote: >> Hi, >> >> I just wanted to know what tools everyone used for debugging Python >> applications - scripts / backend / desktop apps / notebooks / whatever. >> Apart from the usual dance with log files and strategically inserted >> print() calls, that is. >> >> Of course we all know and mildly dislike pdb. >> >> Personally, in practice, I'm most likely to need a debugger when >> prototyping a function in a Jupyter notebook. There, ipdb, summoned with >> the %%debug magic incantation, does the trick. >> >> Sometimes, though, I miss having a visual debugger. You know, the kind >> that Visual Basic has had for decades. There's one in Chrome dev tools >> if you ever have the misfortune of writing JavaScript. >> >> What options are there for Python (that work)? What text editors (and >> IDEs) have a decent integrated debugger or debugging plugin? (Is there >> anything for Sublime?) Does anyone use them? (How do YOU debug?) >> >> I vaguely remember WinPDB, but that hasn't seen a release in more than >> seven years... >> >> > > pudb is a visual terminal debugger: https://pypi.python.org/pypi/pudb > > It uses the same commands as pdb, so it's easy to get started, but it > gives you a variables pane, with customizable presentation, and so on. > > One of my favorite features: you can add a set_trace line in your > program, and then if during the debugging session you realize you don't > want to stop there every time, you can disable that breakpoint even > though it's an explicit line of code telling the debugger to stop. +1 It's excellent piece of software. I started using it when debugging remote/server things, and ended with using eveywhere. It has two drawbacks: it doesn't remember your commandline, watches and sizes of panes, and has ugly default colour scheme. Few years ago, I used Eclipse+PyDev, but I was tired with recurring strange problems with Eclipse, which eg hanged until I reinstalled eclipse or removed workspace metadata. r. m. -- https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On 25/10/17 22:18, Terry Reedy wrote: > On 10/25/2017 12:12 PM, Thomas Jollans wrote: >> On 2017-10-25 15:57, Rustom Mody wrote: >>> >>> pdb inside emacs works (to a fashion) >>> And it shows the arrow for current line so its at least quasi-gui >>> >>> I believe idle too is much more usable than a few years earlier >> >> I haven't used IDLE in years (if ever), partly because Tkinter is so >> incredibly ugly, and feels so out-of-place on a modern PC (maybe it's >> tolerable on Windows, I wouldn't know). > > On Windows, it uses native widgets when possible, so the look and feel > of IDLE's editor is the same as some other apps, such as Notepad++. We > are in the process of switching to the ttk widget set, which improve the > look on Linux and even more so on Macs. The settings dialog was redone, > in part, for 3.6.3 and 3.7. Which version are you using? This was 3.6.0. The look is "meh", but the file selection dialog is (for me) the real usability disaster. > >> In any case I just tried it out and good lord that's terrible. > > The debugger UI has not gotten its badly needed makeover yet; there is a > issue and patch to do so. Glad to hear it! > >> You can >> set breakpoints in the editor (good), it shows locals (excellent), but >> it doesn't show you what line you're at when stepping through >> (seriously?). > > Seriously, you either did not look, or you have a broken IDLE > installation, or you ran into a severe bug I would like to know about. > Rather than never, the next line is shown 2 or 3 times. Sorry Terry, of course you're right. What I meant to write was that it doesn't *point* to the current line (in the editor) - as apparently emacs does. I did notice it quoting the current line in the debugger window. > > 1.The module, line number, and code of the next line is shown > immediately below the header of buttons and checkboxes. > > 2. The box below shows the complete stack of Python lines in the process > of being run, including (again) the one that will be executed next. For > each, it shows the module, line number, and text of the line. > > Bug: code and line number are reversed on the last line, which is the > repeat of the next line. Enhancement: make list more readable with > module, number, and code in neat columns. The window will have to be > much wider, or each line split as in tracebacks, to do this. This sounds like it'll make a nice improvement. > > 3. If one checks the '[X] source' box at the top, the 'next' line is > highlighted in an IDLE editor window. This is currently not checked by > default because the debugger would currently open *every* file stepped > into. When opening new windows is made optional, source will be checked > by default. Aha! > > In summary, I think debugger should rate at least 'good' rather than > 'fail' when it comes to showing you the next line. > >> I'll go back to not even touching IDLE with a ten-foot pole now. > > Do as you want, but please report accurately. There are bugs around the > debugger, but not, that I know of, the one you claim. Guilty as charged. Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
So if the theoretical min compression limit (log2(n)*(x)) has a 3% margin but your transform has a less than 3% inflate rate at most then there is room for the transform to compress below the theoretical min. With every transform the entropy changes, the potential for greater compression also changes, with each pass you can compress untill the entropy is so random it can no longer be comressed. -- https://mail.python.org/mailman/listinfo/python-list
Determine the container class of an object in Python 3
Class1 is instantiated in Class2 as follows. Class2 also contains another variable, say: class Class2: class1 = Class1() a = 0 I want to create a method myDef() in Class1 that can read or write to a. How do I access a from within myDef() to access a? Calling Class2.a is not an option as Class1 does not have any knowledge about its container class a priori. Also, this will hardcode the path. I want to know of a built-in method (kind of equivalent of super() for inheritance) that will give me the container class reference, Class2 in this case. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine the container class of an object in Python 3
On Thu, Oct 26, 2017 at 12:25 PM, qrious wrote: > > Class1 is instantiated in Class2 as follows. Class2 also contains another > variable, say: > > class Class2: > class1 = Class1() > a = 0 > > I want to create a method myDef() in Class1 that can read or write to a. How > do I access a from within myDef() to access a? > > Calling Class2.a is not an option as Class1 does not have any knowledge about > its container class a priori. Also, this will hardcode the path. I want to > know of a built-in method (kind of equivalent of super() for inheritance) > that will give me the container class reference, Class2 in this case. > > Thanks. There isn't any. Relationships like this are one-way; you can go from Class2 to its attribute named "class1", which is an instance of Class1, but you can't go back the other way. There could be multiple ways to get to that same object, so there's no way for it to know which one you want. Now, there MAY be some strange and arcane magic that you can do as you construct that object to figure out what class it's in. But generally, you should avoid that kind of thing. There is (almost certainly) a better way to accomplish whatever it is you're aiming for. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression of random binary data
On Thu, 26 Oct 2017 08:22 am, danceswithnumb...@gmail.com wrote: > with each pass you can compress untill the entropy is so random it can no > longer be comressed. Which is another way of saying that you cannot compress random binary data. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine the container class of an object in Python 3
On Thu, 26 Oct 2017 12:25 pm, qrious wrote: > Class1 is instantiated in Class2 as follows. Class2 also contains another > variable, say: > > class Class2: > class1 = Class1() > a = 0 > > I want to create a method myDef() in Class1 that can read or write to a. How > do I access a from within myDef() to access a? The only way is to hard-code the name "Class2" in myDef. But the usual way to fix this problem is: class Class1: def __init__(self, owner): self.owner = owner def myDef(self): return self.owner.a def Class2: def __init__(self): self.class1 = Class1(self) self.a = 0 Technically, it is a circular reference, but don't worry about it, Python's garbage collector can resolve such circular references. If it becomes a problem -- and it shouldn't, but if it does -- you can use a weakref. But seriously, don't worry about it unless you need to. Another solution is to make Class1 a mixin, and then rely on inheritence: class MyMixin: def myDef(self): return self.a class Class2(MyMixin): def __init__(self): self.a = 0 -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE doesn't recognise installed packages
ok, I did that. I noticed that this path: 'C:\\Users\\Daniel86\\AppData\\Local\\Programs\\Python\\Python36\\Lib\\idlelib' is missing when I run the python.exe without IDLE. how do I fix this? also I get a syntax error when I try that: "To make sure you are running pip with the same binary as IDLE, enter path-to-binary -m pip C:\Programs\Python37\python.exe -m pip list" I need to have this explained with baby steps, I'm sure I'm just doing something wrong there. thank you for the help! I really appreciate it! > Terry Reedy hat am 24. Oktober 2017 um 08:36 geschrieben: > > > On 10/23/2017 10:23 AM, Daniel Tangemann wrote: > > I've recently downloaded and installed python 3.6. (I had already also 2.7 > > and 3.2 on my computer) Initially pip was looking in the wrong directory to > > install to, so I changed that. then it had trouble installing matplotlib, > > so I decided to get rid of the older versions of python, which srewed > > things up even more. now scrips that I had written (in 3.6), that were > > running without errors before, aren't working anymore. I tried reinstalling > > python, and I tried the repair option multiple times as well. when I look > > into the python folder, I can see the modules that I have installed (and > > that I import into those scripts), but the IDLE doesn't see them! what's > > even more weird, is that "pip list" doesn't bring up anything but pip > > itself, while typing "pip install matplotlib" returns a message that > > it's already installed. how do I fix this? > > cheers > > Recognition of installed packages is done by the python running IDLE and > executing your import statements, by not IDLE. The only effect IDLE > could have is any manipulation of sys.path. > > You can find the executable running IDLE with > > >>> import sys; sys.executable > 'C:\\Programs\\Python37\\pythonw.exe' > > Find the sys.path being used with > >>> sys.path > > If you run the same binary (minus the 'w' if present), you can find the > sys.path used without IDLE. You can also test imports without IDLE in use. > > It is possible that you have more than one binary around, but I cannot > tell from here. To make sure you are running pip with the same binary > as IDLE, enter path-to-binary -m pip instance, on windows, given the above > > path> C:\Programs\Python37\python.exe -m pip list > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list