I'm trying to add an Entry field to a gtk.ComboBox. The easy way out would be to use gtk.ComboBoxEntry, but I read somewhere that ComboBoxEntry is deprecated.
I tried setting the property "has-entry" to True, but this can only be done on construction.
Then I tried, somewhat desperately, to add this as a keyword parameter to the constructor, but 'has_entry' doesn't seem to be an existing keyword parameter.
So, how do I set a property at construction time in Python?
Thanks to help on the #gtk+ IRC channel, I found out that (at least some) of the pygtk functions are available by their C-names in Python. So, it is possible to write:
cbboxe = gtk.combo_box_new_with_entry() or
cbboxe = gtk.combo_box_text_new_with entry()
Strangely enough, it was also indicated that
gtk.ComboBox(has_entry = True)
should work. #ebassi (IRC) showed me it worked - I tried it here but wasn't able to get it accepted. Same PyGTK version and all. YMMV :)
(Thanks #SiHa for reminding me I had this question still open!)
Related
I'm having some issues using the console-menu module for Python. I made my menu with the constructor and added a few items to it, but i'm having a hard time figuring out how to add formatting to it. There is a MenuStyle class in the documentation that I think I need to use:
classconsolemenu.format.MenuStyle(margins=None, padding=None, border_style=None, border_style_type=None, border_style_factory=None)
The full documentation is available here: https://console-menu.readthedocs.io/en/latest/consolemenu.html
It's pretty short and to the point. I just don't understand what to do. Do I need to construct the border object and then use it in the ConsoleMenu() constructor? or add it in later?
From reading the documentation it looks like you need to set ConsoleMenu's formatter argument to an instance of MenuFormatBuilder. example2.py has the following that might help you:
menu_format = MenuFormatBuilder().set_border_style_type(MenuBorderStyleType.HEAVY_BORDER)
...
menu = ConsoleMenu("Root Menu", "This is the Root Menu Subtitle", formatter=menu_format)
I'm using feedparser and it seems that for a vast majority of feed items have a published_parsed field. However, some others only have an updated_parsed field.
How do I know when to use one or the other? Am I safe if I use either one or the other, something like this?
def get_publishing_date(item):
try:
return item.published_parsed
except:
return item.updated_parsed
Does feedparser not offer this abstraction itself?
After a bit more investigation I found out this in the documentation:
Note: As of version 5.1.1, if feed.updated key doesn’t exist but feed.published does, the value of feed.published will be returned.
Thus, it seems that one could rely only on feed.updated, respectively feed.updated_parsed to do the work.
I am extending product.template, and I've added a field called uom_class. When I change this field when editing a product, I'd like to clear what is entered in the Many2One field called "Unit of Measure" (uom_id in product.template). I am doing this because I am also changing the domain for the uom_id, and the existing selection ("Units" by default) will probably not be in that domain.
I've tried the following, as suggested for earlier versions, but it did not work.
#api.onchange('uom_class')
def onchange_uom_class(self):
# [...] not shown: previously set new domain for uom_id
result['value'] ={'uom_id':False}
return result
I've seen other posts suggest I need to add assign it an empty product.uom record, but I have no idea how to do that. Any help would be greatly appreciated.
Well, I figured this one out.
I just declared
uom_id = False
For some reason, returning the domain works, but not returning the value. Either that, or I just have no idea what I'm doing and I'm returning the value wrong... which is entirely possible.
I have a simple function
import config
def send_message(mailgunkey=config.MAILGUNKEY):
"""
send an email
"""
It relies on a variable defined in my config.py file. I read the variables from local files on all my machines as I don't want to have my keys etc. in any repository. However, I recently got into the habit of using Sphinx. When generating the html docs the expression config.MAILGUNKEY is getting evaluated and the actual key is revealed in the html file. Is there an option to stop this kind of undesired action?
Consider using this approach:
import config
def send_message(mailgunkey=None):
"""
send an email
"""
if mailgunkey is None:
mailgunkey = config.MAILGUNKEY
In general, this approach gives you some important advantages:
lets your users pass None as the default;
allows changes to config.MAILGUNKEY even if your module has already been imported;
solves the problem of mutable default arguments (not your case, but still it's something to be aware of).
The second point is, in my opinion, something very important, as I would be very surprised to see that changes to a configuration variable at runtime have no effects.
Another option would be to mock the module that has your secrets.
This avoids needing to change your code to generate documentation.
Assuming you are using autodoc; add the below to your conf.py:
autodoc_mock_imports = ["config","secrets",]
https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html?highlight=autodoc_mock_imports%20#confval-autodoc_mock_imports
The autodoc_preserve_defaults configuration option was added in Sphinx 4.0.
The problem is solved by setting this option to True in conf.py. Default argument values of functions will not be evaluated and shown in the generated output.
I'm pretty new to python, and currently playing with the zeroconf library.
when I try to register a service on the network, I'm seeing this in the function definition:
def register_service(self, info, ttl=_DNS_TTL):
"""Registers service information to the network with a default TTL
of 60 seconds. Zeroconf will then respond to requests for
information for that service. The name of the service may be
changed if needed to make it unique on the network."""
self.check_service(info)
self.services[info.name.lower()] = info
if info.type in self.servicetypes:
self.servicetypes[info.type] += 1
else:
self.servicetypes[info.type] = 1
now = current_time_millis()
next_time = now
i = 0
while i < 3:
if now < next_time:
self.wait(next_time - now)
now = current_time_millis()
continue
out = DNSOutgoing(_FLAGS_QR_RESPONSE | _FLAGS_AA)
out.add_answer_at_time(DNSPointer(info.type, _TYPE_PTR,
_CLASS_IN, ttl, info.name), 0)
out.add_answer_at_time(DNSService(info.name, _TYPE_SRV,
_CLASS_IN, ttl, info.priority, info.weight, info.port,
info.server), 0)
out.add_answer_at_time(DNSText(info.name, _TYPE_TXT, _CLASS_IN,
ttl, info.text), 0)
if info.address:
out.add_answer_at_time(DNSAddress(info.server, _TYPE_A,
_CLASS_IN, ttl, info.address), 0)
self.send(out)
i += 1
next_time += _REGISTER_TIME
Anyone know what type info is meant to be?
EDIT
Thanks for providing the answer that it's a ServiceInfo class. Besides the fact that the docstring provides this answer when one goes searching for it. I'm still unclear on:
the process expert python programmers follow when encountering this sort of situation - what steps to take to find the data type for info say when docstring wasn't available?
how does python interpreter know info is of ServiceInfo class when we don't specify the class type as part of the input param for register_service? How does it know info.type is a valid property, and say info.my_property isn't?
It is an instance of ServiceInfo class.
It can be deduced from reading the code and docstrings. register_service invokes check_service function which, I quote, "checks the network for a unique service name, modifying the ServiceInfo passed in if it is not unique".
It looks like it should be a ServiceInfo. Found in the examples of the repository:
https://github.com/jstasiak/python-zeroconf/blob/master/examples/registration.py
Edit
I'm not really sure what to say besides "any way I have to". In practice I can't really remember a time when the contract of the interface wasn't made perfectly clear, because that's just part of using Python. Documentation is more a requirement for this reason.
The short answer is, "it doesn't". Python uses the concept of "duck typing" in which any object that supports the necessary operations of the contract is valid. You could have given it any value that has all the properties the code uses and it wouldn't know the difference. So, per part 1, worst case you just have to trace every use of the object back as far as it is passed around and provide an object that meets all the requirements, and if you miss a piece, you'll get a runtime error for any code path that uses it.
My preference is for static typing as well. Largely I think documentation and unit tests just become "harder requirements" when working with dynamic typing since the compiler can't do any of that work for you.