I would like to write my own isopen function and therefore not import Base.isopen. I have thought of two ways to do this: module MyModule function isopen end # Lots of code... include("file_that_defines_isopen.jl") end and baremodule MyModule import Base: Base, include, @__MODULE__, foreach, fi…

Thank you, I was more or less aware of this simple solution, but the problem is that it is vulnerable to certain relatively innocent code changing the meaning of code later on (e.g. if the “lots of code” includes a file that imports Base.isopen), so I wanted to do something that would help protect a…

I finally got it to work with the following code: baremodule MyModule import Base: Base, @eval, @__MODULE__, foreach, filter, names, ∉ eval(x) = Core.eval(@__MODULE__, x) include(x) = Base.include(@__MODULE__, x) foreach(filter(∉([:isopen]), names(Base))) do sym @eval import Base: $(sym) end …

I think it would be better to utilize multiple dispatch, i.e. to define your own type and define your own version of isopen for it.

In my case, I feel that this would be punning. The docstring for isopen seems to be intended for streams and things like that. In my case, I want to use it for querying if a market was open at a specific time. I feel that these two uses are so different that I do not wish to just make another method…

Then maybe it is better to use a much explicit name to avoid any confusion, such as ismarketopen.

I think it’s fairly common to just have your function public but not exported, so that isopen is for streams and MyPackage.isopen is for your type.

Of the two approaches in the original post, the first seems much more idiomatic to me and also much safer. What was the issue with the first approach? A huge hazard of importing all the methods in Base is that any function you define that happens to coincide with an imported Base function (in this …

It is difficult to describe why I don’t like the first solution so much, one thing is that it does things in the wrong order, importing, exporting and using should be done before defining functions, another thing is that I feel that I am abusing “defining function code” as a way to protect against i…

An improvement to your second method is to using Base: <thing> instead of import. The relevant difference being that defining a method for <thing> will not extend the Base method but will instead throw an error demanding that you use the qualified Base.<thing> to show you mean it. This should avoid …

From a technical perspective, you don’t need to worry about making sure that isopen is locally defined before you write it in a function. You just don’t want to call any of those functions (or directly evaluate isopen(...) itself) before that point. That’s general good practice for a module anyway…

[image] GHTaarn: eval(x) = Core.eval(@__MODULE__, x) include(x) = include(@__MODULE__, x) FYI on Julia v1.12 and up, after PR Use a curried helper for module-local eval/include by Keno · Pull Request #55949 · JuliaLang/julia · GitHub , this is not how a Module’s eval and include are usually de…

How to not import Base.isopen

General Usage

GHTaarn May 18, 2025, 6:04pm 13

Thank you. I made an error in that post and corrected it in my next post. I just got it from the manual at Modules · The Julia Language , so it should work for 1.11 and be backwards compatible.

1 Like

Topic		Replies	Views
Trying not to overload Base.open General Usage	4	699	April 12, 2020
Using isdefined to check where a function is defined General Usage cxx	15	1844	April 14, 2020
Possibility of `local import` statements in future? Internals & Design scope	63	4105	May 2, 2018
Overloading base operator from module General Usage question	7	8421	November 29, 2016
Definition of unary operator inside a module, removes the `Base` definition New to Julia question	3	1291	September 4, 2019

How to not import Base.isopen

Related topics