[tor-bugs] #4913 [Stem]: Add stem.util.conf.Config.save()

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Mon Jan 16 16:09:01 UTC 2012


#4913: Add stem.util.conf.Config.save()
-------------------------+--------------------------------------------------
 Reporter:  gsathya      |          Owner:  atagar        
     Type:  enhancement  |         Status:  needs_revision
 Priority:  normal       |      Milestone:                
Component:  Stem         |        Version:                
 Keywords:               |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------

Comment(by atagar):

 > I'm not sure I follow. Where is this from?

 First line after the pydocs in...
 https://gitweb.torproject.org/user/gsathya/stem.git/commitdiff/4ba49e08ba1d4b07fbb3af87652cd11b3d9fdb9d

 > Yeah, I wanted to do --
 > for entry in sorted(self.iterkeys()):

 Oh, good catch - we should use sorted() instead of sort in this case...

 > So we have a config file that has...

 Ahh, I see. This is a problem with the set() method, not with save. In the
 example that you give the user is expecting the set() call to overwrite
 the configuration value rather than add a new one.

 On reflection, what if we changed set() to...

 {{{
 def set(self, key, value, overwrite = True):
   """
   Sets the given key/value configuration mapping, behaving the same as if
 we'd
   loaded this from a configuration file.

   Arguments:
   key (str)           - key for the configuration mapping
   value (str or list) - value we're setting the mapping to
   overwrite (bool)    - replaces our current configuration mapping if
 True,
                         otherwise it's appended to the configuration
   """
 }}}

 This would allow the more intuitive usage that you're expecting.

 > ACK! I just saw that you passed Multiple=True to Config.get_value(), in
 your latest commit. Now with the above example, when we call Config.save()
 we'd be storing
 >
 > login.password foo bar
 >
 > Right?

 Not quite, we'd store...

 {{{
 login.password foo
 login.password bar
 }}}

 This seems like the right behavior if we *mean* for password to have
 multiple values. Again, if we wanted it to have a single value then that's
 more a problem with set().

 > Please Ignore. I think we can close this ticket and save me from saying
 anything else?

 Don't worry about it, we're all human. :)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4913#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list