Julia: 모듈 및 가져오기 앨리어싱

나는 당신이 다음을 할 수 있다는 것을 몇 분 전에 깨달았습니다.

import ArgParse
ap = ArgParse

ap.add_argument(...)

나는 여전히 "import as" 표기법을 구문 설탕으로 사용하는 것이 좋을 것이라고 생각합니다.

내가 여기 있고 그것에 대해 생각하는 동안 @JeffreySarnoff 의 포럼 게시물 에서 언급했듯이 동일한 가져오기 라인에서 여러 특정 기능을 가져오는 방법이 있으면 좋을 것입니다. 문제를 검색한 결과 아직 그러한 요청이 표시되지 않았습니다.

같은 것

# from the forum post
import Module.(export1,export2,export3)
# or
import Module.[export1,export2,export3]
# or maybe
import Module.{export1,export2,export3}

이 문제와 다른 문제이지만 관련이 있습니다. 내가해야합니까

1. 이 문제를 업데이트하거나
2. 새로운 문제를 만들다

(이러한 기능의 유용성은 논란의 여지가 없다고 가정하고...)

편집 : 이것은 이제 import Module: export1, export2, export3 에서 작동합니다.

나는 그것이 또한 예를 들어 지원해야한다고 생각합니다

import ArgParse.add_argument as addarg

가져올 때 모듈 멤버의 이름을 바꿀 수 있습니다.

이름이 바뀐 함수 이름이 디스패치에 어떻게 참여하는지 궁금하십니까?

기본적으로 const foo = Base.bar 에 해당하는 별칭처럼 작동해야 합니다.

기본적으로 const foo =와 동일한 별칭처럼 작동해야 합니다.
베이스.바.

함수를 가져올 때 사용하거나 재정의할 계획입니다. 주어진
위와 같이

Base.bar를 foo로 가져오기

확실히 foo를 Base.bar로 사용할 수 있지만 foo를 정의하는 것도 재정의됩니다.
베이스바? 그래야 할까요?

이것은 오래된 문제이지만 우리가 0.2에 접근함에 따라 이것을 다시 검토해야 할 때라고 생각합니다.

코드를 작성할 때 항상 import NumericExtensions as ne 를 작성하고 싶었고 이것이 지원되지 않는다는 사실을 스스로에게 상기시켰습니다.

구현하기가 그렇게 어렵지도 않고, 제 생각에는 이게 쓰는 것보다 훨씬 좋은 것 같아요.

import NumericExtensions
const ne = NumericExtensions

+1

+1

이것은 여전히 ​​관련이 있습니까? 저는 개인적으로 모듈 앨리어싱을 위해 추가 foo = Foo 를 하는 것에 신경 쓰지 않지만, 슈거 ​​앨리어싱을 지원하기 위한 합의가 있었던 것 같습니다. 충분히 강하게 느끼는 사람은 스스로 PR을 해야 할 수도 있습니다.
그러나 x as y 는 #1470에서 언급된 convert(y,x) 구문에 대한 가장 강력한 경쟁자 중 하나였습니다. 이 둘을 명확히 구분하는 것은 그리 어렵지 않을 것 같지만 참고만 하세요.

이 기능의 가치는 원래 이름을 가져오는 것을 피할 수 있다는 것입니다.

+1
이 기능이 있으면 좋을 것입니다.

+1

새 키워드 as 를 도입하는 대신 => 연산자를 사용하는 것은 어떻습니까?

import Tlahuixcalpantecuhtli => Venus: xxxxxxxxx => x9, yyyyyyyy => y8, zzz

이렇게 하면 동일한 구문에서 모듈 및 변수의 하위 집합의 별칭을 수직으로 허용할 수 있습니다.

잘 모르겠어, 그건 내가 보기엔 정말 못생겼어.

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

그게 더 나아? 가독성이 훨씬 떨어지는 것 같아요.

저는 개인적으로 as 이 => 보다 더 자명하다고 생각합니다. 이는 여러 가지를 의미할 수 있을 것 같습니다.

전체 공개: 파이썬 편향.

나는 as => 구문이 더 좋습니다.

나는 내쉬 균형에 갇힌 자전거 보관소를 좋아합니다.

모듈의 내부 기호를 다시 바인딩하는 이유는 무엇입니까? 당신이 정말로 그렇게해서는 안되기 때문에 추한 것입니다.

나는 Haskell의 import 문법을 좋아 한다. 나는 Python의 네임스페이스가 Julia의 모듈보다 더 세분화되어 있다고 생각합니다. Julia의 모듈은 Haskell의 모듈에 비해 정신이 더 강하므로 영감을 얻기 위해 그곳에서 찾아야 할 것입니다.

@ssfrr 에 동의합니다. as 키워드는 훨씬 더 자명하며 Python/Haskell 사용자에게도 친숙합니다. @StefanKarpinski 문제를 가독성으로 해결하려면 파이썬과 유사한 접근 방식도 도움이 됩니다.

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

REPL과 대화하는 것 같은 느낌이 듭니다. 그러나 이러한 제안은 실현 가능하지 않다는 것을 알고 있습니다.

from Tlahuixcalpantecuhtli as Venus import xxxxxxxxx as x9, yyyyyyyy as y8, zzz

이것은 내가 Python에서 가장 선호하지 않는 구문 선택 중 하나입니다. 의미를 약간 변경하려면 초기 키워드와 모든 것의 순서를 변경하여 전체 행을 근본적으로 재배열해야 합니다. 다른 수입품과 완전히 다른 것처럼 보이며 거의 동일한 작업을 수행한다는 사실을 흐리게 합니다. 이것은 피상적으로 영어와 같은 것에 너무 많은 비중을 두는 끔찍한 구문 설계입니다.

