On 17 Nov, 09:40, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > Paul Moore <[EMAIL PROTECTED]> writes: > > > OK, but that allocates the initial buffer, which I will then > > throw away. > > Why don't you use a constructor argument that allows specifying > the initial buffer size?
That's an option, but I don't want to expose that argument to Python code (as it would allow the user to create an object which wasn't fully initialised - I only use the extra argument myself when there's additional initialisation to do in C). > > In practice, this isn't a significant issue (the overhead of > > one allocation and one deallocation isn't going to wreck > > things!) but it feels somehow clumsy. However, I can't see an > > obvious way to refactor the code so that building the object > > and assigning the buffer are separate - so that I can write a > > function like Pattern_init, which allocates a differently > > sized buffer (well, I could, but if I did, I'd have no way of > > using it that respects subclassing... > > Another way would be to avoid allocating the buffer at all > until it is actually needed. The problem then is that I have to include null checks in a lot of code that can otherwise assume that objects passed in have a valid buffer. Thinking it through, I think the extra dealloc/alloc and minor code duplication probably isn't enough of an issue to compromise safety over. Thanks, Paul. -- http://mail.python.org/mailman/listinfo/python-list
