Is it possible to iterate through a ConfigSubsection()?

[IanSav]

Hi,

Is there a way to enumerate and then subsequently iterate through all the configuration items within a ConfigSubsection()?

Regards,
Ian.

[prl]

Look in the source,

[IanSav]

Hi Prl,

Look in the source,

I wouldn't have asked if I saw the answer.

Regards,
Ian.

[IanSav]

Hi Prl,

Okay, I think I have worked it out. Testing my idea now.

Regards,
Ian.

[IanSav]

Hi Prl,

I used the dict() function to give me the individual elements. I then used an eval() to reconstruct the setting and then use it in normal settings management functions.

This appears to work okay. Is this what you intended me to find?

Regards,
Ian.

[prl]

I have no idea what that code looks like,so I can't say.

[IanSav]

Hi Prl,

I will be checking the new code into the repository shortly. All will be available for review shortly.

Regards,
Ian.

[prl]

I've commented, but it's more stylistic than anything else.

[IanSav]

Hi Prl,

I like your simplification and will use it in the few similar cases the currently exist.

Do you have any other comments or reviews of the code? Hopefully my Python coding style is improving with each iteration.

Regards,
Ian.

[prl]

There are a few evals left that could be replaced by getattr()s, though, while using getattr() is way more efficient than eval(), which has to call the built-in compiler, the eval()s might be argued to be clearer:

Code: Select all

eval("config.plugins.skin.OverlayHD.%s.%s" % (label, mode))

vs

Code: Select all

getattr(getattr(config.plugins.skin.OverlayHD, label), mode)

It gets a bit messier with

Code: Select all

eval("config.plugins.skin.OverlayHD.%sTransparency.%s" % (label, mode))

vs

Code: Select all

getattr(getattr(config.plugins.skin.OverlayHD, label + "Transparency"), mode)

Your call.

Thinking about loops like

Code: Select all

		for x in config.plugins.skin.OverlayHD.dict():
			getattr(config.plugins.skin.OverlayHD, x).cancel()

again, they can probably be done more cleanly using:

Code: Select all

		for x in config.plugins.skin.OverlayHD.dict().itervalues():
			x.cancel()

This directly accesses the individual config items, uses a generator (iterator) rather than instantiating a list, and the config items will even be visited in the same order as in the old code

And nothing to do with the code itself, but I'd be using a branch-per-release structure in the repository, and merging into the master for each release. For example, as I did for v1.4 of Series2Folder (but not for earlier versions).

[IanSav]

Hi Prl,

I will look at these other optimisations ASAP.

As for the code check-ins. Given that I do all the development and testing on the T3 and my PC I usually have all the changes prepared and tested well before the code is checked in. I didn't think that creating a branch and then immediately merging it in offered any additional benefit. Am I missing something?

Regards,
Ian.

[prl]

...
As for the code check-ins. Given that I do all the development and testing on the T3 and my PC I usually have all the changes prepared and tested well before the code is checked in. I didn't think that creating a branch and then immediately merging it in offered any additional benefit. Am I missing something?
...

I find it useful to be able to put all the changes that are related to a new release into a branch so that the stages of creation of the new release can be separated into logical steps. Then the whole thing can go into the master in a merge. I'm also more comfortable in re-writing history (e.g. git rebase -i) in a branch than I would be in the master.

It's also much easier to abandon a branch than to roll back all the commits in the master if you decide that the direction you've taken in the branch is unproductive.

There are no hard rules about this, especially where there's only one contributor. As soon as more than one person starts working on a repository, either directly or via a fork, branches become much more clearly useful.

This is all orthogonal to when you test, which should be, as you say, before every commit.