:+1: as , :-1: from

import a => b: c => d, e => f 는 나에게 너무 펄럭이는 느낌입니다.

나는 내쉬 균형에 대해 들어본 적이 없으며 그것에 대해 읽은 후에 이것이 균형을 구성한다고 생각하지 않습니다. 하지만 재미있는 점은 이 자전거 보관소가 1시간에 10개의 응답을 가지고 있는 반면, 저에게 매우 중요하지만 더 어려운 것으로 생각되는 #6984의 제안이 4시간 동안 아무런 논평도 없다는 것입니다!

as vs. => 의 경우 : 어느 쪽이든 현재 상황에 대한 좋은 개선이 될 것입니다.

좋은 지적 @BobPortmann #6984.

=> 가 FWIW에 적합하다고 생각합니다.

하지만 재미있는 점은 이 자전거 보관소가 1시간에 10개의 응답을 가지고 있는 반면, 저에게 매우 중요하지만 더 어려운 것으로 생각되는 #6984의 제안이 4시간 동안 아무런 논평도 없다는 것입니다!

Parkinson의 원래 비유에서 이 문제는 자전거 창고이고 #6984는 원자로입니다.

:)

나는 이 냄비를 휘젓는 것을 싫어하지만 나는 as 을 선호한다고 생각합니다. => 는 약간 모호하고 사전과 구문을 공유하는 것이 이상합니다. 아마도 = 가 의미가 있을 수 있습니다. import Foo: x = y , 지금 하는 const x = Foo.y 와 유사합니다.

그 외에는 Haskell 문서의 해당 표가 정말 도움이 됩니다. 나는 종종 (특히 julia를 처음 배울 때) import / using / require 또는 import Mod.thing vs. import Mod: thing . 실제로 가져오기에 대한 콜론 구문에 대한 설명을 찾고 있었는데 찾을 수 없었습니다.

@jakebolewski Julia의 using 는 Haskell의 (한정되지 않은) import 와 같고 Julia의 import 는 Haskell의 import qualified 와 같으며 Haskell 구문이 꽤 비슷한 것 같습니다.

출발점으로 더 잘 아는 사람이 이것이 현재 사용 가능한 가져오기/사용 구문의 좋은 요약임을 확인할 수 있습니까? x 및 y 함수를 내보내고 p 및 q 함수를 내보내는 Mod 모듈이 있다고 가정합니다.

import Mod 는 Mod.x , Mod.y , Mod.p 및 Mod.q $ 를 가져옵니다. 가져온 함수는 모두 메서드 확장에 사용할 수 있습니다.

using Mod 는 x , y , Mod.x , Mod.y , Mod.p 및 Mod.q $를 가져옵니다. . x 및 y 는 메서드 확장에 사용할 수 없지만 Mod.* 는 사용할 수 있습니다.

import Mod.x, Mod.p 는 x , p , Mod.x , Mod.y , Mod.p 및 Mod.q $를 가져옵니다. . 메서드 확장에 모두 사용할 수 있습니다.

import Mod: x, p 은 import Mod.x, Mod.p 와 동일합니다.

using Mod.x, Mod.p 는 x , p , Mod.x , Mod.y , Mod.p 및 Mod.q $를 가져옵니다. . x 및 p 는 메서드 확장에 사용할 수 없지만 Mod.* 는 사용할 수 있습니다.

using Mod: x, p 는 using Mod.x, Mod.p 와 동일합니다.

내가 말할 수있는 한 using Mod 은 Mod 내보낸 것을 신경 쓰는 유일한 사용법입니다.

Module의 문서에 이 요약이 있으면 정말 유용할 것입니다! 누군가 이것을 확인하여 PR을 준비할 수 있습니까?

논쟁의 여지가 가장 적은 버전은 다음과 같습니다.

import Tlahuixcalpantecuhtli as Venus: xxxxxxxxx as x9, yyyyyyyy as y8, zzz

나는 괜찮습니다. 할당 버전은 흥미롭지만 다음과 같이 테스트합니다.

import Venus = Tlahuixcalpantecuhtli: x9 = xxxxxxxxx, y8 = yyyyyyyy, zzz

싫어할 줄 알았는데 정말 이쁘네요. 이 모듈에 소개된 이름이 가장 먼저 나오고 가장 눈에 띄는 것이 마음에 듭니다. 여러 면에서 이것이 가장 중요한 것입니다.

@jakebolewski : 왜 모듈의 내부 기호를 다시 바인딩합니까? 당신이 정말로 그렇게해서는 안되기 때문에 추한 것입니다.

서로 다른 두 모듈에서 이름이 충돌하는 바인딩을 가져올 수 있으며 이를 통해 가능합니다. 또한 완전히 자격을 부여할 수도 있지만 앨리어싱을 지원하는 경우 이것도 지원할 수 있습니다.

잘 배치 된 일부 줄 바꿈은 IMO를 더 읽기 쉽게 만듭니다.

import Tlahuixcalpantecuhtli as Venus:
    xxxxxxxxx as x9, 
    yyyyyyyy as y8,
    zzz

또는

import Venus = Tlahuixcalpantecuhtli: 
    x9 = xxxxxxxxx, 
    y8 = yyyyyyyy, 
    zzz

나는 할당 버전을 상당히 선호한다는 것을 알게 되었습니다. 가져오기는 결국 할당의 한 형태입니다.

Module의 문서에 이 요약이 있으면 정말 유용할 것입니다! 누군가 이것을 확인하여 PR을 준비할 수 있습니까?

