neogeographica / quakesounds Goto Github PK

2to3 only complains about __main__.py, and even there almost exclusively about how strings are formatted in the print statements. The only other change seems to be "input" instead of "raw input".

Could munge it according to the target platform (for win and mac builds). Doesn't seem to affect functionality, but I'm sure it would make some text editors happier.

More "passthru" than the current one. Just a literal data dump.

Maybe have a special "last stage only" option like "%write_to% filename", and treat that specially when building chain. Read stdout from previous stage and write to named file.

Right now it is just true or false, but it seems like we really have at least three possibly desirable behaviors for handling a sound_name value:

• Send it to the converter command without trying to do any directory creation.
• Interpret it as a path in the style of the current OS, and create subdirectories as necessary before sending it to the converter command.
• Interpret forward slashes as directories regardless of what the current OS thinks; transform the sound_name into an OS-appropriate path, then make directories as necessary, then send it to the converter.

The last one may be the appropriate default because that's what would be useful if running without explicit name maps and without dir-stripping the default names.

Not sure how best to represent this as some optional config setting(s) with sensible default(s).

There may be two different settings going on there:

• Whether to change forward slashes into OS-appropriate directory separators.
• Whether to try to make directories before the converter runs.

Currently the converter func assumes that the mapped sound name is a path, and it creates any directories in that path (as necessary). Probably a good assumption, but there are possible usecases that wouldn't necessarily treat the map lookup value as the actual pathname of a file to write... in those cases it would be nice to be able to turn off the directory-creating behavior.

Currently I just use the original basename. An alternate behavior that could be desired is the nop_converter behavior from expak (create subdirectories for path segments).

A couple of things I could do if I passed more data around:

TooManySubstitutions could contain info about the sequence of values that were iterated through before hitting the max iter depth. (It should also take the iteration # as an initializer input, rather than using the MAX_SUBSTITUTION_DEPTH constant).

BadSetting could contain info about whether the setting was something directly looked up by the quakesounds code (a "required" setting) or as a result of evaluating the value of some other setting. In the latter case it would also be nice to have info about what that other setting is -- although currently I lose that info in cases where the "prep" and "finalize" stages are separated, I could instead carry it around by bundling it into some sort of intermediate object type that is passed between prep and finalize (rather than just passing the value string).

3.4 final release is scheduled for March I think.

Hopefully qs will work out-of-the-box, even with the current bundled expak and pkg_resources.

The context key in the setting finalization in the valid_command_stage and converter functions should probably be the raw_converter_val value, if we're in the smart-eval case. Not a big deal but it would make the error messages slightly nicer if the selected converter command is goofed up.

FWIW: http://legacy.python.org/dev/peps/pep-0441/

This has been deferred out of Python 3.4.

If/when that is implemented, it would be nice to take advantage of that in some way, although making a specific version of the application for a different Python version would be icky.

(Also a good reminder in there about precompiling stuff.)

Just use some placeholder sound_name.

Advantages of doing it outside is that it would only be done once, and failure terminate the program (unlike exceptions inside converter functions).

...I think

I.e. make the path tokens/values part of the "special" table & get rid of eval_prep_paths.

This is a little more compute-intensive since it means it is done for every converter invocation. But in practice this doesn't matter.

The upsides are also minor, but probably outweight that downside:

• If a value from one of the path tokens happens to itself contain one of the special tokens (like "%comma%") then I won't mangle the path. In practice I doubt it would ever hit that bug, but I might as well do the right thing.
• Don't have to construct & use special_token_re, since that was only used to avoid complaining about token-like strings introduced from eval_prep_paths.
• Fewer & simpler config.Settings functions, by a small amount.

Current ones are just a rough guess.

... for whitespace characters (space at least), to help circumvent the whitespace-stripping if necessary.

The behavior with all optional settings omitted should be some sort of baseline. This may require "flipping the sense" of some optional settings.

The two that I'm mostly pondering about here are sound_name_as_path and default_sound_name_includes_dirs.

default_sound_name_includes_dirs should probably be True by default, which means we would want to flip it to be something like default_sound_name_strips_dirs so it can be False by default.

As for sound_name_as_path, it should probably be True by default also, except that maybe it shouldn't even be a boolean at all... going to file a separate issue for that.

Config file is way too busy/chatty now.