Why does csv.field_size_limit(new_limit) returns old_limit

Ideas
1

Description

As it is now, the field_size_limit method from the csv module does the following, as per the documentation (emphasis mine):

Returns old limit. If limit is not given, no new limit is set and the old limit is returned

It seems to me this is a major discrepancy with the majority of such methods I’ve encountered, which usually return the current value (thus the “new” value, if it is a setter). (I am talking about my experiences with such methods “in the wild”, not specifically in this module).
Am I the only one mildly annoyed at this? Or, more probably, is there an explanation to this way of operating that I haven’t thought of?

More elements

This was initially posted as an issue, but @picnixz correctly redirected me here. On further consideration, this indeed seems a better platform to interact on this topic.
In addition to pointing me here, they also made the argument that in the case of a temporary change in field size limit, the current way of operating was shorter to write:

old = obj.set_value(new)
# do something with new
...
# restore
obj.set_value(old)

instead of:

old = obj.get_value()
obj.set_value(new)
# do something with new
...
# restore
obj.set_value(old)

Though it is technically true, it in itself does not seem to me a satisfactory justification. The way this operates really seems counter intuitive and removing one line of code in a specific instance doesn’t outweigh the counter intuitiveness in this instance (for me).

Main problem

I would have proposed to change this to match the expected behavior of this type of methods, but @tjreedy made the point that it wasn’t such a big issue, while necessitating a breaking change to be fixed.

Question

Am I the only one for who it is a strange way of doing this operation? Is there a pattern I have not encountered, or a reason to justify this I wouldn’t have seen?
I am aware this is minor and not really worthy of a breaking fix but I’d still like to have your opinions on this.

2

Of what use would the new value be if it were returned? It seems to me the only reasonable return values are None or the old value. And as pointed out, the old value has some use when temporarily changing the field size limit. So best to return the old value.

4 Likes
3

Returning the old value is, in my experience, a very common behaviour. There’s no point returning the new value, as the caller already knows what the new value is, so what else would you return?

In any case, as you say this isn’t going to change as it simply isn’t worth breaking code for this.

4 Likes
4

If there is only one function to set/get value, it is common that it returns the previous value. See for example os.umask(), _locale.setlocale(). It does not make sense to return the new value, because the caller already has it.

This pattern is not so common, because not always there is a neutral value that you can use to only request the current value without changing it (see os.umask()). If it is used, this is most likely for compatibility.

I do not think there is a reason to change this here.

2 Likes
5

So it seems it was a bad perception on my part, maybe it will come with more experience?
Thank you for your inputs!