Message154171
| Author |
valhallasw |
| Recipients |
alexandre.vassalotti, pitrou, valhallasw |
| Date |
2012年02月25日.00:10:05 |
| SpamBayes Score |
1.5251412e-06 |
| Marked as misclassified |
No |
| Message-id |
<1330128606.95.0.0950021715057.issue14118@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
That makes sense. The goal was not so much cleaning up the module per se; rather, it was a result of trying to understand the general structure of _pickler.c specifically.
However, is there an intermediate level of 'modularization' you would propose? The idea is of course not to have 30 files open to make a small change, but rather have one or two reasonably small files open. My current approach was fine-grained on purpose - it's not that much work to recombine files.
I think it makes sense to split the PicklerObject into several parts:
* the Pickler object (initialization/type/etc, maybe functions split off)
* the actualy pickler implementation (dump/save/save_*) (but maybe in less files - see below)
* the PicklerMemoProxy
for the picker implementation - specifically the picklers directory - my approach was to have a 'mirrored' directory for PicklerObject and UnPicklerObject: the methods to pickle and unpickle will be in the same files in the two directories (i.e. picklers/unicode.c will pickle str, unpicklers/unicode.c will unpickle them). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年02月25日 00:10:07 | valhallasw | set | recipients:
+ valhallasw, pitrou, alexandre.vassalotti |
| 2012年02月25日 00:10:06 | valhallasw | set | messageid: <1330128606.95.0.0950021715057.issue14118@psf.upfronthosting.co.za> |
| 2012年02月25日 00:10:06 | valhallasw | link | issue14118 messages |
| 2012年02月25日 00:10:05 | valhallasw | create |
|