Repository navigation
global function _add_one_to_index_C #47351
Description
| BPO | 3101 |
|---|---|
| Nosy | @loewis, @birkenfeld, @doko42, @pitrou |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/pitrou'
closed_at = <Date 2010-09-01.13:03:11.110>
created_at = <Date 2008-06-13.07:30:19.652>
labels = []
title = 'global function _add_one_to_index_C'
updated_at = <Date 2010-09-01.13:03:11.107>
user = 'https://github.com/loewis'bugs.python.org fields:
activity = <Date 2010-09-01.13:03:11.107>
actor = 'pitrou'
assignee = 'pitrou'
closed = True
closed_date = <Date 2010-09-01.13:03:11.110>
closer = 'pitrou'
components = []
creation = <Date 2008-06-13.07:30:19.652>
creator = 'loewis'
dependencies = []
files = []
hgrepos = []
issue_num = 3101
keywords = []
message_count = 11.0
messages = ['68133', '68495', '68499', '71738', '71879', '77353', '77363', '77368', '77373', '114623', '115294']
nosy_count = 6.0
nosy_names = ['loewis', 'georg.brandl', 'doko', 'teoliphant', 'pitrou', 'riq']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue3101'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']Metadata
Metadata
Assignees
Labels
No labels
Activity
loewis commentedon Jun 13, 2008
abstract.c defines two functions _add_one_to_C and _add_one_to_F. These
apparently must be global, as memoryobject.c references them. Therefore,
they should get a Py or _Py prefix.
A short comment for what these functions actually do would also be
appreciated.
riq commentedon Jun 21, 2008
This seems to be fixed in r62348
http://svn.python.org/view?rev=62348&view=rev
loewis commentedon Jun 21, 2008
Ok, so it's fixed for the trunk, but not Py3k. The trunk fix doesn't
port to 3k, since the functions are called inside memoryobject.c (so
making them static would break that module).
pitrou commentedon Aug 22, 2008
A sensible solution would be to put all the memoryview / buffer API
stuff in the same standalone file (e.g. memoryobject.c), rather than
having half of it dumped in abstract.c.
teoliphant commentedon Aug 24, 2008
I've added comments in the code to document these functions. I have no
opinion where they live except they should probably be available to
extensions modules.
These routines increment an N-length counter representing a position in
an N-dimensional array with wrap-around when the counter reaches the
size of the dimension. Thus, for a (2,3) array we have:
F-version
0,0
1,0
2,0
0,1
1,1
2,1
C-version
0,0
0,1
0,2
1,0
1,1
1,2
[-]global function _add_one_to_C[/-][+]global function _add_one_to_index_C[/+]loewis commentedon Dec 8, 2008
I think _add_one_to_index_C and _add_one_to_index_F should be renamed.
If they are meant to be called by non-core extension modules, their
names should start with Py_, else with _Py_.
pitrou commentedon Dec 8, 2008
I think they currently are private functions which happen to be used
accross two different C source files. So they should be renamed
_Py_something (or the situation should be fixed so that they can be made
static).
loewis commentedon Dec 8, 2008
But see msg71879
pitrou commentedon Dec 8, 2008
Well, then a proper API should be devised. Perhaps Travis can shed more
light on what he thinks would be useful.
birkenfeld commentedon Aug 22, 2010
Functions are still present and non-static in trunk.
pitrou commentedon Sep 1, 2010
I've added a "_Py" prefix in r84391, and also made the
shapeargument const. If numpy people want this to be an official public API, they'll have to contribute. Thanks.