# Bytes for changing a configuration file before running a program?

In this answer using Python's turtle module, I discovered that some default settings for the turtles are set in a configuration file called turtle.cfg, which is read at import time.

Can I change this as part of my program, and how would the changes be scored in bytes, if at all?

• Example: I could change a default color value from black to "".
• Closely related – AdmBorkBork Sep 9 '16 at 16:09
• Is there a default turtle.cfg file, or is it like .vimrc where you have to create your own? – James Sep 9 '16 at 16:13
• @DJMcMayhem There is a default one that comes with the distribution. – mbomb007 Sep 9 '16 at 16:14
• For some languages (esp interpreted), wouldn't this be the equivalent of modifying the standard libraries to change method/function names, etc? I would really hate to see us start down that rabbit hole. – Geobits Sep 9 '16 at 16:29
• @Geobits Yeah, I'm thinking that, too now. How about if I find a pre-existing distribution of Python with a specific config file? Can I just say to use that distribution? I've found that the defaults used on Trinket.io may not be the only defaults around. CPython and here both use the config I'd need. – mbomb007 Sep 9 '16 at 16:30
• That sounds reasonable, yes. Assuming it was pre-existing, it sounds like "golfed language" libraries. Not terribly interesting, but I don't think it breaks rules. – Geobits Sep 9 '16 at 16:31
• Also closely related – AdmBorkBork Sep 9 '16 at 16:35
• @Geobits Actually I was mixed up. I can't actually use the default, because it's a different property than I was thinking of. So I would have to change it. So I won't be using a different distribution for my answer linked in the question, since I can't actually golf any bytes off that way. – mbomb007 Sep 9 '16 at 16:37

## 1 Answer

On PPCG, languages are defined by their implementation. This includes any configuration files. Therefore, if you edit your local configuration files, you are essentially creating a new unpublished implementation of an existing language. Now, if you were to significantly edit your configuration files, and publish them somewhere, you have essentially created a golfing library, which is allowed (although generally disliked, but that's beside the point).

If we allow editing of configuration files, I see no reason to stop there. We can edit source code of the interpreter too! No matter what scoring method you use, it just seems to me like opening a huge can of worms. It paves the way for MetaConfigScript, makes scoring more confusing, bogs us down in even more rules, and makes testing significantly harder. So here is my proposal:

If your solution runs with any fresh install of the language you are using, your solution is valid. Otherwise, your answer is basically just a it works on my machine!.

If your solution requires one very specific install of the language you are using, this is perfectly fine, but please specify this in your answer.

I think this is a reasonable default because it keeps testing as simple as possible, and it fits with our rule of "languages are defined by their implementation". Presumably any language that might benefit from tweaking defaults would also have a way to edit that behavior inside of your solution, and however many bytes of boilerplate that takes is a reasonable byte handicap.

• What about, say, an option that is disabled by default but 98% of users enable it? – LegionMammal978 Sep 11 '16 at 11:53