[issue20345] Better logging defaults
Arne Babenhauserheide added the comment: Just calling basicConfig() is not problematic. Specifying the format is what requires mental investment (because for that I need to read up on the config options). Would it be possible to add a simple way to select a certain logging style? In Mercurial I can for example call `hg log --style changelog` to get GNU-style changelog output. This is easy to remember. On the other hand, getting --template string right for somewhat complex log styles is a small task in itself. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20345] Better logging defaults
Arne Babenhauserheide added the comment: (though calling logging.basicConfig() still produces some overhead, it does not pull me away from the task I’m currently doing) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20345] Better logging defaults
New submission from Arne Babenhauserheide: Currently the default operation of logging prints messages like the following: INFO:root: Milk found. This is close to a print-call, but not much more useful - especially not in small scripts. To make the default settings more useful to quick scripts, I would suggest adding the filename and linenumber by default. This would be equivalent to the following setup: logging.basicConfig( level=logging.INFO, format=%(levelname)s (%(filename)s::%(lineno)s): %(message)s) With that setup, the above message would look like this: INFO (move.py::23): Milk found. -- components: Library (Lib) messages: 208812 nosy: ArneBab priority: normal severity: normal status: open title: Better logging defaults ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20345] Better logging defaults
Arne Babenhauserheide added the comment: I do not think it is necessary to change the defaults, but I do think that it would help users of python. In the usecase of bigger applications, the default logging format does not matter: the overhead of logging.basicConfig() only happens once while the advantages help for the whole time. In the usecase of small programs and quick scripts, the overhead of having to use logging.basicConfig() is big, though: It requires reading up on the different formatting options and actually thinking about a good format. But the results only help that small script, and for the next script the programmer will likely have to read the documentation again. If logging would have a better default, the programmer would just have to remember “import logging, then call logging.LEVEL()”. In the python console, logging.tab will autocomplete the level, so programmers do not actually have to read up anything: It actually goes down to “log with logging”. And that’s a very different level of usability than having to call logging.basicConfig(). And I think that the filename and the line number is the minimum information necessary for any debug message - though the format could be matched to `grep -n` by replacing the double colon with a single colon. To stay with your analogy: It’s not about the color of the bikeshed. It’s about providing the basic bycycle stands in the shed, so people who have no strong feelings about bikesheds can simply go there, leave the bike and move on - instead of having to adjust the stand every time to keep their bike from falling over. I agree, though, that backwards compatibility could be an issue. Can you give me a hint, how I could investigate that? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: …you were faster than me (I only managed to get the repo onto my current computer yesterday and the children kept me occupied). Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27484/profile-docs-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27485/profile-docs-2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27491/sort-argument-2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27492/sort-argument-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: Jepp, I missed that. I hope the added patches clear that up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Removed file: http://bugs.python.org/file27492/sort-argument-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27493/sort-argument-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Removed file: http://bugs.python.org/file27491/sort-argument-2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file27494/sort-argument-2.7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: I’ll create them as soon as I get the time. It’s not as if that’s really hard - but I still have to do it (need to diff against current tip - I already merged, so that should work without problems). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: Copyright-assignment signed and sent. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: Did you get to taking a look? Is there anything I should change? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: What would be the best way to get this patch reviewed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Arne Babenhauserheide added the comment: Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
New submission from Arne Babenhauserheide arne_...@web.de: cProfile reports the profiling result in a table with the headers ncalls tottime percall cumtime percall filename:lineno(function) The respective arguments are calls time -cumulative - nfl Since I had to lookup these different names everytime I used cProfile, I think that it should take the table headings as argument aliases. Also there is inconsistent naming of pcalls between docs and code. In the docs of Stats.sort_stats pcalls is named primitive call count. In the code at Stats.sort_arg_dict_default it was just named call count. I created 4 patches to fix that in Python 2.7 and Python 3.2. The first is attached here, the later will be attached to comments. They apply to 822d7a1f8885 for 2.7 and 89b699e68fa2 for 3.2. I also created a patch for adding percall sorting, but that requires more invasive changes and I did not see a simple name to distinguish between the two bycall headings. -- components: Library (Lib) files: 2.7-0-pcalls.diff keywords: patch messages: 161508 nosy: ArneBab priority: normal severity: normal status: open title: cProfile does not take its result headers as sort arguments versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25695/2.7-0-pcalls.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file25696/2.7-1-headings-sortable.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file25697/3.2-0-pcalls.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14900] cProfile does not take its result headers as sort arguments
Changes by Arne Babenhauserheide arne_...@web.de: Added file: http://bugs.python.org/file25698/3.2-1-headings-sortable.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
Arne Babenhauserheide arne_...@web.de added the comment: I also think that rounding half away from zero would be the most obvious choice, as it does not introduce a bias for random numbers distributed around 0 while being close to what I would expect from school mathematics. The case of n*(random() - 0.5) which I assume as common, this should work well, which is not the case for rounding towards +infinity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] make round() floating-point errors less hurtful
New submission from Arne Babenhauserheide arne_...@web.de: Hi, I just stumbled over round() errors. I read the FAQ¹, and even though the FAQ states that this is no bug, its implementation is less than ideal. To illustrate: round(0.5, 1) 0.0 and round(5, -1) 0 This is mathematically wrong and hits for comparisions which humans put in. As alternate I use the following hack myself where ever I have to round numbers: def roundexact(a, *args): ... return round(a+0.001*max(1.0, (2*a)//10), *args) This has correct behavior for *5 on my hardware: roundexact(0.5, 0) 1.0 Its errors only appear in corner cases: roundexact(0.4999, 0) 0.0 roundexact(0.49998, 0) 1.0 This implementation shields me from implementation details of my hardware in all but very few extreme cases, while the current implementation of round() exhibits the hardware-imposed bugs in cases which actually matter to humans. Maybe round could get a keyword argument roundup5 or such, which exhibits the behavior that any *5 number is rounded up. Note: The decimal module is no alternative, because it is more than factor 100 slower than floats (at least for simple computations): from timeit import timeit timeit(float(1.0)+float(0.1)) 0.30365920066833496 timeit(Decimal(1.0)+Decimal(0.1), setup=from decimal import Decimal, getcontext; getcontext().prec=17) 49.96972298622131 ¹: http://docs.python.org/library/functions.html?highlight=round#round -- components: Interpreter Core messages: 144590 nosy: ArneBab priority: normal severity: normal status: open title: make round() floating-point errors less hurtful versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] make round() floating-point errors less hurtful
Arne Babenhauserheide arne_...@web.de added the comment: Better comparision of decimal and float: timeit(a+a, setup=from decimal import Decimal, getcontext; getcontext().prec=17; a = Decimal(1.0)) 21.125790119171143 timeit(a+a, setup=a = float(1.0)) 0.05324697494506836 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] make round() floating-point errors less hurtful
Arne Babenhauserheide arne_...@web.de added the comment: If the C accelerator for decimal gets decimal performance close to floats (which I doubt, because it has to do much more), it could be very useful for me. What is its estimated time to completion? Even when it is finished, it does not change the problem that round(0.5, 0) gives mathematically wrong results, so python requires hacks to be correct in this very simple case - instead of being right for most of the simple cases and only get it wrong in corner cases. My hack isn’t really clean, though, because it depends on the internal representation of floats in the hardware. A real fix would have to get the real size of floats and adjust the added value accordingly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
Arne Babenhauserheide arne_...@web.de added the comment: I did not know about rounding to even, so maybe there should be a warning in the 2.7 documentation, that the behavior changed in python 3 (I just checked that: python2.7 is in line with the documentation). The first time I stumbled over these issues was when implementing a game, where I wanted to map pixels to hexfields, where I had to get the borderline cases right: https://bitbucket.org/ArneBab/hexbattle/src/38ad49c04836/hexgrid.py#cl-24 This likely won’t hit me in the game, but it really hurts in the doctests. PS: I like the naming as “allow other rounding modes”, so I changed the title of the bug. I hope that’s OK. PPS: Thank you for all your replies! The bugtracker feels really welcoming and helpful, even when reporting something as a bug, which is just a difference in goal definition. I hope it will turn out to be useful for the community! -- title: make round() floating-point errors less hurtful - allow other rounding modes in round() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
Arne Babenhauserheide arne_...@web.de added the comment: cdecimal sounds great! when is it scheduled for inclusion? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
