[issue18160] Packaging more coherent Python
New submission from Tambet Väli: Hello! First the issue: my usual way of installing programming environments, languages and platforms is to install all the available modules from standard repositories, or if there is some all-good or batteries-included metapackage, I sure install this. I surely favor installing Python packages through standard Linux repositories. In last year or so, the number of available libraries has grown 'exponentially' for Python in the Linux Mint (Debian) repositories. Some of them are not trivial to install - by simply installing python-prefixed packages, I got my Ubuntu broken, because Window Manager of this version of Linux won't display window borders, menus or anything to navigate around if it does not have OpenGL working - it just displays window content and one can do almost anything with it. I did not trust this installation anymore and I did install a new Linux, Debian Mint. To avoid this kind of problems, there should be python-prefixed metapackages, which contain library collections for different kinds of tasks (for example, web programming should interface me with all apache, mysql, postgres, etc., whereas game programming should give nice collection for sound and video). These collections should be safe and work well together, where possible, or be usable - because for good programming language, predefined set of good libraries is critical. So that I could choose all those metapackages, know that I can play around and still my system is safe. -- components: Installation messages: 190768 nosy: Tambet.Väli priority: normal severity: normal status: open title: Packaging more coherent Python type: enhancement versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Slice implementation bug
Hello! Let's say slice is multidimensional now - how to interpret it? I excpect these to work: - m[0, 3] - get one element from matrix - m[0:2, 0:2] - get four elements from matrix, iterate over them (I have actually an rtree if it doesn't make sense to you) But it won't, because if m[0, 3] returns something, then m[0:2, 0:2] cannot yield anymore. Ofcourse I could return an iterator, but this would not be so simple. So, maybe we need these: - __isslice__(key) - return true, false - __getitem__(key) - return a value - __getslice__(key) - yield a lots of values So that if isslice returns true, getslice will be called. Would be much more beauty! Right now it's ugly. I love Python, but I also love n-dimensional spaces and those are ugly in Python - last time I did Matrix multiplication I could not implement m[0, 3] (stupid errors), could not m[0j + 3], could not use tuple. Now I was happy that it's implemented and just ran into another problem that I have to choose, if getter returns one or many :) Ofcourse I could return list or other iterable, but I want to be able to do it with three-liner, because the rest of my code mostly consists of those. Except the few masterfunctions, which do some complex manipulations with data. I also need to implement things like that, which also return true for __isslice__: m[Circle(0, 0, 10)] - for RTree, any shape object implementing getExtent and doesOverlap can be used as slice index. Because I do complex map transformations and all this trivial stuff must be *hidden*! Tambet -- http://mail.python.org/mailman/listinfo/python-list
Error message repetition
Hello! I have such problem that: - My console shows maximally x last lines, then truncates - Error message takes 2 line - In case of very big stack trace, there will be 2*x error lines - In such case I do not see any debug output In this case, it's about recursion: File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) and so on... I think it should be instead: File b2.py, line 124, in seek_solution [*repeated x times*] solution = self.seek_solution(weight + U.gravity, len(test), test) Getting big strack trace is most probable with functions calling themselves - thus, long stack traces usually contain such repetitions. As those functions might not call themselves directly, one cycle of recursion might become four lines long, in such case: Stack item 1: File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) Stack item 2: File b2.py, line 124, in seek_solution solution = self.seek_solution(weight + U.gravity, len(test), test) Stack item repetitions: [#1, #2] * x This could simply enumerate stack items and then create formulas of repetitions, like: [[#1, #2] * 15, #3 * 15] * 3 If it shows each message written-out at least one and max two or three times, but over that gives it an id and shows patterns of those instead, it will be a lot better. I have, sometimes, gone through some four pages of Java stack traces etc., but I think that having such long array of errors does not make it more readable or simple - if you can see everything in one page, then it's good enough for pondering. And scrolling up and looking at output would be a nice feature ;) Especially now, as I am going to raise recursion limit - this program would be perfectly possible without relying on built-in loop constructions so much, but I did it yesterday in such manner and it simply raised into unmanageable complexity. Thus, now I am trying to encapsulate it's logic into pieces, which maximize the use of Pythons overloads and function-based iterators etc., but this makes error messages that long when I do something wrong - and I can't even check if that was really some mistake in code or just the recursion actually needs to be deeper than I hoped. Tambet -- http://mail.python.org/mailman/listinfo/python-list
Re: Error message repetition
Depending on how far this goes up, you might just be able to change the backlog your terminal emulator saves? that would allow you to scroll up. If you can't do that, you should get a proper console. I use bash, which allows to do that. This was rather a case example - actually this output gets pretty annoying anyway and should contain only most important information at any given moment. Scrollbar getting too small is another example of the same case ...the case that if something outputs 2000 lines of repetition, it's not very much of use. This could be that someone does not understand the cryptic output, but I think that anyone having that long traceback is probably intelligent enough to google for Python traceback what those cryptic things mean ;) I think that this functionality should be triggered only by traceback bigger than, say, 20 lines or so. Also, this is not the point, where processor usage costs anything. Anyway, if you want to customise the traceback output, you can! simply replace sys.excepthook with your own version. http://docs.python.org/dev/py3k/library/sys.html#sys.excepthook Ok, I should have thought of that - anyway, such thing should be standard functionality. I personally love nonverbose output - if it can't say it in 1 A4, it should just tell me that it could if I asked. I mean, normally I like to have one sight over the traceback and another over program itself. Thanks for that hook ...I will use it in case I get four of five more similar errors today ;) -- http://mail.python.org/mailman/listinfo/python-list
