 |
 |
On Thu, Mar 8, 2012 at 3:53 PM, Mark A. Matienzo <[log in to unmask]> wrote: > On Thu, Mar 8, 2012 at 3:32 PM, Godmar Back <[log in to unmask]> wrote: > > > One side comment here; while smart handling/automatic detection of > > encodings would be a nice feature to have, it would help if pymarc could > > operate in an 'agnostic', or 'raw' mode where it would simply preserve > the > > encoding that's there after a record has been read when writing the > record. > > > > [ Right now, pymarc does not have such a mode - if leader[9] == 'a', the > > data is unconditionally utf8 encoded on output as per mbklein's patch. ] > > Please feel free to write a patch and submit a pull request if you're > able to contribute code to do this. > > Mark, while I would be able to contribute code to pymarc, I probably won't (unless my collaborators' needs in respect to pymarc become urgent.) I've been contributing to open source for over 15 years, my first major contribution having been the ext2fs filesystem code in the FreeBSD kernel ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html ) and I'm a bit confused by how the spirit in the community has changed. The phrase "patches welcome" used to be reserved for when there was a feature request somebody wanted, but you (the owner/maintainer of the software) didn't have the time or considered the problem not important. Back then, it used to be that all suggestions were welcome. For instance, if a user pointed out a typo, you'd fix it. Similarly, if a user or fellow developer pointed out a potential design flaw, you'd understand that you don't ask for patches, but that you go back to the drawing board and think about your software's design. In pymarc's case, what's needed is not more code (it already has a moderately confusing set of almost a dozen switches for reading/writing), but a requirement analysis where you think about use cases you want to support. For instance, whether you want to support reading/writing real world records in batches (without touching them) even if they have flaws or not. And/Or whether you insist on interpreting a record's data in terms of encoding, always. That's something occasional contributors cannot do, it requires work by the core team, in discussion with frequent users. (I would have liked to take this discussion to a pymarc-users list, but didn't find any.) - Godmar