`from spm import *` hides `range`

[balbasty]

The bultin python range gets hidden when importing spm using from spm import *, as suggested in the doc.

Thie is because of spm.__external.__fieldtrip.__external.__stats.range

In general, it's become bad practice to import * in python. I wonder if we should recomment people do import spm instead?

[balbasty]

@Y-Bezs faced the same issue, and I think it's going to be a common one.

I am in favour of not advising people to use from spm import * in the doc.

cc @johmedr

[Y-Bezs]

I agree with @balbasty. I think "import spm" as mentioned before is way to go then?

[johmedr]

The problem is that range should be a reserved keyword.
Here the problem is with range but if it was is or class, then the code would break. I would prefer focusing on fixing this issue instead, e.g. by renaming range to range_ (as I thought was already done).

The motivation for from spm import * is to avoid the pedantic notation:

import spm
spm.spm_first_step
spm.spm_second_step
spm.spm_...

It's a lot of spm to write, and ultimately users should be allowed to choose what they prefer --- but I think we should push for enabling a low effort Matlab-to-Python translation for users that want that. What do you think?

[johmedr]

Python builtins are already accounted for here. The problem is that the file name is not changed accordingly. I will update this.

[johmedr]

In general, it's become bad practice to import * in python. I wonder if we should recomment people do import spm instead?

Just to bump onto this, my initial preference was to wrap all functions and drop the spm_ prefix, to allow:

import spm
spm.figure('...')
spm.dcm_specify('...')

It allows imports to be more specific but necessitate to change the syntax. It also raises the question of creating submodules (i.e., should we have spm.external.fieldtrip? How do we build this automatically?) and necessitated lot more work.

Another option that avoids from spm import * would be:

from spm import spm_figure, spm_dcm_specify
spm_figure(...)
spm_dcm_specify(...)

[Y-Bezs]

I think that "range" is such an automatic function, that users would want it to be just "range". Also, I guess it very much depends on how one wants to use spm_python - to actually code in python with some spm fuctionality (then I think range should be range) and the first option (rop the spm_ prefix) is perfect I think

[johmedr]

I think that "range" is such an automatic function, that users would want it to be just "range". Also, I guess it very much depends on how one wants to use spm_python - to actually code in python with some spm fuctionality (then I think range should be range) and the first option (rop the spm_ prefix) is perfect I think

Just to be more specific, I am not proposing to override range or any Python builtins, but rather to rename whatever range function that is defined in spm-python to something like range_ so that the built in range is kept clear.

[jbonaiuto]

I think that "range" is such an automatic function, that users would want it to be just "range". Also, I guess it very much depends on how one wants to use spm_python - to actually code in python with some spm fuctionality (then I think range should be range) and the first option (rop the spm_ prefix) is perfect I think

Just to be more specific, I am not proposing to override range or any Python builtins, but rather to rename whatever range function that is defined in spm-python to something like range_ so that the built in range is kept clear.

I think this is the way

[arthurmitchell96]

I think that "range" is such an automatic function, that users would want it to be just "range". Also, I guess it very much depends on how one wants to use spm_python - to actually code in python with some spm fuctionality (then I think range should be range) and the first option (rop the spm_ prefix) is perfect I think

Just to be more specific, I am not proposing to override range or any Python builtins, but rather to rename whatever range function that is defined in spm-python to something like range_ so that the built in range is kept clear.

I think there's two different types of user surrounding this and it depends on which we're trying to best satisfy. One is a user familiar with SPM coming from MATLAB to use python, and the other is a user that has not used SPM much or at all, but is a regular user of python. I would expect are more likely to have more of the latter catagory (although I may be wrong, you probably have a better intution of who intends to use this).

Thus, to make it easier for new SPM users (rather than new python users) in python we perhaps should keep terms from SPM seperate to other base python functions we may want to go a step further and specify something like 'spm_range' to make a clear distinction. In additon I think just usining import spm followed by spm.spm_... should be okay as python users will be used to this format and people coming over from MATLAB will still be familar with the function names. Users can also import funtions with from spm import spm_..., spm_... if they do not want to use spm. when calling functions or a repetedly using functions.

[johmedr]

Opened an issue in mpython.

[johmedr]

Closing the issue as the problem is resolved.

[johmedr]

Migrating this discussion to #28.