Re: [Python-Dev] API for the new sysconfig module
Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. I really like that much better than Java-like accessor functions. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Dec 12, 2010, at 02:42 PM, Antoine Pitrou wrote: On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I have used them and I do think they're fairly ugly and unwieldy. However, I agree that we should not rush into a different design. Since sysconfig was essentially refactored out of distutils (and now we have two ways to do it!), and we're getting distutils2 for 3.3, I think it would be better to work out a more natural design for sysconfig for 3.3. Then the sysconfig module can go through the natural deprecation cycle. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, Dec 12, 2010 at 11:42 PM, Antoine Pitrou solip...@pitrou.net wrote: I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I would also like those advocating replacement of a tried and tested API with oh, you can just use a single function for it to rewrite distutils2 and the other tools that currently used distutils.sysconfig based on their single function approach before *anything* gets touched. This is not an API that was invented on a whim. It is well-established, with existing use cases that are essential to the wider Python ecosystem, and are more easily managed on some Linux distributions if they don't involve a dependency on distutils. Proposing to throw it away in favour of an ill-defined single function that indiscriminately mixes system data with metadata about that data because some people that don't even use the module find it aesthetically displeasing seems... unwise. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Sun, Dec 12, 2010 at 5:32 AM, Brett Cannon br...@python.org wrote: On Fri, Dec 10, 2010 at 22:21, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Nick Coghlan ncoghlan at gmail.com writes: This could actually make a reasonably good basic for a task oriented subsection of the logging documentation. Something like: Good suggestion, I'll see what I can do. Just wanted to +1 on some task-oriented (or at least simple intro) docs going into the logging module. I think Vinay has made some great improvements to the logging module docs in the last day or two. The latest version out of SVN is available on the site at the usual location: http://docs.python.org/dev/library/logging I am putting some minor notes here for Vinay's benefit (I can put them on the tracker instead, if he would prefer): General It may be worth talking to Georg about how best to split the logging docs up into multiple files. The sidebar menu is getting kinda overwhelmed. 14.7.1.1 Parenthetical comment in first row of second table should start with (e.g. for not (e.g. or 14.7.1.8 Probably best to say that's it for the basic tutorial and then point people towards the advanced tutorial in 14.7.2 before setting them loose on the rest of the docs. The advanced tutorial defines the terminology and gives the necessary structure to help keep the detailed docs in perspective without being overwhelmed by the detail. 14.7.2.1 Something appears to have gone wrong with the first bulleted list. It is missing the These are the configuration methods: intro text, as well as a bullet for add/removeHandler The does not address filters part should cross-reference the detailed section on filter objects This section should state explicitly whether or not the level setting on a child logger affects which messages it passes to its parent logger 14.7.2.5 This section is out of date, and needs to be caveated to make it clear that it applies only to version prior to Python 3.2 (for 3.2, it can describe the new handler of last resort behaviour) And that's the end of the two tutorials... very nice update :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
Lukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. I really like that much better than Java-like accessor functions. When I use sysconfig, I just want to get things done as quickly and painlessly as possible. The API suits me just fine (in fact, I find it one of the APIs that are easy to remember). Given that sysconfig will always contain a certain amount of hackery and will always change to accommodate new systems, I'd prefer that it remains a standalone module. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for the new sysconfig module
On Sun, Dec 12, 2010 at 3:05 PM, Barry Warsaw ba...@python.org wrote: On Dec 12, 2010, at 02:42 PM, Antoine Pitrou wrote: On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa luk...@langa.pl wrote: Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: *(I sometimes lose track of which changes were made in both branches pre-2.7, which ones were mode post-2.7 release, and which ones went in pre-2.7, but were 3.x only regardless) Right. I missed that it was already in 2.7. So, now we're stuck with it, forever. Why not deprecate it for 3.2 (easy since it's probably not yet used anywhere anyway, even in 2.7) and introduce sys.sysconfig. We already had a lot of churn around these APIs (distutils friends). I don't think it's a good idea to introduce even more churn. Oh and by the way it's too late to add or remove features from 3.2. I really like that much better than Java-like accessor functions. Do you actually use sysconfig yourself? It's quite a specialized module, and I don't think API elegance arguments have a great weight here. I have used them and I do think they're fairly ugly and unwieldy. However, I agree that we should not rush into a different design. Since sysconfig was essentially refactored out of distutils (and now we have two ways to do it!), and we're getting distutils2 for 3.3, I think it would be better to work out a more natural design for sysconfig for 3.3. Then the sysconfig module can go through the natural deprecation cycle. I don't think any API refactoring worth the pain here. I don't see the proposed changes make the caller's code that much better. The existing one is good enough in my opinion. Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Nick Coghlan ncoghlan at gmail.com writes: Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and highlighting the typos and omissions. I've just checked in a further update; hopefully it'll get built soon so we can all see the latest changes. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] use case for bytes.format
I'm considering to write some pure python pdf lib from from scratch, but found there is no built-in formating for bytes. It's very frustrating to use some inefficient surogate funtion, which is gong to be called thousands times. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 10 December 2010 20:57, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 12/10/2010 12:49 PM, Antoine Pitrou wrote: And yet, I have helped many people who were baffled by exactly what Bill observed: logging.info() didn't do anything. Maybe the default should be INFO? Funny, because displaying only errors and silencing other messages is exactly what I expected logging to do by default. So we are slowly learning the things that should be on the first couple pages of the logging docs... 1) simple example for one file programs, include an example of specifying output severity threshold. I'm with Antoine here on my expectations. 2) example for multi-module, showing how a single logging destination causes logging to happen in all modules, at the same level (if that is the case, which I hope it is). 3) Maybe a small discussion of log formatting should be next? So the user realizes he shouldn't do the message formatting himself? 4) Then rotating logs for long-running programs. The thing *I* hit very early was wanting to add a command lime option to my script to set the logging level. I'd have liked to be able to add --log=INFO/DEBUG/... but to do that I seem to need to write my own mapping between level names and numbers. A simple example of how to tie command line options to logging config would be a great addition to the documentation. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] use case for bytes.format
On 12/12/2010 2:04 PM, Zeljko wrote: This post should have gone to python-list, mirrored as gmane.comp.python.general. Please limit any further response to either of those (or c.l.p) and delete pydev. I'm considering to write some pure python pdf lib from from scratch, but found there is no built-in formating for bytes. Bytes do, but you should use text str for general text manipulation. It's very frustrating to use some inefficient surogate funtion, which is gong to be called thousands times. This sentence has 3 spelling mistakes, 2 of which would be caught with a mail client like Thunderbird (free) that has spelling correction. Please consider switching. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Hi, I suggest to replace “error” with “event” in the module doc synopsis. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/12/2010 2:26 PM, Paul Moore wrote: The thing*I* hit very early was wanting to add a command lime option to my script to set the logging level. I'd have liked to be able to add --log=INFO/DEBUG/... but to do that I seem to need to write my own mapping between level names and numbers. A simple example of how to tie command line options to logging config would be a great addition to the documentation. Oh? import * from logger # change some details to avoid this basicConfig( level= eval( opt.loglevel ) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/12/2010 9:41 AM, Vinay Sajip wrote: Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and highlighting the typos and omissions. I've just checked in a further update; hopefully it'll get built soon so we can all see the latest changes. I'm not as fast as Nick, but let me add that these changes to the documentation are surely helpful to me. I've read 12% now, of a bigger base, but it was very approachable, and I've come away with being ready to scrap my little logger, I know what I need to do to make my multi-module logging work with the logging module instead, to greater benefit than my little logger, and the only advanced technique that I think I need to learn at the moment is formatters, so next chance I get I'll read about those. The mountain doesn't look as steep, now! Thanks for the fast reaction time. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 2010-12-12 18:42 , Glenn Linderman wrote: On 12/12/2010 2:26 PM, Paul Moore wrote: The thing*I* hit very early was wanting to add a command lime option to my script to set the logging level. I'd have liked to be able to add --log=INFO/DEBUG/... but to do that I seem to need to write my own mapping between level names and numbers. A simple example of how to tie command line options to logging config would be a great addition to the documentation. Oh? import * from logger # change some details to avoid this basicConfig( level= eval( opt.loglevel ) level = getattr(logging, opt.logLevel) or level = logging._levelNames[opt.logLevel] -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kern robert.k...@gmail.com wrote: level = getattr(logging, opt.logLevel) While this is the approach I would recommend, it does have a couple of downsides: 1. An upper() call is also needed to allow strings like info instead of INFO: 2. If an integer is available, it would be nice to return it unmodified (or, if we ever get named values in the standard library, convert it to that) 3. The asymmetry with logging.getLevelName grates a bit So it would be far more obvious if there was a logging.getLevel counterpart to logging.getLevelName that looked something like: def getLevel(level): try: return operator.index(level) # Integers and equivalents except TypeError: pass try: key = level.upper() except Exception as ex: raise TypeError(Log level must be an integer or string) from ex return globals()[key] level = logging._levelNames[opt.logLevel] That doesn't work (_levelNames maps from integers to strings, we want the mapping from strings to integers and it is only the module globals that provides that). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87202 - python/branches/py3k/Doc/library/logging.rst
On Mon, Dec 13, 2010 at 8:45 AM, vinay.sajip python-check...@python.org wrote:
+to get the value which you'll pass to :func:`basicConfig` via the *level*
+argument. You may want to error check any user input value, perhaps as in the
+following example::
+
+ # assuming loglevel is bound to the string value obtained from the
+ # command line argument. Convert to upper case to allow the user to
+ # specify --log=DEBUG or --log=debug
+ numeric_level = getattr(logging, loglevel.upper(), None)
+ assert numeric_level is not None, 'Invalid log level: %s' % loglevel
+ logging.basicConfig(level=numeric_level, ...)
Minor nit - using asserts to check user input is generally a bad idea.
A more explicit check might be a better example:
if not isinstance(numeric_level, int):
raise ValueError('Invalid log level: %s' % loglevel)
This also covers the case where someone does something weird like pass
in basic_format as a logging level.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 2010-12-12 21:30 , Nick Coghlan wrote:
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kernrobert.k...@gmail.com wrote:
level = getattr(logging, opt.logLevel)
While this is the approach I would recommend, it does have a couple of
downsides:
1. An upper() call is also needed to allow strings like info instead
of INFO:
2. If an integer is available, it would be nice to return it
unmodified (or, if we ever get named values in the standard library,
convert it to that)
3. The asymmetry with logging.getLevelName grates a bit
So it would be far more obvious if there was a logging.getLevel
counterpart to logging.getLevelName that looked something like:
def getLevel(level):
try:
return operator.index(level) # Integers and equivalents
except TypeError:
pass
try:
key = level.upper()
except Exception as ex:
raise TypeError(Log level must be an integer or string) from ex
return globals()[key]
I don't think that the implementation should use globals(). I wouldn't want
logging.getLevel('basic_format') to work. Instead, it should look it up in the
known set of levels.
level = logging._levelNames[opt.logLevel]
That doesn't work (_levelNames maps from integers to strings, we want
the mapping from strings to integers and it is only the module globals
that provides that).
At least in Python 2.6, it maps both ways. But then again, it is an
_implementation _detail that should not be relied upon in your programs. I would
suggest that there should be two dictionaries as part of the documented API, one
mapping numbers to names and one mapping names to numbers. Or functions/methods
returning said dictionaries. Having the entire mappings at hand is more useful
than having functions that do the translation. They would allow you to
auto-generate UIs (e.g. the help text for a --log-level argument or a radio box
widget in a GUI). Having separate mappings makes them easier to work with than
the 2.6-style _levelNames mapping.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Mon, Dec 13, 2010 at 2:13 PM, Robert Kern robert.k...@gmail.com wrote: level = logging._levelNames[opt.logLevel] That doesn't work (_levelNames maps from integers to strings, we want the mapping from strings to integers and it is only the module globals that provides that). At least in Python 2.6, it maps both ways. But then again, it is an _implementation _detail that should not be relied upon in your programs. Ah, you're quite right - I didn't notice that when looking at the contents (the first entries happened to map levels to names) I would suggest that there should be two dictionaries as part of the documented API, one mapping numbers to names and one mapping names to numbers. Or functions/methods returning said dictionaries. Having the entire mappings at hand is more useful than having functions that do the translation. They would allow you to auto-generate UIs (e.g. the help text for a --log-level argument or a radio box widget in a GUI). Having separate mappings makes them easier to work with than the 2.6-style _levelNames mapping. Definitely something worth considering for 3.3. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
