Comments (11)
FWIW, when import ... as ...
syntax was introduced, I tried using ... as ...
expecting it to work as well, and was disappointed it isn't supported. Agree that the semantics are clear, as @LilithHafner proposes.
The same arguments as for import as
are suitable here: yes, using ...
+ const ...
is possible, but using as
is more natural. Especially given import as
already exists.
from julia.
I think this syntax is more intuitive and readable:
I disagree; using LongPackageName as LPN
feels like it should do what import LongPackageName as LPN
does today.
from julia.
It's not valid syntax:
julia> :(using Foo as Bar)
ERROR: ParseError:
# Error @ REPL[1]:1:8
:(using Foo as Bar)
# └─────────┘ ── `using` with `as` renaming requires a `:` and context module
Stacktrace:
[1] top-level scope
@ none:1
from julia.
Seems like a pretty niche usecase where you happily accept all export
ed names from using
the module but not the module name itself? What else does it offer over using Foo; const F = Foo
? The import
/using
logic is already pretty complicated and something new users are often confused by, perhaps it isn't worth adding complexity? In particular not if it is breaking?
from julia.
The point is not so much to exclude loading the module name itself, but to support the syntax at all. I think this syntax is more intuitive and readable:
using LongPackageName as LPN
using LongPackageName; const LongPackageName = LPN
I do not think that the ability to rename packages on using will confuse new users because this renaming syntax is already supported in all other locations in using/import. The use case of wanting to load a long package under a short alias is reasonable in my opinion and may help allow folks to use descriptive package names without loosing brevity in domain specific usage.
If we are agreed that we want the using LongPackageName as LPN
syntax, then we kinda have to make it not load LongPackageName
which, sadly, does add some complexity.
This can be implemented in a technically non-breaking way (though I think the current PR is already practically non-breaking), the tradeoff there is that to make it technically non-breaking requires a more complex mental model and/or a more complex object model.
from julia.
And is equivalent to
It seems that it should be equivalent to this, but there is a warning that seems unintended with attempting it:
julia> using Statistics: Statistics as Stat
julia> global Statistics
julia> using .Stat
WARNING: using Statistics.Statistics in module Main conflicts with an existing identifier.
from julia.
@vtjnash, am I correct in thinking that the using
syntax does not load names by explicitly enumerating the exported names of the loaded module but instead simply adds the name of the loaded module to the list of modules used by the parent, done here:
Line 636 in 5643c60
from julia.
Apparently the history of this warning is #4715, so this might specifically need to avoid the warning there when using the .Stat
module tries to bring it its own name (from the implicit export Statistics
)
from julia.
Declaring a global is also an observable property and I don't think it makes sense to declare a global named Statistics
on using Statistics as Stat
julia> Statistics
ERROR: UndefVarError: `Statistics` not defined in `Main`
Suggestion: check for spelling errors or missing imports.
julia> using Statistics: Statistics as Stat
julia> global Statistics
julia> using .Stat
WARNING: using Statistics.Statistics in module Main conflicts with an existing identifier.
julia> Statistics
ERROR: UndefVarError: `Statistics` not defined in `Main`
Suggestion: add an appropriate import or assignment. This global was declared but not assigned.
Hint: a global variable of this name also exists in Statistics.
julia> names(Main)
8-element Vector{Symbol}:
:Base
:Core
:InteractiveUtils
:Main
:Statistics
from julia.
Just to clarify, what's the current behavior of using Foo as Bar
?
from julia.
The Julia object model does have the notion of "using all the exported symbols except for one". As I see it we have a few options if we want to implement this
- Create an explicit binding for the module name when running
using Mod
,using Mod as M
, orusing Mod.SubMod
(this is already sometimes the case) and stop implicitly exporting the module name itself (technically breaking but likely a minor change) - 1 but also add a special case to the
Base.isexported
function to make it's behavior stay the same (note: Base.isexported is not part of the public API of Julia <= 1.10) - When running
using Mod as M
, define a binding that shadowsMod
- Make the object model more expressive
I'm currently investigating option 1. Open to alternative suggestions.
from julia.
Related Issues (20)
- reverse(A, dims=...) doesn't work for Diagonal, Tridiagonal, etcetera HOT 5
- `logabsdet` has a weird name HOT 4
- Support arbitrary multiple-cluster sorting in `ordschur` HOT 1
- Support broadcasting `I` HOT 6
- Add error hint for `setindex(::Type, ...) HOT 2
- Outdated documentation for type conversions HOT 4
- `Core.EnterNode` is showing up in Method.roots list HOT 1
- Remove outdated wrong information about Module's qualified name access. HOT 1
- delete unsupported Filesystem.JL_O_ flags HOT 1
- REPL suggestion with up-arrow in Pkg/help mode returns to last command in normal mode HOT 4
- Shortcut to test a local package HOT 5
- [release 1.10] effects wrong for function that throws MethodError HOT 8
- Julia doesn't add lifetime intrinsics to it's allocas, specifically the sret ones. Wasting stack space
- `@time` doesn't work correctly on some macros HOT 1
- On master, REPL fails to load due to StyledStrings HOT 1
- Current master always re-precompiles `REPLExt` when entering `pkg>`-mode in a clean environment HOT 12
- Operators without precedence HOT 4
- Tasks with the same workloads sometimes finish in much longer time than others HOT 12
- Assigning a View to a field in a struct typed as an Array unexpectedly copies values HOT 1
- Stack traces for errors inside generated function generators are terrible
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from julia.