automatically search Base in using and import?

[StefanKarpinski]

It seems a bit weird that you can do using SomePackage and it will just work yet to use something that's defined in Base you need to write Base.Test or Base.Markdown. Now that we can put non-strings into LOAD_PATH it probably makes sense that if you stick a module in LOAD_PATH you should automatically look at its submodules. Then one could do push!(LOAD_PATH, Base) and be allowed to do using Test. Of course, that's still a little weird since for all other kinds of module we're asking for the module by its "full name" – although of course, once a module is loaded into Main that can sort of be considered its full path.

[tkelman]

That could cause issues with anywhere a package name collides with a base module name, as with Iterators.

[StefanKarpinski]

Indeed, but arguably it's not a good idea for a package to have the same name as a submodule of Base – Iterators is precisely a case in point.

[iamed2]

The plan when Base.Iterators was introduced was to reexport everything from Base.Iterators in Iterators.jl. Currently that has not happened because of incompatibilities in Base methods and Iterators.jl methods (e.g. collect(product((1, 2), (1, 2)))).

With 0.4 and Dates.jl, I would use using .Dates to get the Base version.

[JeffBezanson]

I think the best way to achieve this is the "default packages" idea. Any submodule of Base that's useful to import should be moved out to a separate toplevel package, so it's not inside Base anymore.

[tkelman]

Agreed, but that makes the name conflict problem even worse doesn't it?

[JeffBezanson]

I see that as the same as package name conflicts in general. Why can't there be two packages called Test? If there's going to be only one package namespace, and we want an un-qualified Iterators default package, but there's also another Iterators package, then one of them has to go, plain and simple. We also have the option of leaving things in Base, so that their name stays as Base.Foo. In the case of something like Iterators, that might make sense.

[JeffreySarnoff]

I just started using import Base.Submodule: some-of and importall ... with Operators, Math, LinAlg &tc.

(initial impression, an aside)
For developer support, Base submodules one step finer would help. As example: the operations and functions that are applied with the integer and floating point built-in types would be more helpful in submodules collecting. Letting <Num> be {Int, Float} or else their amalgam:

• providings: NumPrimitives, NumPredicates, NumOrderings, NumOperators,
• calculatings: ArithmeticOps, ArithmeticFuncs, ElementaryFuncs, SpecialFuncs

(maybe this)
If using Base.Operators and importall Base.Operators becomes using Operators and importall Operators, and my package has a submodule Operators, then I should write using MyPackage.Operators and importall MyPkg.Operators. Base submodules are used more often by more persons than an individual package's submodules (and that referential priv should be grantable by y'all e.g. if their packages have submodules: JuliaFin, JuliaStats, JuliaPlots). It is utilitarian to see at once that some-this is of Communal and this-some is of Community.

(this may be)
Should their be no deeper value (like, doing so allows precompilation to put its carts before its horses in a way that is available/accessed in the company of such doing and done more clumpulatedly otherwise), then the value of less is more.

#30#

[mschauer]

Shouldn't it be

using PackageRepository.Package
using Base.Package

with

using Package

trying both Metadata and Base and reporting

julia>using Iterators
ERROR: A package named `Iterators` is contained both in [...] Use the qualified name 
`Metadata.Iterators` or `Base.Iterator` [...]

?

[JeffBezanson]

I propose closing this. I don't think we want using X to look at exported names of Base (or other modules). That would allow changes to package contents to create new top-level package name conflicts, which seems bad.

[StefanKarpinski]

💯 Since we're moving most packages that were previously inside of Base into stdlib this is mostly moot. That said, as a corollary, almost anything where doing using Base.Foo made sense should be considered for excision into a standard package instead of part of Base.