@brk00 , 가세요!

@kmsquire 오늘 작업하겠습니다!

하지만 그 전에 내가 그것을 잘 이해하고 있는지 확인하고 싶습니다. @ssfrr 예에서 내가 REPL에 있고 using Mod 를 입력한다고 가정합니다. 가져온 함수 x 및 y 는 메서드 확장에 사용할 수 없습니다. 즉, 다른 x 및 y 함수를 선언하면 한 번 가져온 Mod 의 메서드에 더 이상 액세스할 수 없으며 새 메서드에만 액세스할 수 있습니까?

함수를 가져오지 않고 확장하려고 하면 다음과 같이 됩니다.

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x()
"x"

julia> p()
ERROR: p not defined

julia> x(n) = n
ERROR: error in method definition: function Mod.x must be explicitly imported to be extended

다음과 같은 방법을 추가할 수 있습니다.

julia> import Mod: x # or import Mod.x

julia> x(n) = n
x (generic function with 2 methods)

julia> methods(x)
# 2 methods for generic function "x":
x() at none:5
x(n) at none:1

글쎄, 나는 이름 해결 행동에 혼란 스러웠습니다.

julia> module Mod

       export x, y

       x() = "x"
       y() = "y"
       p() = "p"
       q() = "q"

       end

julia> using Mod

julia> x(n) = n
x (generic function with 1 method)

using Mod 로 방금 가져온 함수를 _using_하기 전에 x 에 새 함수를 할당하면 오류가 발생하지 않습니다. 그러나 예를 들어 새 할당 전에 x() 를 호출하면(귀하의 예에서와 같이) 오류가 실제로 발생합니다.

아, 흥미롭다! 나는 그것에 대해 몰랐다. 방금 using 뒤의 네임스페이스를 보여주기 위해 x 를 호출했습니다.

핵심 개발자 중 한 명이 약간의 빛을 비출 수 있습니다. x 가 호출되어 오버로딩 시도 시 오류가 발생하면 어떻게 됩니까?

위에서 @carlobaldassi 가 제안한 앨리어싱이 실제로 매우 유용하다는 것을 알았습니다.

import 가 모듈 개체를 반환할 수 있는지 궁금합니다. 그래서 const 가 있거나 없는 할당으로 직접 별칭을 지정할 수 있습니까? 예

const Shortname = import ModuleWithLongName

대신에

import ModuleWithLongName
const Shortname = ModuleWithLongName

이것은 새로운 구문이 필요하지 않으며 기존 구문 요소의 조합만 필요합니다. 나는 현재 import 가 순전히 부작용을 위해 호출된 "문장"이며 가치가 없다는 것을 알고 있습니다. 파서가 이것을 허용하지 않는다면, 나는 import("Module") 또는 이와 유사한 것을 선호할 것입니다.

모듈에 별칭을 지정하는 옵션이 좋을 수도 있지만 아무도 언급하지 않은 단점이 있다고 생각합니다. 코드를 상당히 가릴 수 있다는 것입니다. 코드 리더의 관점에서 보면 모듈에 대해 설명하는 이름이 하나만 있는 것이 좋습니다.

그래도 찾아보기가 쉽지 않나요? 단축된 형식은 np for numpy 와 같은 인기 있는 패키지에 대해서도 표준화될 것입니다.

나는 여전히 numpy 을 표준화된 np 보다는 $ Arrays 를 numpy 로 선호합니다. numpy 는 1950년대 댄스 동작과 치명적인 전염병 사이의 교차처럼 들립니다.

다음과 같이 쉽게 작성할 수 있습니다.

Base.require("ArgParse")
const ap = Main.ArgParse

이것은 1.0에 대한 구문이 필요하지 않습니다

이에 대한 구문이 있어야 한다고 생각합니다. 예, require 및 const 할당을 할 수 있기 때문에 그것 없이도 살 수 있습니다. 그러나 require 를 사용하는 것은 꽤 추하고 편리한 구문이 없기 때문에 사람들이 이름을 바꾸지 못하게 됩니다. 그들이 원하는/필요한 대로.

참조 https://github.com/fredrikekre/ImportMacros.jl

const 쉬운 트릭은 매크로에 별칭을 지정해야 할 때 부족합니다. 이것이 제가 하는 방법이며 알아내는 데 시간이 좀 걸렸습니다.

julia> macro foo(a, b, c)                                  
           a, b, c                                         
       end                                                 
<strong i="8">@foo</strong> (macro with 1 method)                                 

julia> macro f(args...)                                    
           Expr(:macrocall, Symbol("@foo"), args...) |> esc
       end                                                 
<strong i="9">@f</strong> (macro with 1 method)                                   

julia> <strong i="10">@f</strong> 1 2 3                                            
(1,2,3)                                                    

ImportMacros.jl에서 다음을 구현하고 있습니다.

• <strong i="15">@from</strong> Foo.Bar use foo as f
• <strong i="18">@from</strong> Foo.Bar use <strong i="19">@foo</strong> as @f

참조: https://github.com/fredrikekre/ImportMacros.jl/pull/3

@Ismael-VC

노력하다

<strong i="7">@eval</strong> const $(Symbol("@foo")) = $(Symbol("@bar"))

이것은 더 못생겼지만, 매크로를 로컬에서 정의하는 것보다 짧고 더 명확합니다.

@TotalVerb 도움을 주셔서 다시 한 번 감사드립니다!

Julia + ImportMacros에서 누락된 유일한 기능은 모듈에 별칭을 지정하는 것과 이러한 모듈에서 가변 수의 개체에 별칭을 지정하고 별칭 없이 다른 개체를 가져오는 것을 혼합하는 것입니다.

