On scoring imported functions

Question

There are lots of questions about whether to count the bytes in an import statement, etc. This question is not about that. Instead, this question is more inline with this question but I think it would be considered off topic/distinct.

Again, assume standard library imports are allowed at least, and that the byte count of the whole import is included in the score. The question arose here where many languages have libraries that provide a ready made solution. Now, is importing the solution enough, or does the required function need to be reassigned or evaluated?

When considering the consensus about builtin functions, it seems builtin solutions are acceptable in two situations:

1. The builtin is evaluated.
2. The builtin is assigned to a new name.

My gut feeling is that just importing a library is the same as doing neither of the above and claiming the builtin solves it for 0 bytes.

For instance, in Python, the NumPy library provides the function eye which returns the nxn identity matrix.

from numpy import*

seems like cheating, but by the wording of the other discussion, I think it could be argued that it's valid.

My gut feeling is that this should not be allowed, but by the wording of the discussion about builtins it looks like it should be. Look at the wording of these two articles assignments and imports:

Assignment statements are used to (re)bind names to values

• Assignment

The import statement ... searches for the named module, then it binds the results of that search to a name in the local scope.

So is

from library import func

equivalent to

func=builtin_func

and therefore acceptable as an answer? And if, technically, it is, should we put it on the list of banned loopholes?

Answer 1

Score is the length of the import plus the length of the function name

This seems to be the standard around here. If there exists a built-in function (we'll call it foo) that solves the task, and built-ins are not forbidden, then, for a challenge that accepts functions and not just full programs, the solution would be:

Python, 3 bytes

foo

Similarly, if foo resides in a module named bar, the solution would be:

Python, 20 bytes

from bar import*
foo

(technically it would be shorter to do import bar\nbar.foo, but that's beside the point)

Though this is specifically aimed at Python, it's easy enough to generalize to other languages. Consider a challenge where the goal is to output the number of characters in an ASCII string. A C solution would be:

C, 25 bytes

#include<string.h>
strlen

Answer 2

It depends. The question is whether the library is part of the language. If it is, merely specifying an import-clause is the most idiomatic solution and we should not penalize that. (Individual challenge authors may penalize it anyway but it’s their decision.)

If the imported library is a third-party plugin, however, i. e. not part of the programming language, you are outsourcing the implementation. Several loopholes forbidden by default try to prevent this.

It is therefore consistent that just importing a third-party symbol is not sufficient, but you will at least need to define your own symbol, too.

---

For instance, as far as I understand, the numpy library is a third-party library independently developed from the Python language. The existence of numpy is not guaranteed with any Python implementation. Hence

from numpy import *

is an incomplete implementation of the n×n identity matrix function. You will need to declare a user-defined function.

On the other hand the C programming language defines (since C99) that (unless an implementation defines the __STDC_NO_COMPLEX__ symbol) the function carg is available via the complex.h header. Therefore

#include <complex.h>

is a “complete” and in particular idiomatic implementation of the complex argument function.