Making safe file names

[Roy Smith]

In article <mailman.1465.1368056269.3114.python-list at python.org>,
 Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

> On Tue, 07 May 2013 18:10:25 -0500, Andrew Berg
> <bahamutzero8825 at gmail.com> declaimed the following in
> gmane.comp.python.general:
> 
> > None of these would work because I would have no idea which file stores 
> > data for which artist without writing code to figure it out. If I
> > were to end up writing a bug that messed up a few of my cache files and 
> > noticed it with a specific artist (e.g., doing a "now playing" and
> > seeing the wrong tags), I would either have to manually match up the hash 
> > or base64 encoding in order to delete just that file so that it
> > gets regenerated or nuke and regenerate my entire cache.
> >
> 	And now you've seen why music players don't show the user the
> physical file name, but maintain a database mapping the internal data
> (name, artist, track#, album, etc.) to whatever mangled name was needed
> to satisfy the file system.

Yup.  At Songza, we deal with this crap every day.  It usually bites us 
the worst when trying to do keyword searches.  When somebody types in 
"Blue Oyster Cult", they really mean "Blue Oyster Cult", and our search 
results need to reflect that.  Likewise for Ke$ha, Beyonce, and I don't 
even want to think about the artist formerly known as an unpronounceable 
glyph.

Pro-tip, guys.  If you want to form a band, and expect people to be able 
to find your stuff in a search engine some day, don't play cute with 
your name.