• <strong i="9">@from</strong> Foo.Bar as B use foo as f, <strong i="10">@bar</strong> as <strong i="11">@b</strong>, baz

또는 from 없이 :

• import Foo.Bar as B: foo as f, <strong i="17">@bar</strong> as <strong i="18">@b</strong>, baz
• import B = Foo.Bar: f = foo, <strong i="21">@b</strong> = <strong i="22">@bar</strong>, baz

마지막 것은 매크로로는 불가능한 것 같습니다:

julia> parse("<strong i="26">@from</strong> Foo.Bar as B use foo as f, <strong i="27">@bar</strong> as <strong i="28">@b</strong>, baz")
:(<strong i="29">@from</strong> Foo.Bar as B use foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="30">@import</strong> Foo.Bar as B: foo as f, <strong i="31">@bar</strong> as <strong i="32">@b</strong>, baz")
:(<strong i="33">@import</strong> Foo.Bar as B:foo as (f,@bar(as,(@b(),baz))))

julia> parse("<strong i="34">@import</strong> B = Foo.Bar: f = foo, <strong i="35">@b</strong> = <strong i="36">@bar</strong>, baz")
ERROR: ParseError("unexpected \"=\"")
 in #parse#310(::Bool, ::Bool, ::Function, ::String, ::Int64) at .\parse.jl:184
 in (::Base.#kw##parse)(::Array{Any,1}, ::Base.#parse, ::String, ::Int64) at .\<missing>:0
 in #parse#311(::Bool, ::Function, ::String) at .\parse.jl:194
 in parse(::String) at .\parse.jl:194

제안된 모든 구문이 오류이거나 완전히 넌센스이기 때문에 이것은 실제로 1.0에 대해 결정할 필요가 없습니다.

원래 모듈이 REPL에서 reload("...") 와 같이 재정의되면 모듈 별칭은 어떻게 됩니까? const M = MyModule 접근 방식을 사용하면 M 는 다시 로드한 후에도 여전히 이전 모듈을 참조하므로 MyModule MyModule.name 액세스할 수 있지만 액세스할 수는 없습니다. M.name .

이 경우 별칭 구문은 const M = Module 에 대한 문법적 설탕 이상이어야 하지만 대신 M 가 항상 MyModule 와 동일한 것을 참조해야 합니다.

이렇게 하면 개발 중에 모듈을 계속 import 할 수 있지만 매번 ( const 가 아닌) 별칭을 다시 설정할 필요 없이 더 짧은 별칭을 통해 참조할 수 있기 때문에 REPL 워크플로가 단순화됩니다. reload .

현재 reload 이 제거되었으므로 이 문제는 더 이상 적용되지 않습니다.

이것은 include 에도 적용됩니다. 아니면 제가 놓치고 있는 것이 있습니까? 일반적으로 모듈을 재정의할 때 import ed 모듈 이름은 새 정의를 참조하고 할당에 의해 정의된 별칭은 이전 정의를 참조하지 않습니까?

아니요, 그것은 걱정할 필요가 없습니다. 일반 import 를 포함하여 모듈이 재정의될 때 가져온 이름은 절대 변경되지 않습니다. 변경된 사항은 다시 가져올 경우 가져올 모듈입니다. 가져온 것은 항상 바인딩이었습니다.

네, 제가 명확하게 표현하지 못했을 수도 있습니다. 예를 들면 다음과 같습니다. 콘텐츠가 포함된 test.jl 파일을 생성하는 경우

module Tst
f() = 1
end

로드하고 Tst 가져오고 $# Tst 별칭을 정의하면 모든 것이 정상입니다.

julia> include("test.jl")
Tst

julia> import Tst

julia> const Tst2 = Tst
Tst

julia> Tst.f()
1

julia> Tst2.f()
1

이제 test.jl 를 다음으로 변경하면

module Tst
f() = 2
end

REPL에서 다시 include 모듈과 해당 별칭이 다르게 작동합니다.

julia> include("test.jl")
WARNING: replacing module Tst
Tst

julia> Tst.f()
2

julia> Tst2.f()
1

이것이 왜 그런지 알지만 import Tst as Tst2 와 같은 별칭을 만들 때 이런 일이 발생해서는 안 된다고 생각합니다.

나는 이것을 0.6.2에서 테스트했고 현재로서는 0.7에서 테스트할 수 없기 때문에 이것이 여전히 사실이라면 지금은 하지 않습니다.

당신은 그것을 전혀 수입하지 않습니다. 포함하는 모듈은 이미 범위에 정의되어 있습니다. import 은(는) 작동하지 않습니다.

사실이지만 이것이 요점이 아닙니다. 요점은 가상의 import Tst as Tst2 와 같은 작업을 수행할 때 일어나는 일입니다. 그런 다음 이 명령문은 작동하지 않는 것이 아니라 별칭을 만듭니다.

이 별칭이 const Tst2 = Tst 처럼 작동하는 경우 Tst 모듈을 재정의하면 별칭이 모듈의 이전 버전을 가리킵니다. 이것은 어떤 경우에도 바람직하지 않습니다. 별칭은 Tst 의 새 버전도 가리켜야 합니다. 그렇지 않으면 사용자가 별칭을 다시 설정해야 합니다. 그러나 후자의 경우 재설정하지 않고 이전 별칭을 사용하면 이전 모듈을 가리키는 대신 오류가 발생해야 합니다.

그것이 전적으로 요점입니다. 모듈 정의가 아닌 import 에 함수를 추가하는 문제입니다. 귀하의 import 는 작동하지 않으며 제거한 후 코드에 import 또는 using 가 더 이상 없으므로 이 문제와 관련이 없습니다. 모듈이 import 와 동일한 범위에 정의되지 않도록 변경하십시오.

import Tst as Tst2 는 해당 이름에 바인딩되는 항목의 관점에서 import Tst 와 동일하게 작동합니다. 이는 항상 바인딩이며 원하는 마법이 아닙니다. 이것은 모듈을 정의할 때 별칭을 추가하는 것이 아닙니다 .

다른 식으로 말하면 코드는 기본적으로

a = Ref(1) # include
a = a # import
b = a # alias
a = Ref(2) # include again

그리고 a 가 a = a 에 의해 바인딩되지 않기 때문에 b = a 의 동작에 대해 불평하는 것은 의미가 없습니다. 당신이 보는 모든 것은 나쁜 예에서 가져오기와 같은 범위에서 모듈을 정의하는 부작용(예: a = a 및 a = Ref(...) 같은 범위)입니다.

좋습니다. 어떤 상황에서는 할당에 의해 정의된 별칭이 예상대로 작동하지 않는다는 점을 지적하고 싶었습니다. 어쩌면 내가 나쁜 예를 선택했을 수도 있습니다. 모듈 별칭을 생성하는 구문( import 과 관련이 있는지 여부)에 대해 이것이 중요할 수 있다고 생각했지만 지금 당장은 어디까지나 가설입니다. 소음 죄송합니다.

이 문제는 오랫동안 존재해 왔지만 일부 확장은 여전히 ​​논의되어야 합니다.

import LongPackage as longpkg

자체는 꽤 합리적으로 보입니다.

충돌. 현재로서는 최고의 솔루션이 무엇인지 궁금합니다. 내가 하는 일은 다음과 같습니다.

import LinearAlgebra
const linalg = LinearAlgebra

더 나은 솔루션이 있으면 수정해주세요!

그것이 현재의 기준입니다.

~ 구문은 어떻습니까? 결과는 모르겠지만 멋진 미학이 있습니다. 또한 ~는 근사치를 나타내는 기호로 사용됩니다.

import LongPackage ~ lp

@JeffreySarnoff 스테판 인용

@StefanKarpinski

이것은 내가 Python에서 가장 선호하지 않는 구문 선택 중 하나입니다. 의미를 약간 변경하려면 초기 키워드와 모든 것의 순서를 변경하여 전체 행을 근본적으로 재배열해야 합니다. 다른 수입품과 완전히 다른 것처럼 보이며 거의 동일한 작업을 수행한다는 사실을 흐리게 합니다. 이것은 피상적으로 영어와 같은 것에 너무 많은 비중을 두는 끔찍한 구문 설계입니다.

이 경우 ~는 Python 구문의 영어와 같은 측면과 아무 관련이 없습니다. ~을 볼 때 나는 근사치의 수학적 개념을 인식하는 것 같아요. 10.001 ~ 10.

그런 의미에서, 나는 ~가 실제로 꽤 좋다고 생각합니다.

import LongPackage ~ lp
import HugePackage ~ hp
import MassivePackage ~ mp
import GiantPackage ~ gp

:-)

ok -- python은 잊어버리세요 -- 저는 그 주석을 삭제하겠습니다.

lp imports LongPlayingRecords
hp imports HewlettPackard
mp imports MilitaryPolice
gp imports PariForNumberTheory

원래 마음에 안들었는데 자연스럽게 as 로 쓰고 싶어하시는 분들이 많은 것 같아서 다른 걸 하기에는 너무 엉뚱한 생각을 하게 되네요. 이것은 명확한 구문 컨텍스트이므로 키워드 또는 다른 것으로 예약할 필요가 없습니다.

사람들에게 그 의미를 알리기 위해 _시도하는_ 프로그래밍 언어 !?!

@제프리사노프

파이썬보다 더 잘하려고 하는 프로그래밍 언어 !!!

@neilpanchal Julia는 확실히 여러 면에서 Python보다 더 나은 언어를 시도하는 언어입니다. 다른 한편으로, 파이썬이 뭔가를 제대로 하고 있는 파이썬과 _다르게_ 되는 방식에서 벗어나지 않는 것은 분명합니다. Julia는 Python 왼쪽 및 오른쪽에서 구문 규칙을 차용합니다.

파이썬 as 을 채택하십시오. 그들은 그것을 맞았다.

julia> LightGraphs를 lg로 가져오기
오류: 구문: 표현식 끝 뒤에 추가 토큰 "as"

Python에서 벗어나는 as 에 찬성하는 또 다른 $0.02 주석입니다. fwiw, 이제 Julia w/some regularity를 ​​다시 사용하고 있으므로 이것을 그리워합니다. Python이 아니라 Clojure( 예 참조)에서와 같이 패키지 범위 네임스페이스(명확성에 좋은)를 단순화하여 라이브러리를 훨씬 더 광범위하게 명시적으로 사용할 수 있습니다. const gf = 행을 추가하지 않고 import Gadlfy as gf 에 약간의 구문 설탕을 갖는 using (예: 와일드카드 가져오기)를 피하는 것을 선호하기 때문에(현재 내가 하는 일) 편리하다.

as 구문을 지원하는 또 다른 의견 :heart: 앞으로의 Julia 릴리스에서는 정말 어려운 작업이 되었으면 합니다.

나도 이런 일이 일어나길 바란다. 특히 브레이킹 체인지가 아니기 때문에(맞나요?).

나는 이것이 어느 시점에 구현될 것이라고 생각하지만(시간이 허락한다면 스스로 시도할 것입니다), 그 동안 ImportMacros 패키지 에는 여기에서 요청한 거의 모든 기능이 있습니다(문서가 누락되었지만) :

<strong i="8">@import</strong> ModuleA as ma
<strong i="9">@using</strong> ModuleB as mb
<strong i="10">@from</strong> ModuleC use long_function_name as func
<strong i="11">@from</strong> Module use <strong i="12">@macroname</strong> as <strong i="13">@alias</strong>

ImportMacros .jl에 대해 몰랐는데 지적해주셔서 감사합니다. 이 기능이 패키지에 존재한다면 기본 언어로 포함하는 것이 그렇게 중요하지 않다고 생각합니다.

나는 여전히 이것이 언어로 있으면 좋을 것이라고 생각합니다.

가져오기는 거의 _항상_ 기본 언어 규칙을 따르고 매크로로 래핑하거나 패키지 종속성을 추가하지 않으려는 IMO입니다. import ... const 는 기본 언어가 2단계 프로세스를 더 간결하게 만들기 위해 확장되지 않는 경우에도 (특히) 폴백하기에 더 좋습니다.

특히 보기에 좀 징그럽다.

using ImportMacros
<strong i="6">@using</strong> OtherPackage as ...
<strong i="7">@using</strong> ThirdPackage as ...

매크로가 아닌 using 가 튀어나오기 때문입니다.

import 가 실제로 범위에 가져오는 모듈/함수/무엇이든 반환하는 것은 어떻습니까?
그러면 쓸 수 있습니다.
lg = import LightGraphs
baz = import foo.bar
baz, kit, kat = import foo : bar1, bar2, bar3
변경해야 할 유일한 것은 가져오기 기능입니다.

@DhruvaSambrani 의 솔루션은 Julia의 전반적인 "모든 것이 표현입니다" 접근 방식에 적합하기 때문에 정말 좋아합니다.

유일한 것은 일관성을 위해 가져오기 표현식이 전체 이름을 범위로 가져오는 부작용을 수행해야 한다는 것입니다(재해가 아닐 수도 있음). 전체 이름을 가져오지 않도록 특수 케이스를 사용할 수도 있지만 특수 케이스는 총체적입니다.

OCaml(최고의 모듈이 있는 언어!)에서 다음과 같이 할 수 있습니다.

module LG = LightGraphs

여기서 중요한 차이점은 OCaml 프로그램으로 컴파일되는 모든 모듈의 정규화된 이름이 자동으로 범위 내에 있다는 것입니다.

물론 import LightGraphs as LG 를 사용하면 "모든 사람"이 Python에서 이미 알고 있다는 이점이 있지만, 내 개인적인 취향은 문자 그대로 할당인 것에 할당 구문을 재사용하는 것이 더 낫다는 것입니다.

또는 더 광범위한 변경은 "네임스페이스"를 유형으로 도입하는 것입니다(이미 완료된 경우 idk). 그런 다음 import 는 모듈/무엇이든 네임스페이스로 확장하고 네임스페이스를 반환할 수 있습니다. 그러나 단순히 import mod_name 를 수행하면 전역 범위에서 mod_name 네임스페이스를 사용할 수 없기 때문에 모든 Julia 코드가 손상됩니다. import가 선행 할당 없이 사용될 때 mod_name 네임스페이스를 전역에서 사용할 수 있도록 할 수 있다면 그것은 문제가 되지 않습니다.

또는 단일 네임스페이스에서 모든 함수/모듈 등을 반환하는 순수 함수가 될 새 함수 import_as_ns(mod_name) :: Namespace 를 추가하십시오.

Julia의 전반적인 "모든 것이 표현입니다" 접근 방식에 맞습니다.

그러나 import 및 using 는 부작용에 대해서만 최상위 수준에서만 사용되기 때문에 특별합니다.

덧붙여서, 이 문제가 오랫동안 공개되어 왔다는 점을 감안할 때 triage에서 기꺼이 그것을 다시 방문하고 결정을 내릴 의향이 있는지 궁금합니다. 나는 폐쇄를 옹호할 것이다.

1. import Foo; const Bar = Foo 는 사용자가 네임스페이스에서 Foo 를 신경 쓰지 않을 때 완벽한 솔루션을 제공합니다.
2. ImportMacros.jl 은 나머지를 처리해야 합니다.
3. 둘 다 특별한 구문을 보증하기 위해 실제 코드에서 자주 사용되지 않는 것 같습니다.

나는 이 모든 시간이 지난 후에도 여전히 이것을 그리워한다고 말할 것입니다(내 자신의 코드에서도 ImportMacros를 사용합니다).

나는 당신이 쓰고 있는 커피의 스타일이 이것에 대한 필요(또는 욕망)에 영향을 미친다고 생각합니다. 저는 ML이나 과학 코드를 작성할 때 그것을 그리워하지 않는다는 것을 알게 되었습니다. 긴 이름을 가진 여러 패키지를 사용하는 다른 코드를 작성할 때 ImportMacros를 가장 많이 사용합니다.

ImportMacros로 충분합니다. 깨끗해 보이지 않는다는 의견에 동의합니다.

또한 편집기에서 자동 포맷터를 사용하여 가져오기를 정렬할 수 있는 날을 고대하고 있습니다. 하지만 @using 로 무엇을 해야 할지 알 수 없을 것 같습니다...

나는 또한 이것이 큰 문제가 아니며 ImportMacros로 충분해야 한다는 @kmsquire 에 동의합니다. 그러나 어떤 방법이든 다시 나타나지 않도록 문서화해야 합니다.

그래도 m=import Module 설탕이 먹고싶지만 😂

내 메시지가 이것이 큰 문제가 아니라는 것을 암시하려는 의도는 없었습니다.

나는 여전히 이것에 대한 구문을 선호합니다.

ImportMacros로 충분합니다. 깨끗해 보이지 않는다는 의견에 동의합니다.

동의한다. 또한:

using ImportMacros
<strong i="8">@using</strong> OtherPackage as ...

주어진 스크립트가 흐름을 복잡하게 만들고 가르침의 초점을 이동시키기 때문에 주어진 스크립트가 왜 이러한 불일치로 시작하는지 설명하기 위해 신규 이민자나 프로그래밍 초보자에게 언어를 제시할 때 약간 짜증이 납니다.

둘 다 특별한 구문을 보장하기 위해 실제 코드에서 자주 사용되지 않는 것 같습니다.

사람들이 실제 코드에서 ImportMacros를 많이 사용하지 않는 이유는 절충안 때문일 수 있습니다. 예를 들어 거의 매번 import ... as ... 를 사용하지만 이를 수행하기 위해 먼저 다른 패키지를 가져와야 하는 비용은 들지 않을 것입니다. 추가 종속성 이상으로 "느낌" 측면에서도 영향을 미칩니다(그리고 일부 사람들은 코드가 매끄럽게 보이기를 좋아합니다(특히 python 또는 Julia에서) 🤷‍♂️ , 이 using/@using 는 오히려 " hacky'의 분위기를 스크립트 도입에).

예, "ImportMacros로 충분합니다". 정말 사용하고 싶은 분들을 위해. 그러나 그것은 중요한 문제가 아니며 사람들은 그것 없이도 일할 수 있습니다. 그럼에도 불구하고, 나는 일반적으로 언어의 구문이 고정되도록 만드는 것이 일반적으로 이러한 작은 것들이라고 강력하게 믿습니다. 따라서 이 괴물 스레드는 기본에 대한 지원을 추가합니다.

import ... as ... 는 확실히 가치가 있는 구문적 설탕이라고 생각합니다. 이해하고 설명하기가 정말 쉽고 패키지 이름이 다소 긴 Julia와 같은 언어에서 특히 유용합니다(분명히 이것이 중요합니다. 사람들이 using ... 하고 싶지 않다는 가정 하에서만).

그리고 파이썬이 그것을 먼저 구현했다는 사실은 실제로 관련이 없어야 합니다. Julia는 다른 언어와 거리를 두거나 고유한 정체성을 강조하기 전에 최상의 구문을 갖도록 노력해야 합니다.

이것에 대한 구문과 인기 있는 모듈에 대한 규칙을 갖는 것(나는 그것이 항상 import numpy as np 및 import matplotlib.pyplot as plt 인 방법을 생각하고 있습니다)은 using SuchAndSuch 를 수행하고 export 에 의존하는 것에 대한 간결한 대안을 제공합니다.

@DominiqueMakowski :

주어진 스크립트가 이러한 불일치로 시작하는 이유를 설명하기 위해 신규 이민자 또는 프로그래밍 초보자에게 언어를 제시합니다.

왜 그것이 불일치라고 생각하는지 이해가 되지 않습니다. 단순히 네임스페이스 관리일 뿐인데, 이는 대규모 프로그래밍의 일반적인 부분입니다.

또한 모듈의 이름을 바꾸는 것은 Julia를 처음 접하는 사람들이 처음 접하는 일이 아닐 수도 있습니다.

유스케이스가 없다는 말은 아니지만, 자신의 키워드를 정당화하는 경우는 드물다. 현재 using ImportMacros 를 검색하면 Github에서 <10개의 고유한 결과가 표시됩니다.

나는 거의 매번 import ... as ...를 사용하고 싶지만 그것을 수행하기 위해 먼저 다른 패키지를 가져와야 하는 비용은 들지 않을 것입니다.

이렇게 하면 두 가지 방법이 모두 줄어듭니다 ImportMacros 또는 추가 기호( import LongFoo; const Foo = LongFoo )와 같은 경량 패키지를 사용하는 데 드는 (매우 사소한) 비용이 이점을 누릴 가치가 없다면 이점은 그다지 크지 않을 수 있습니다. .

Julia는 다른 언어와 거리를 두거나 고유한 정체성을 강조하기 전에 최상의 구문을 갖도록 노력해야 합니다.

왜 이것이 이 토론의 동기라고 생각하는지 잘 모르겠습니다.

const 할당이 제대로 작동하지 않는 경우 as 를 사용하려는 경우가 있습니다.

julia> using Distributed

julia> import Future; const future = Future
Future

julia> Future === Distributed.Future # oops, this is what we wanted
false

julia> Future === future # not what we wanted `Future` to mean
true

예, 이 문제를 해결할 수 있지만 어색합니다. 그것이 종종 편리하고 때때로 필요하고 import FooBar as FB 가 일반적으로 "가장 놀랍지 않은" 구문에 동의한다는 점을 감안할 때 우리가 따라야 할 것 같습니다. 이 모든 요구 사항은 누군가가 이를 구현하는 PR을 만드는 것입니다.

여기에 새로운 Julia 사용자가 있습니다.
저는 Python도 사용하여 주로 R 배경에서 왔습니다. using 와 같은 로드 메커니즘이 이끄는 패키지 공통 이름 공간에 대한 나쁜 경험이 있습니다. 충돌의 위험은 하나이지만 가독성 측면에서 각 메서드의 모듈에 대해 끊임없이 생각해야 하는 정신적 부담입니다.

이 구문을 추가하는 것이 얼마나 복잡한지 모르겠습니다. 뉴비도 가능한가요?

아마도 쉽지 않을 것입니다. Scheme에 작성된 파서 코드를 해킹하고 AST를 통해 변경 사항을 연결하여 일부 C 코드도 건드릴 수 있습니다.

여러 모듈에서 함수 이름 충돌을 피하기 위한 좋은 기능입니다.

slack에 대한 토론에서 몇 가지 생각을 추가합니다.

이것이 사람들이 함수 이름을 선택하고 올바른 함수에 메소드를 적절하게 추가하는 데 주의를 덜 기울이게 만들지 궁금합니다. 예를 들어,

numpy.sin
sympy.sin

다른 함수는 숫자 및 기호 입력 모두에 대해 작동하도록 하려면 두 가지 버전의 함수를 구현해야 하는 확실한 방법입니다. 이러한 네임스페이스가 julia에서도 편의성으로 인해 보편화된다면 많은 코드 재사용을 놓칠 수 있지 않을까요? 즉, Lyndon이 https://www.oxinabox.net/2020/02/09/whycompositionaljulia.html 에 게시한 것처럼 " 이는 사람들이 함께 일하도록 장려합니다 "라는 메시지를 덜 줄 수 있습니다.

@baggepinnen 나는 이것이 그 점에서 아무것도 바뀌지 않는다고 생각합니다.

Julia에서 다른 모듈에서 구현된 메서드는 두 메서드를 동일한 네임스페이스로 가져옴으로써 병합되지 않습니다.

julia> module Foo
           export sin
           sin(s::String) = uppercase(s)
       end
Main.Foo

julia> sin(1)
0.8414709848078965

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

julia> sin("wat")
ERROR: MethodError: no method matching sin(::String)
Closest candidates are:
  sin(::BigFloat) at mpfr.jl:727
  sin(::Missing) at math.jl:1197
  sin(::Complex{Float16}) at math.jl:1145
  ...
Stacktrace:
 [1] top-level scope at REPL[4]:1
 [2] run_repl(::REPL.AbstractREPL, ::Any) at /build/julia/src/julia-1.5.1/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:288

julia> Foo.sin("wat")
"WAT"

이것이 작동하려면 원래 함수에 디스패치를 ​​명시적으로 추가해야 합니다.

julia> Base.sin(s::String) = Foo.sin(s)

julia> sin("wat")
"WAT"

내가 말할 수 있는 한, 모듈 앨리어싱이 함수가 디스패치되는 방식을 변경할 수 있는 방법은 없습니다.

그리고 솔직히 말해서, 같은 이름을 가진 일부 함수는 별도의 네임스페이스에 _존재해야 합니다_. 숫자 라이브러리의 find_delta 함수는 파일 diff 라이브러리의 find_delta 와 관련이 없는 작업을 수행합니다. 코드가 너무 다형성이 되어 잘못된 입력에서 실행하는 방법을 찾게 되면 JavaScript 영역에 들어가게 되며 아무도 그것을 원하지 않습니다.

@ninjaaron 위의 우려 사항에 약간의 뉘앙스를 전달하지 못했을 수도 있습니다. 나는 이 변화가 사람들이 라이브러리를 구현할 때 선택하는 전략 이외의 어떤 것도 변경하는 데 관심이 없습니다.
Foo 구현하는 사람이 다음과 같은 경고를 만났습니다.

julia> using .Foo
WARNING: using Foo.sin in module Main conflicts with an existing identifier.

단순히 import .Foo.sin as sin2 를 선택하거나 실제로 Base.sin 에 대한 새 디스패치를 ​​제공하고 싶었는지 여부를 생각할 수 있습니다. 제 요점은 그것들을 단순히 다른 기능으로 간주하는 것이 매우 쉬워지면, 같은 기능의 다른 방법이 실제로 필요한 상황에서도 이것이 너무 널리 퍼질 수 있다는 것입니다. 같은 이름으로 다른 기능을 다루는 것이 조금 더 어색한 현재 상황은 사람들이 서로 이야기하고 실제로 같은 기능인지 확인하기 위해 최선을 다하는 좋은 부작용이 있습니다. 물론 매우 유용할 수 있는 같은 이름을 가진 다른 기능을 가질 가능성에 대해 논쟁하는 것이 아닙니다. 내 우려 사항이 중요한지 여부조차 확실하지 않지만 고려되었는지 확인하기 위해 제기할 가치가 있다고 생각했습니다.

@baggepinnen 그것은 의미가 있으며 그것을 제기하는 데 아무런 해가 없습니다. 모듈 앨리어싱은 라이브러리 사용자에게만 영향을 미치기 때문에 이것이 라이브러리를 만드는 사람들에게 큰 차이를 만들지 않을 것이라고 생각합니다. 모듈 앨리어싱이 더 쉬워지면 이름 충돌에 대해 _불평하는_ 사용자가 줄어들 가능성이 있다고 생각하지만 이것이 API에 엄청난 영향을 미친다면 놀랄 것입니다.

라이브러리를 작성할 때 일반적으로 Base의 함수에 디스패치를 ​​추가할지 아니면 별도로 유지해야 하는지 잘 알고 있습니다. 나는 대부분의 다른 도서관 저자들도 마찬가지라고 생각합니다.

@ninjaaron 현재 규칙이 다음과 같은 디스패치를 ​​위해 특정 구현을 사용하고 있는지 생각합니다.

numpy.sin
sympy.sin

import numpy.sin as np_sin 를 사용자/개발자를 위한 추가 옵션으로 사용하는 것은 현재 코드 기반에 영향을 주지 않아야 합니다.
유일한 관심사는 노출 기능/인터페이스에만 영향을 미칠 것입니다.