[Cython] array.array member renaming
Hi, I just wanted to say that this https://github.com/cython/cython/commit/a3ace265e68ad97c24ce2b52d99d45b60b26eda2#L1L73 renaming seems totally unnecessary as it makes any array code verbose and ugly. I often have to create extra local variables just to avoid endless something.data.as_ints repetition. What was the reason for ranaming? It would be really nice to reintroduce old names (_i, _d etc). Best regards, Nikita Nemkin ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] array.array member renaming
Nikita Nemkin, 04.06.2013 10:29: > I just wanted to say that this > https://github.com/cython/cython/commit/a3ace265e68ad97c24ce2b52d99d45b60b26eda2#L1L73 > > renaming seems totally unnecessary as it makes any array code > verbose and ugly. I often have to create extra local variables > just to avoid endless something.data.as_ints repetition. Are one-shot operations on arrays really so common for you that the explicit "unpacking" step matters for your code? > What was the reason for ranaming? It would be really nice to > reintroduce old names (_i, _d etc). IMHO, the explicit names read better and make it clear what happens. Also, I think the original idea was that most people shouldn't access the field directly and use memory views and the buffer interface instead, at least for user provided data. It might be a little different for arrays that are only used internally. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] array.array member renaming
On Tue, 04 Jun 2013 14:47:47 +0600, Stefan Behnel wrote: Nikita Nemkin, 04.06.2013 10:29: I just wanted to say that this https://github.com/cython/cython/commit/a3ace265e68ad97c24ce2b52d99d45b60b26eda2#L1L73 renaming seems totally unnecessary as it makes any array code verbose and ugly. I often have to create extra local variables just to avoid endless something.data.as_ints repetition. Are one-shot operations on arrays really so common for you that the explicit "unpacking" step matters for your code? I use array in most places where you would normally see bare pointer and malloc/PyMem_Malloc. Automatic memory management FTW. Many people would do the same if they knew about arrays and a special support for them that Cython provides. (Personally, I had discovered it by browsing standard include .pxd files) Array class members also have "self." prepended which does not help brevity. So, yeah, it matters. Sure I can live with overly verbose names, but there is certainly room for improvement. ATM I have 96 cases of ".data.as_XXX" in my codebase and that's after folding some of them using local variables (like "cdef int* segments = self.segments.data.as_ints"). What was the reason for ranaming? It would be really nice to reintroduce old names (_i, _d etc). IMHO, the explicit names read better and make it clear what happens. Indexing makes it clear enough that, well, indexing happens. Direct array access is sort of magic anyway. Here is an example of unnecessary verbosity: while width + piDx.data.as_ints[start] < maxWidth: width += piDx.data.as_ints[start] start += 1 Also, I think the original idea was that most people shouldn't access the field directly and use memory views and the buffer interface instead, at least for user provided data. It might be a little different for arrays that are only used internally. When using buffer interface, it really doesn't matter if user have passed an array or ndarray or whatever. Buffer interface covers everything, array-specific declarations are irrelevant. But when I know that the variable is an array, buffer declaration, acquisition and release code is dead weight (especially for class members which can't have buffer declaration attached to themselves, necessitating an extra local variable to declare a fast access view). Best regards, Nikita Nemkin ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] array.array member renaming
Nikita Nemkin, 04.06.2013 12:17: > On Tue, 04 Jun 2013 14:47:47 +0600, Stefan Behnel wrote: >> Nikita Nemkin, 04.06.2013 10:29: >>> I just wanted to say that this >>> https://github.com/cython/cython/commit/a3ace265e68ad97c24ce2b52d99d45b60b26eda2#L1L73 >>> >>> renaming seems totally unnecessary as it makes any array code >>> verbose and ugly. I often have to create extra local variables >>> just to avoid endless something.data.as_ints repetition. >> >> Are one-shot operations on arrays really so common for you that the >> explicit "unpacking" step matters for your code? > > I use array in most places where you would normally see bare pointer and > malloc/PyMem_Malloc. Automatic memory management FTW. > > Many people would do the same if they knew about arrays > and a special support for them that Cython provides. > (Personally, I had discovered it by browsing standard include .pxd files) > > Array class members also have "self." prepended which does not help brevity. > So, yeah, it matters. Sure I can live with overly verbose names, > but there is certainly room for improvement. > > ATM I have 96 cases of ".data.as_XXX" in my codebase and that's after > folding some of them using local variables > (like "cdef int* segments = self.segments.data.as_ints"). And the local assignment also resolves the pointer indirection for "self" here, which the C compiler can't really reason about otherwise. >>> What was the reason for ranaming? It would be really nice to >>> reintroduce old names (_i, _d etc). >> >> IMHO, the explicit names read better and make it clear what happens. > > Indexing makes it clear enough that, well, indexing happens. > Direct array access is sort of magic anyway. > Here is an example of unnecessary verbosity: > > while width + piDx.data.as_ints[start] < maxWidth: > width += piDx.data.as_ints[start] > start += 1 Agreed that it's more verbose than necessary, but my gut feeling is still: if it's worth shorting, it's worth assigning. If it's not worth assigning, it's likely not worth shortening either. IIRC, the reason why there's a redundant ".data." bit in there is a) because of C declaration issues and b) because we wanted to keep the namespace impact on the Python array object interface as low as possible. >> Also, I think the original idea was that most people shouldn't access the >> field directly and use memory views and the buffer interface instead, at >> least for user provided data. It might be a little different for arrays >> that are only used internally. > > When using buffer interface, it really doesn't matter if user have passed > an array or ndarray or whatever. Buffer interface covers everything, > array-specific declarations are irrelevant. > > But when I know that the variable is an array, buffer declaration, > acquisition and release code is dead weight (especially for class > members which can't have buffer declaration attached to themselves, > necessitating an extra local variable to declare a fast access view). That's what I meant with "only used locally". So, I do see your problem, but it's not obvious to me that it's worth doing something about it. Especially not something as broad as duplicating the direct access interface. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] array.array member renaming
On Tue, 04 Jun 2013 18:27:15 +0600, Stefan Behnel wrote: Nikita Nemkin, 04.06.2013 12:17: On Tue, 04 Jun 2013 14:47:47 +0600, Stefan Behnel wrote: Nikita Nemkin, 04.06.2013 10:29: I just wanted to say that this https://github.com/cython/cython/commit/a3ace265e68ad97c24ce2b52d99d45b60b26eda2#L1L73 renaming seems totally unnecessary as it makes any array code verbose and ugly. I often have to create extra local variables just to avoid endless something.data.as_ints repetition. Are one-shot operations on arrays really so common for you that the explicit "unpacking" step matters for your code? I use array in most places where you would normally see bare pointer and malloc/PyMem_Malloc. Automatic memory management FTW. Many people would do the same if they knew about arrays and a special support for them that Cython provides. (Personally, I had discovered it by browsing standard include .pxd files) Array class members also have "self." prepended which does not help brevity. So, yeah, it matters. Sure I can live with overly verbose names, but there is certainly room for improvement. ATM I have 96 cases of ".data.as_XXX" in my codebase and that's after folding some of them using local variables (like "cdef int* segments = self.segments.data.as_ints"). And the local assignment also resolves the pointer indirection for "self" here, which the C compiler can't really reason about otherwise. What was the reason for ranaming? It would be really nice to reintroduce old names (_i, _d etc). IMHO, the explicit names read better and make it clear what happens. Indexing makes it clear enough that, well, indexing happens. Direct array access is sort of magic anyway. Here is an example of unnecessary verbosity: while width + piDx.data.as_ints[start] < maxWidth: width += piDx.data.as_ints[start] start += 1 Agreed that it's more verbose than necessary, but my gut feeling is still: if it's worth shorting, it's worth assigning. If it's not worth assigning, it's likely not worth shortening either. Shortening is about readability. Extra CPU time to dereference self is not my concern. (I'm pretty sure L1 cache hides the cost.) So, I do see your problem, but it's not obvious to me that it's worth doing something about it. Especially not something as broad as duplicating the direct access interface. I guess I'll just copy array.pxd and modify it to suit my needs. (Long member names is not my only grievance.) Modified include path should do the trick. Best regards, Nikita Nemkin ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
