Update. Some experience later, I'd strongly encourage the use of __all__, and discourage the initializer-function idea. There is a lot of tooling, that will be confused by it.

1. Initializer function

An alternative might be wrapping definitions into an initializer function.

## --- exporttest.py ---
def _init():
    import os                       # effectively hidden

    global get_ext                  # effectively exports it
    def get_ext(filename):
        return _pointless_subfunc(filename)

                                      # underscore optional, but good 
    def _pointless_subfunc(filename): # for the sake of documentation
        return os.path.splitext(filename)[1]

    if __name__ == '__main__':      # for interactive debugging (or doctest)  
        globals().update(locals())  # we want all definitions accessible
        import doctest
        doctest.testmod()
        
_init()

print('is ``get_ext`` accessible?           ', 'get_ext' in globals())
print('is ``_pointless_subfunc`` accessible?', '_pointless_subfunc' in globals())
print('is ``os`` accessible?                ', 'os' in globals())

For comparison:

>>> python3 -m exporttest
is ``get_ext`` accessible?            True
is ``_pointless_subfunc`` accessible? True
is ``os`` accessible?                 True

>>> python3 -c "import exporttest"
is ``get_ext`` accessible?            True
is ``_pointless_subfunc`` accessible? False
is ``os`` accessible?                 False

1.1. Advantages

• Actual hiding of the imports.
• More convenient for interactive code-exploration, as dir(exporttest) is clutter-free.

1.2. Disadvantages

• Sadly, unlike the import MODULE as _MODULE pattern, it doesn't play nicely with pylint.

  C:  4, 4: Invalid constant name "get_ext" (invalid-name)
  W:  4, 4: Using global for 'get_ext' but no assignment is done (global-variable-not-assigned)
  W:  5, 4: Unused variable 'get_ext' (unused-variable)
  

• It also doesn't play nicely with IDE intellisense features.

2. Embrace __all__

Upon further reading, I've found that the pythonic way to do it is to rely on __all__. It controls not only what is exported on from MODULE import *, but also what shows up in help(MODULE), and according to the "We are all adults here" mantra, it is the users own fault if he uses anything not documented as public.

2.1. Advantages

Tooling has best support for this approach (e.g. through editor support for autoimports through the importmagic library).

2.2. Disadvantages

Personally, I find that whole "we are all adults" mantra quite naive; When working under time pressure with no chance to fully understand a code-base before delivering a change, we can do with any help we can get to prevent "shot your own foot" scenarios. Plus, even many popular packages don't really follow best practices like providing useful interactive docstrings, or defining __all__. But it is the pythonic way.

I know this is a 4-year-old question, but I found myself having to deal with this same problem recently and came up with a solution that seems to work.

This is the file structure we'll be using:

package/
    __init__.py
    import_me.py
    import_me_no_re_export.py

The contents of package/import_me.py (used only for comparison) are as per the question:

import re
import sys

def hello():
    pass

Those of package/import_me_no_re_export.py are:

def _():
    global hello

    import re
    import sys

    def hello():
        pass

_()
del _

The following python CLI session (Python 3.8.5) shows the results of this approach:

>>> import package.import_me
>>> import package.import_me_no_re_export
>>> dir(package.import_me)
['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'hello', 're', 'sys']
>>> dir(package.import_me_no_re_export)
['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'hello']
>>> set(dir(package.import_me)) - set(dir(package.import_me_no_re_export))
{'sys', 're'}

As you can see, the import_me_no_re_export module does not re-export the sys and re modules.

Pros:

• It seems to work like a charm, no side effects whatsoever.
• Both mypy and flake8 seem to like this approach alright.

Cons:

• At least Visual Studio Code seems to not like it too much (IntelliSense will simply not work and only suggest the deleted _ function for a module so altered).
• You need to sacrifice an indentation level.
• Boilerplate

As other answers pointed out, embracing __all__ is probably the best bet, although it does not in fact address the issue; other than that, probably deal with the fact that these things are bound to happen.

The solution might be to rethink your files structure and create a submodule. Use a file such as __init__.py to expose the variables that you want.

package/
    __init__.py
    import_me/
         __init__.py
         code.py

'''
import_me/code.py
'''

# imports that you do not want to expose
import re
import sys


def hello():
    re.doSomething()
    sys.doSomething()
    print('hello')

'''
import_me/__init__.py
'''

from code import hello