Question by someone coming from C...

Discussion in 'Python' started by Skye, Jun 9, 2008.

  1. Skye

    Skye Guest

    Writing this app in Python, not sure what the "best practice" would
    be.

    I want a bitfield global logging level that allows me to turn specific
    debugging modules on and off. If I was doing this in C, I'd just use
    some globals like:

    unsigned int debug_level = 0;
    #define DEBUG_GENERAL 0x0001
    #define DEBUG_CONFIG 0x0002
    #define DEBUG_OPTIONS 0x0004
    etc etc

    So I guess my questions are:

    1. there doesn't seem to be a way to define global constants like in
    other languages?
    2. any special voodoo to use bitfields in Python?

    Thanks!
    Skye
    Skye, Jun 9, 2008
    #1
    1. Advertising

  2. Skye

    Lie Guest

    On Jun 10, 4:00 am, Skye <> wrote:
    > Writing this app in Python, not sure what the "best practice" would
    > be.
    >
    > I want a bitfield global logging level that allows me to turn specific
    > debugging modules on and off.  If I was doing this in C, I'd just use
    > some globals like:
    >
    > unsigned int debug_level = 0;
    > #define DEBUG_GENERAL 0x0001
    > #define DEBUG_CONFIG 0x0002
    > #define DEBUG_OPTIONS 0x0004
    > etc etc
    >
    > So I guess my questions are:
    >
    > 1. there doesn't seem to be a way to define global constants like in
    > other languages?


    Global variables is like this:

    -- module.py --
    someglobal = 1
    def func():
    print someglobal
    # This makes someglobal readonly,
    # any attempt to write to someglobal
    # would create a new local variable.

    def func2():
    global someglobal
    someglobal = 2
    # this allows you to manipulate the global
    # variable
    -- --

    > 2. any  special voodoo to use bitfields in Python?


    That's a not a good idea in Python. In C, it might worth saving some
    few bytes of memory especially for embedded application, in python
    it's just not worth it, the virtual machine is way huge compared to
    the few bytes of space saved.

    OK, it is possible to do bitfield manipulation in python:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/113799 but
    it's not really worth it

    >
    > Thanks!
    > Skye
    Lie, Jun 9, 2008
    #2
    1. Advertising

  3. Skye

    Skye Guest

    OK, sounds good. So if not bitfields, what would be a good Python-y
    way to do it?
    Flip booleans in a "debug config" dictionary or something?

    Skye
    Skye, Jun 9, 2008
    #3
  4. Skye

    Matimus Guest

    On Jun 9, 2:00 pm, Skye <> wrote:
    > Writing this app in Python, not sure what the "best practice" would
    > be.
    >
    > I want a bitfield global logging level that allows me to turn specific
    > debugging modules on and off. If I was doing this in C, I'd just use
    > some globals like:
    >
    > unsigned int debug_level = 0;
    > #define DEBUG_GENERAL 0x0001
    > #define DEBUG_CONFIG 0x0002
    > #define DEBUG_OPTIONS 0x0004
    > etc etc
    >
    > So I guess my questions are:
    >
    > 1. there doesn't seem to be a way to define global constants like in
    > other languages?
    > 2. any special voodoo to use bitfields in Python?
    >
    > Thanks!
    > Skye


    There is no conventional way to define a constant. There may be some
    tricks if you look around, but I've been coding Python for a long time
    and never actually needed one. The side effect is that you could
    redefine one of the values at run-time. By naming convention though,
    the user will know not to do that, just like they know not to mess
    with attributes of an object that begin with "_". If they do mess with
    it, well, they better know what they are doing.

    There is no special bitfield voodoo that I know of.

    Generally, naming conventions are the same as they would be in C (all
    caps):

    FOO = 0x01
    BAR = 0x02
    BAZ = 0x04

    val = FOO | BAR | BAZ

    if val & BAR:
    #do bar stuff

    The only time to do that sort of thing (in python) is when interacting
    with something else that isn't written in Python though. In general,
    for logging, just use the standard logging module:
    http://docs.python.org/lib/module-logging.html


    Matt
    Matimus, Jun 9, 2008
    #4
  5. Skye

    Lie Guest

    On Jun 10, 4:32 am, Skye <> wrote:
    > OK, sounds good.  So if not bitfields, what would be a good Python-y
    > way to do it?


    The word is "pythonic".

    > Flip booleans in a "debug config" dictionary or something?


    I'm not really sure, I've been programming with Python (and some other
    languages) but never really felt the need to store data in such super-
    efficient manners. I reckon a dict should do the job and it would be
    easier to read too compared to bitfield, since dict's entry is named.

    Actually, in python I usually do not put debugging codes before
    entering debugging cycle, and I usually remove all those debugging
    codes when the debugging cycle has finished (I'm talking for myself,
    not the whole python community).

    > Skye
    Lie, Jun 9, 2008
    #5
  6. Skye

    Skye Guest

    On Jun 9, 2:35 pm, Matimus <> wrote:
    > The only time to do that sort of thing (in python) is when interacting
    > with something else that isn't written in Python though. In general,
    > for logging, just use the standard logging module:http://docs.python.org/lib/module-logging.html


    Thanks! It looks like subclassing the logging module would be a much
    better idea :)

    Skye
    Skye, Jun 9, 2008
    #6
  7. Skye schrieb:
    > Writing this app in Python, not sure what the "best practice" would
    > be.
    >
    > I want a bitfield global logging level that allows me to turn specific
    > debugging modules on and off. If I was doing this in C, I'd just use
    > some globals like:
    >
    > unsigned int debug_level = 0;
    > #define DEBUG_GENERAL 0x0001
    > #define DEBUG_CONFIG 0x0002
    > #define DEBUG_OPTIONS 0x0004
    > etc etc



    For debugging - use the module logging. And configure properly.

    Diez
    Diez B. Roggisch, Jun 9, 2008
    #7
  8. Skye

    John Krukoff Guest

    On Mon, 2008-06-09 at 15:02 -0700, Skye wrote:
    > On Jun 9, 2:35 pm, Matimus <> wrote:
    > > The only time to do that sort of thing (in python) is when interacting
    > > with something else that isn't written in Python though. In general,
    > > for logging, just use the standard logging module:http://docs.python.org/lib/module-logging.html

    >
    > Thanks! It looks like subclassing the logging module would be a much
    > better idea :)
    >
    > Skye
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    Really, the logging module is heavy weight enough, it's very doubtful
    you need to add any functionality at all.

    If you look at the documentation for logger objects, you'll see that you
    can use a number of them, and set different logging levels for each one.
    So, to get equivalent functionality to your bitfields, instead make a
    separate logger for each category (config, options, blah...) and call
    the object to log for that type.

    i.e. config.debug( ... ), options.error( ... )

    Since you probably want access to these from many different places in
    your code, I find the simplest way is to create a logging module of your
    own (not called logging, obviously) and instantiate all of your loggers
    in that namespace, then import that one module as needed.

    Perhpas you want one logging message to qualify as several different
    types? That's the only place where I could see this being too verbose,
    but even then it'd be easy to make a wrapper function that made that
    easy given a collection of loggers.
    --
    John Krukoff <>
    Land Title Guarantee Company
    John Krukoff, Jun 9, 2008
    #8
  9. Skye

    Carl Banks Guest

    On Jun 9, 5:00 pm, Skye <> wrote:
    > Writing this app in Python, not sure what the "best practice" would
    > be.
    >
    > I want a bitfield global logging level that allows me to turn specific
    > debugging modules on and off. If I was doing this in C, I'd just use
    > some globals like:
    >
    > unsigned int debug_level = 0;
    > #define DEBUG_GENERAL 0x0001
    > #define DEBUG_CONFIG 0x0002
    > #define DEBUG_OPTIONS 0x0004
    > etc etc
    >
    > So I guess my questions are:
    >
    > 1. there doesn't seem to be a way to define global constants like in
    > other languages?
    > 2. any special voodoo to use bitfields in Python?


    Apart from the good advice "use the logging module", here is the
    Pythonic way you'd do this sort of thing in general. (There's not
    always a spiffy built-in module for anything you want to do; just
    usually. :)

    The lack of globals is a minor issue; you can get globally accessible
    values by storing them in a module and importing that module.

    The way I'd do the above is to define a module, say config.py, to hold
    configuration options. Then I'd define each condition in its own
    variable:

    debug_general = False
    debug_config = False
    debug_options = False

    I could then enable debugging by changing the value:

    import config
    config.debug_general = True

    And I could use print debugging output based on the config settings
    like this:

    import config
    if config.debug_general or config.debug_options:
    print_debugging_info()

    But again, the logging modules handles all this for you so no point
    for this particular task.

    P.S. I'd do it more or less this way in C, too.


    Carl Banks
    Carl Banks, Jun 9, 2008
    #9
  10. Skye

    Skye Guest

    Very cool - I'm liking the pythonic way of doing things more and
    more.
    The logger namespace/singleton idea makes great sense!

    I see how the module variables make globals irrelevant, thanks!

    Skye
    Skye, Jun 9, 2008
    #10
  11. Skye a écrit :
    > Writing this app in Python, not sure what the "best practice" would
    > be.
    >
    > I want a bitfield global logging level that allows me to turn specific
    > debugging modules on and off. If I was doing this in C, I'd just use
    > some globals like:
    >
    > unsigned int debug_level = 0;
    > #define DEBUG_GENERAL 0x0001
    > #define DEBUG_CONFIG 0x0002
    > #define DEBUG_OPTIONS 0x0004
    > etc etc
    >
    > So I guess my questions are:
    >
    > 1. there doesn't seem to be a way to define global constants like in
    > other languages?
    > 2. any special voodoo to use bitfields in Python?


    Others already gave you the best advises (namely: using the logging
    module). But let's answer your questions anyway:

    1/ by convention, anything named ALL_UPPER is considered a constant.
    Anyone breaking your code by messing with a PSEUDO_CONSTANT is on it's
    own and has no right to complain. Consider it as a "warranty void if
    unsealed" warning.


    2/ just use plain integers and bitwise operators. But we're usually more
    concerned about readability than about saving bits, and I've rarely
    (maybe twice ?) seen bitfields used that way in Python.
    Bruno Desthuilliers, Jun 10, 2008
    #11
  12. John Krukoff wrote:
    > Since you probably want access to these from many different places in
    > your code, I find the simplest way is to create a logging module of your
    > own (not called logging, obviously) and instantiate all of your loggers
    > in that namespace, then import that one module as needed.


    No, don't do that. Simple do

    import logging
    log = logging.getLogger("some_name")

    The logging module takes care of the rest. The logging.getLogger()
    function creates a new logger *only* when the name hasn't been used yet.

    Christian
    Christian Heimes, Jun 10, 2008
    #12
  13. Skye

    John Krukoff Guest

    On Wed, 2008-06-11 at 00:43 +0200, Christian Heimes wrote:
    > John Krukoff wrote:
    > > Since you probably want access to these from many different places in
    > > your code, I find the simplest way is to create a logging module of your
    > > own (not called logging, obviously) and instantiate all of your loggers
    > > in that namespace, then import that one module as needed.

    >
    > No, don't do that. Simple do
    >
    > import logging
    > log = logging.getLogger("some_name")
    >
    > The logging module takes care of the rest. The logging.getLogger()
    > function creates a new logger *only* when the name hasn't been used yet.
    >
    > Christian
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    Nifty, I never noticed that function, thanks for pointing it out as
    it'll make my application a bit simpler.

    Now, if they'd only add a syslog module that uses the libc syslog
    interface (sure, it wouldn't be thread safe, but at least it'd be
    portable to AIX, unlike the current one), I'll be a happy camper.
    --
    John Krukoff <>
    Land Title Guarantee Company
    John Krukoff, Jun 11, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Holden

    PyCon is Coming! PyCon is Coming!

    Steve Holden, Jan 5, 2006, in forum: Python
    Replies:
    0
    Views:
    293
    Steve Holden
    Jan 5, 2006
  2. lightning
    Replies:
    0
    Views:
    2,085
    lightning
    Oct 24, 2008
  3. laredotornado
    Replies:
    8
    Views:
    418
  4. Jeff Carlson
    Replies:
    9
    Views:
    113
    James Edward Gray II
    Oct 12, 2005
  5. Brian Hicks

    Coming from Perl question

    Brian Hicks, Aug 17, 2006, in forum: Ruby
    Replies:
    6
    Views:
    108
    Austin Ziegler
    Aug 18, 2006
Loading...

Share This Page