Julia: API 일관성 검토

이것이 언급하기에 적절한 장소가 아니라면 사과하지만 앞으로 함수 이름의 밑줄과 더 일치하는 것이 좋을 것입니다.

아니, 여기가 좋은 곳입니다. 그리고 예, 우리는 밑줄이 필요한 모든 이름을 제거하기 위해 노력해야합니다. :)

• "이 [이] 차원에 걸쳐 계산"입력 인수, 허용되는 유형 등의 일관된 처리, 이러한 작업을 키워드 인수로 수행하는 것이 바람직한 지 고려
• do-blocks에 대한 함수 인수, 인쇄하는 함수에 대한 IO 인수, in-place 함수에 대한 출력 등의 관점에서 우리의 첫 번째 규칙을 나열하고 우선 순위 지정 (편집 : 이미 열려있는 것이있을 수 있음)

@tkelman 의 두 번째 요점은 https://github.com/JuliaLang/julia/issues/19150을 참조

find API 및 관련 기능에 대한 최근 Julep도 있습니다 : https://github.com/JuliaLang/Juleps/blob/master/Find.md

채널에 push! 및 shift! 가 있으므로 채널에서 put! 및 take! 를 지원 중단해야합니까 (선물에도 동일하게 적용)? API에서 중복 단어 2 개를 제거하는 것이 좋습니다.

shift! 이 (가) 사용자 친화적인지 의심 스럽습니다. 후보는 fetch! 우리는 이미 fetch 의 인 비 돌연변이 버전 take!

ref # 13538 # 12469

트윗 담아 가기

편집 : 채널에서 send 및 recv 를 재사용하는 것도 이치에 맞습니다. (현재로서는 UDPSocket에만 사용된다는 사실에 놀랐습니다)

put! / take! 를 push! / fetch! 로 바꾸면 +1

나는 이름을 변경 추가 할 것입니다 @inferred 에 @test_inferred .

전문화가 더 일반적인 기능과 일치하는지 다시 확인하십시오. 즉 # 20233과 같은 것이 아닙니다.

내 보낸 모든 함수를 검토하여 여러 디스패치로 대체하여 제거 할 수 있는지 확인합니다 (예 : print_with_color).

큐와 같은 데이터 구조로 작업 할 때 일반적인 쌍은 push! 및 shift! 입니다.

이러한 종류의 데이터 구조에 대해 일반적인 이름 쌍을 사용하지 않을 것입니다. 작업이 해당 이름으로 적절하게 전달되지 않는 통신 오버 헤드를 수반 할까 걱정하기 때문에 push! 의미가 있습니다. send 및 recv 정말 더 좋을 수 있습니다.

함수가 튜플을 마지막 인수로 사용하는지 아니면 vararg를 사용하는지간에 일반적인 일관성이 있는지 다시 확인하십시오.

이 문제에 비해 너무 클 수도 있지만 함수가 오류를 발생시켜야하는시기와 Nullable s 또는 Union s (예 : parse 반환해야하는시기에 대한 일관된 규칙을 갖는 것이 좋습니다 tryparse , match 등)

너무 큰 문제는 없습니다. @simonbyrne – 이것이 세탁 목록입니다.

Btw : 이것은 특정 변경 (예 : 특정 기능의 이름 변경)을위한 것이 아닙니다. 검토 할 수있는 종류에 관한 것입니다. 제안 된 특정 변경의 경우 해당 변경을 제안하는 문제를 엽니 다.

code_xxx 와 같은 기본 함수와 쌍을 이루는

이것이 당신이 말하는 것인지 확실하지 않지만 CreateMacrosFrom.jl을 참조하십시오.

• "출력 유형"API가 요소 유형 또는 전체 컨테이너 유형을 기준으로해야하는지 여부 (참조 # 11557 및 # 16740)

• 내 보낸 모든 기능 문서화 (doctest 포함)

내 보낸 모든 기능 문서화 (doctest 포함)

이것이 이것의 일부라면, 아마도 또한 : 문제 / 홍보 번호로 테스트에 라벨을 붙이는 것을 잊지 마십시오. 그 테스트가있는 이유를 훨씬 쉽게 이해할 수 있습니다. 나는 git blame이 어떻게 작동하는지 알고 있지만, 테스트 세트를 추가 할 때 (예제를 들기 위해) 때때로 테스트중인 것이 약간 미스터리이며 문제 / 홍보 번호가 항상 존재한다면 좋을 것입니다.

@dpsanders : 및 내 보낸 매크로! 예 : @fastmath 에는 독 스트링이 없습니다.

이것은 매우 사소하지만 string 및 Symbol 함수는 거의 동일한 작업을 수행하고 대소 문자가 다릅니다. symbol 가 더 의미가 있다고 생각합니다.

@amellnik 차이점은 Symbol 은 유형 생성자이고 string 는 일반 함수라는 것입니다. IIRC는 우리가 symbol 있었지만 타입 생성자를 위해 더 이상 사용되지 않습니다. 이를 위해 변경이 필요하다고 확신하지는 않지만, string 대신 String 생성자를 사용해야한다고 생각합니다.

문자열 대신 String 생성자를 사용해야한다고 생각하는 경우.

아니요, 서로 다른 기능이므로 병합하면 안됩니다.

julia> String(UInt8[])
""

julia> string(UInt8[])
"UInt8[]"

아니요, 서로 다른 기능이므로 병합하면 안됩니다.

이것은 string(args...) 대신 sprint(print, args...) 대신 사용되지 않는 상황처럼 보입니다. 그러면- string 및 String 것이 혼란 스럽습니다. 손실 된 성능을 복구하기 위해 sprint(::typeof(print), args...) 에 특화 할 수 있습니다. 이 줄을 따라 repr(x) 대해 sprint(showall, args...) repr(x) 를 더 이상 사용하지 않는 것이 좋습니다.

string 를 호출하여 무언가를 문자열로 바꾸는 것은 꽤 표준적인 것처럼 보이지만 괜찮아 보입니다 ....

무언가를 문자열로 바꾸기 위해 문자열을 호출하는 것은 꽤 표준적인 것 같습니다.

예,하지만 여기서 String 와 string 사이의 연결이 끊어집니다.

sprint(print, ...) 은 중복 된 느낌입니다. 우리가 제거하는 경우 string , 우리는 이름을 바꿀 수 있습니다 sprint 에 string 우리가 얻을 수 있도록 string(print, foo) 및 string(showall, foo) 내 의견을 잘 읽는 .

일관성이 과대 평가되는 경우 일 수 있습니다. 나는 "그냥 x의 문자열 표현을 줘"에 대해 string(x) 를 갖는 것이 괜찮다고 생각합니다. 예를 들어 사용할 인쇄 기능을 지정해야하는 경우와 같이 그보다 더 복잡 할 경우 sprint 와 같은 다른 이름을 사용하는 것이 좋습니다.

또한 이름을 나와 함께 괜찮을 것 String(UInt8[]) 다른 것으로, 사용이 String 대신 string . string 는 앞으로 우리가 반환하는 문자열 유형을 변경할 수있는 유연성을 조금 더 제공하지만 그럴 것 같지는 않습니다.

reinterpret(String, ::Vector{UInt8} 이 (가) 전혀 의미가 없습니까, 아니면 reinterpret 에 대한 말장난입니까?

말이되는 것 같습니다.

문제는이 함수가 때때로 복사하기 때문에 이름이 다소 오해의 소지가 있다는 것입니다.

사실이지만 문자열은 불변이어야하므로 아마 그럴 수 있습니다.

String(::IOBuffer) 메서드도 있지만 readstring 로 더 이상 사용되지 않을 수 있습니다.

나는 당신이 제안한 API 변경에 대해서도 생각했지만 string(a, b...) 의 인터페이스는 인수를 문자열 화하고 연결한다는 것이므로 호출 가능한 첫 번째 인수에 대해 성가신 예외가 발생합니다. string 에서 연결을 제거하면 작동 할 수 있습니다.

예, 동의했습니다. 일관성과 문제를 피하는 것이 가장 중요합니다.

"차원 인수"범주의 문제 # 18326 및 # 3893에 주목하십시오.

다른 항목을 다룰 수 있다면 : 변경 가능한 컨테이너의 동작이 문서화되고 일관성이 있는지 확인하십시오.

@ JaredCrean2 : 그게 무슨 뜻인지 자세히

나는 그것이 많은 "방어 복제물"을 만드는 것을 포함하지 않기를 바란다.

예를 들어, 변경 가능한 유형의 배열이 있고 여기에서 sort 를 호출하면 반환 된 배열이 입력 배열과 동일한 객체를 가리 키거나 객체를 복사하고 반환 된 배열이 그들?

같은 물건. 모든 컬렉션 정렬, getindex, 필터링, 검색 등의 메서드가이 규칙을 따르고 있다고 확신합니다.

저는 그 점에 대해 명확성이나 일관성이 부족하다고 생각하지 않습니다. 항상 같은 대상입니다.

사실, 그렇지 않은 유일한 표준 함수는 deepcopy 이며, 여기서 요점은 모든 새 개체를 얻는 것입니다.

어딘가에 문서화되어 있습니까?

아니오 – 우리는 할 수 있지만 그것을 문서화하는 것이 가장 좋은 곳을 모르겠습니다. 함수가 불필요하게 복사하는 이유는 무엇입니까? 그들이 할 수있는 인상을 어디서 얻었습니까?

안녕하세요. 나는 데이터 직렬화에 대한 발언을 보지 못했습니다.

조만간 julia 프로그램이 작성되고 공개적으로 실행될 것이며 데이터는 때때로 몇 년 동안 계층화되기 시작할 것입니다. 데이터 직렬화 예. 체인 : 객체는 유형 (json 또는 ... 일 수 있음)에 의해 구동되는 바이트로 시간 복원력이 있도록 빌드되어야합니다. 시맨틱 버전 관리 및 웹 API에 대해 생각하는 것도 중요합니다.

사용자 데이터의 직렬화가 https://github.com/JuliaLang/julia/blob/v0.5.1/base/serialize.jl에 가깝게 유지 될 것으로 예상 할 수 있습니까?

함수가 불필요하게 복사하는 이유는 무엇입니까? 그들이 할 수있는 인상을 어디서 얻었습니까?

나는 그들이 그렇지 않은지 모른다. 내가 말할 수있는 한, 행동은 정의되지 않았습니다. @JeffBezanson 의 의견에서 그가 반대하는 방어적인 사본을 만드는 것을 옹호하는 사람들이 있습니다. 따라서 문서는 어딘가에서 방어 복사본 문제를 다루어야합니다.

당신은 어떤 종류의 최소 동작 원리를 암시하는 것처럼 보이지만 알고리즘의 세부 사항에 따라 "최소 동작"이 무엇인지 모호해집니다. API 전체에서 일관성을 얻으려면 더 구체적인 지침이 필요하다고 생각합니다.

@ o314 : 이것은 API 일관성 검토 문제입니다. 직렬화가 어떻게 관련되는지 잘 모르겠습니다.

@ JaredCrean2 : 최상위 객체가 복사되었는지 여부는 확실히 문서화 될 필요가 있습니다. 내가 말하는 것은 deepcopy (분명히)를 제외하고는 더 깊은 객체는 결코 복사되지 않는다는 것입니다.

내가 말하는 것은 deepcopy (분명히)를 제외하고는 더 깊은 객체는 결코 복사되지 않는다는 것입니다.

일부 배열 래퍼에 대해 copy 컨텍스트에서 이에 대한 최근 논의가있었습니다 (예 : SubArray 및 SparseMatrixCSC 및 Symmetric , LowerTriangular . 위에서 언급 한 정책에 따라 copy 는 그러한 래퍼 유형에 대한 noop이 될 것 같습니다. 여기서 언급 한 정책이 적절한 추상화 수준입니까? 예를 들어 Array s가 Julia에서 구현 된 경우 (버퍼 래핑) Array 의 copy 동작이 noop로 변경되어야 함을 의미합니다.

더 깊은 객체는 절대 복사되지 않는다는 것이 관례라면 남은 것은 문서화하는 것뿐입니다. 문서화는 API에서 정말 중요한 부분입니다. 이 동작은 (아마도 코드의 일부를 작성했기 때문에) 분명해 보일 수 있지만 외부 관점에서는 그렇게 명확하지 않습니다.

편집 : Andreas 게시물을 보지 못했습니다. 흥미로운 고려 사항입니다.

@StefanKarpinski 나는 당신의 요점에 동의합니다.
그리고 여기서 언급 된 모든 주요 주제는 매우 훌륭하고 영리합니다.

하지만 줄리아의 프로세스와 데이터 간의 균형에 대해 때때로 약간의 두려움이 있습니다.

fortran 또는 c를 쉽게 호출 할 수 있습니다.
그러나 코드는 예를 들어 최신 데이터 센터에 쉽게 배포됩니다. 서비스 패턴으로서의 기능을 가진 aws lambda. 인터넷, 오픈 API를 통해 코드를 쉽게 호출 할 수 있습니까?

때로는 확장하기 위해 기능 부하를 낮추고 (일반, 함수 서명에 대한 vaarg 없음, 공개 API에 대한 상위 순서 없음) 더 체계적으로 데이터를 바인딩해야합니다 (json 스키마 / openapi).

나는 이런 식으로 가라 앉는 아주 좋은 파이썬 라이브러리를 보았고 그것은 유감입니다.

웹에 쉽게 배포 할 수 있도록 데이터와 기능의 균형을 유지하고 모듈 식으로 유지하는 것이 언어 1.0의 중요한 지점이라고 생각합니다. 그리고이 기능을 위해 인터페이스는 필요에 따라 애완 동물이 적고 가축 지향적이어야합니다.

이 주제의 요점이 아닐 수도 있습니다.

@StefanKarpinski 귀하의 게시물을 오해했을 수 있습니다. 당신이 말했을 때

최상위 객체가 복사되었는지 여부를 확실히 문서화해야하는지 여부

"최상위 개체"는 무엇을 의미합니까? x::Vector{MyMutableType} 이있는 경우 최상위 개체는 x x 입니까, 아니면

최상위 객체는 x 의 요소가 아니라 x 자체를 참조합니다.

@andreasnoack 최상위 객체의 개념은 구현 세부 사항이 아니라 구현 된 추상 구조를 참조해야합니다.

float 및 유형 대 값에 모두 작용하는 기타 유사한 기능을 추가 할 수 있습니까?

0.6 릴리스 노트를 살펴보면 iszero(A::Array{T}) 가 도입 된 반면 배열에 대한 다른 많은 함수 (예 : sumabs , isinteger , isnumber )는 all(f,A) 대신 더 이상 사용되지 않습니다.

배열이 0이고 벡터 공간에 0 요소가 있습니다. iszero 일반적으로 무언가가 가산 적 역인지 여부를 테스트합니다.

레. 함수 이름에서 밑줄의 일관성, 여기에 count_ones 및 count_zeros 대한 탐색 경로가 있습니다.

Julia API를 일관되게 유지하려면 (a) API 규칙 / 컨벤션이 무엇인지 지정하고, (b) Julia 코드의 정적 분석을 수행하여 감지 할 수있는 소프트웨어가 필요합니다. 이러한 규칙 / 협약에서 벗어난 경우 (c) 제안을 제공합니다. 이러한 도구는 Julia Base와 모든 Julia 패키지 모두에 도움이됩니다. 새로운 Julia 패키지가 트릭을 수행 할 수 있습니다. (Tongue in cheek :이 패키지가 가장 먼저해야 할 일은 APICheck.jl, ApiCheck.jl, API_Check.jl, APIChecker.jl, JuliaAPIChecker.jl 등) 자체 이름을 제안하는 것입니다. 저는 Julia를 처음 접합니다. 그러니 그런 일을 주도하고 싶지 않습니다. 그러나 나는 기여하는 것을 꺼리지 않을 것입니다. 이 작업을 수행하는 방법에 대한 제안이 있습니까?

우리는 Lint.jl에 그것을 갖고 싶습니다!

num2hex 및 hex2num (# 22031 및 # 22088)

저도 Lint.jl이 Julia API 일관성 검사에 적합한 패키지라고 믿습니다. 하지만 우리가 그 길을 가면 스테판의 원래 목록이 훨씬 더 정확 해져야합니다. 예를 들어 그가 "DataStructures의 모든 컬렉션에 일관된 API가 있는지 확인해야합니다"라고 썼을 때 떠오르는 질문은 다음과 같습니다.

• 데이터 구조를 컬렉션으로 만드는 것은 무엇입니까? (기본 컬렉션 목록)
• 컬렉션이 반드시 지원해야하는 기능은 무엇입니까? (컬렉션 별 함수 스프레드 시트)
• 각 기능의 서명은 무엇입니까?
• 컬렉션을 위해 Base에서 제공하는 API가 실제로 이미 일관성이 있습니까?

이러한 인벤토리와 분석을 관리하기 위해 프로젝트를 Julia 저장소 (프로젝트 # 8), JuliaPraxis 저장소 (TotalVerb에서 오프라인으로 제안) 또는 Lint 저장소에 추가 할 수 있습니다. 이 경우 누가 그러한 프로젝트를 소유 할 것인지, 어떤 사람들이 처음부터 참여해야하는지, 그리고 줄리아 규칙이 실제로 무엇인지에 대한 최종 결정을 내려야하는 사람을 분류해야합니다 (린팅 목적을 위해).

그러나이 라인을 따라 더 진행하기 전에 @StefanKarpinski 에게 물어보고

나는 이것을 구체적으로 명시하는 것이 좋은 생각이라는 데 동의합니다. 그 목록이 무엇인지 알아내는 것은 여기서 작업의 일부입니다. 만약 당신이 그것에 균열을 갖고 싶다면 그것은 좋을 것입니다.

Base.datatype_module과 Base.function_module이 정말로 필요합니까?

데이터 유형과 함수를 전달하는 통합 함수 "모듈"(어쩌면 getmodule)이 나에게 더 일관된 것 같습니다.

@code_typed 및 친구의 밑줄은 어떻습니까?

이는 리팩토링을 할 수있는 좋은 기회입니다 (밑줄 금지에 대한 명시된 이유). 첫 번째 인수가 원하는 코드 유형 인 @code 매크로를 가질 수 있습니다.

( @bramtayl , 매크로 주변에 백틱을 두는 것을 @code )

FWIW, 탭 완성은 함수 이름에서만 작동합니다. @code_<TAB> 할 수 있다는 것은 좋은 일입니다 ....

리팩토링이 고려되었지만 거부 된 경우 밑줄이 있는지 여부는 논쟁의 여지가 있습니다. 밑줄 금지의 유일한 요점은 리팩토링을 장려하는 것입니다. 사실이 경우에는 언어를 더 명확하게하기 위해 밑줄을 사용하는 것이 좋습니다.

감사를 강조하십시오.

반대 제안 : 우리는 여전히 이러한 이름을 감사하지만 코드를 더 쉽게 읽을 수있는 곳에 밑줄을 더 추가합니다 (codetyped vs code_typed, isos2 vs is_os2).

나는 이것에 대해 절대주의자가 아닙니다. @KristofferC가 지적했듯이 code_typed 은 괜찮고 , 유용하게 탭 완성이라고

나에게는 배가 기본적으로베이스의 절반을 제거해야하기 때문에 더 많은 밑줄을 추가하여 항해 한 것처럼 보입니다. 예를 들어, is 시작하는 74 개의 술어 함수와 is_ 시작하는 6 개만 있습니다. 6 또는 74를 더 이상 사용하지 않는 것이 더 합리적입니까?

여기에 몇 가지 상충되는 목표가 있습니다.

1) 이름을 더 읽기 쉽게 만들기
2) 코드 이탈 감소
3) 리팩토링 장려

단어를 함께 충돌시켜 밑줄을 제거하는 것은 3 개의 전선 모두에서 실패합니다.

스트림을 수락하는 show 메서드가 ! 되지 않은 것은 일반적인 규칙과 일치하지 않는 것 같습니다. Ref. https://github.com/JuliaLang/julia/pull/22604/commits/db9d70a279763ded5088016d9c3d4439a49e3fca#r125115063. 베스트! (편집 : 이것이 스트림을 받아들이는 write 메서드와 일치한다고 가정합니다.)

트레이 트 API에 불일치가 있습니다. 일부 특성은 다음과 같은 특성을 호출하여 계산됩니다.
TypeArithmetic(Float64)
이 함수는 소문자로 표기해야합니다.
iteratorsize(Vector{Float64})

size -> shape (xref # 22665)의 이름을 바꾸는 것이 좋습니다.

Array{T,1}() 도 더 이상 사용되지 않습니다.

julia> Array{Int,1}()                                                                                                                  
0-element Array{Int64,1}                                                                                                               

julia> Array{Int,2}()                                                                                                                  
WARNING: Matrix{T}() is deprecated, use Matrix{T}(0, 0) instead.                                                                       

컬렉션에 대해 생각하고 있습니다. 기본적으로 세 가지 종류가 있습니다.

• 일부 값만 포함하는 단순한 세트 형 (또는 가방 형) 컬렉션입니다.
• 데이터와 함께 인덱스를 추가하는 배열과 유사한 컬렉션.
• 데이터의 일부로 인덱스가있는 사전과 유사한 컬렉션, 즉 k=>v 쌍.

나는 딕셔너리와 같은 행동에 회의적이었습니다. 석탄 광산의 카나리아는 map 이며 키-값 쌍에서 작동하는 것은 일반적으로 키 집합을 변경하지 않기 때문에 자연스럽지 않습니다. 배열과 사전이 동일한 인터페이스를 구현하는 것도 가능합니다.

• keys 는 eachindex
• mapindexed 및 filterindexed 는 사전과 배열 모두에 유용합니다. 함수에 해당 항목의 인덱스를 전달한다는 점을 제외하면 맵 및 필터와 유사합니다.
• 배열과 사전 (및 명명 된 튜플 및 기타 항목)은 기본적으로 zip(keys(c), values(c)) 대한 바로 가기 인 pairs 반복자를 사용할 수 있습니다.

ind2sub 및 sub2ind 이름을 바꾸는 것을 고려하십시오. 이는 분명히 matlabism이며 비 matlab 사용자에게는 줄리아나가 아닌 이상한 이름을가집니다. 가능한 이름은 각각 indice 및 linearindice 입니다. 사람들이 어떻게 생각하는지 모르겠 기 때문에 감히 PR을 만들지 않았지만 지원이 있으면 할 것입니다.

rad2deg 및 deg2rad 합니다.

Ref. # 22791 ( select -> partialsort ). 베스트!

내가 여기서 보지 못한 한 가지는 : 선택적 위치 인수가 처음 또는 마지막으로 이동합니까? sum(f, itr) 및 rand([rng,] ..) 와 같이 선택적 위치 인수가 먼저 median(v[, region]) 또는 split(s::AbstractString[, chars]) . 때때로 그들은 처음 또는 마지막으로 갈 수 있지만 둘다는 아닙니다! (예를 들어, mean 는 함수를 먼저 사용하거나 마지막 차원을 사용할 수 있지만 둘 다 사용할 수는 없습니다.)

현재 언어 시맨틱은 선택적 인수를 마지막으로 강제합니다. f(a, b=1) 는 쓸 수 있지만 f(b=1, a) 는 쓸 수 없습니다. 그러나 모든 선택적 인수가 마지막으로 가면 편리한 do 블록은 어떻게 될까요?

다른 것이 없다면, rand.jl : shuffle!(a::AbstractVector) = shuffle!(GLOBAL_RNG, a) 에서 언어가 이와 같은 메서드를 정의해야한다는 것은 사소한 사마귀입니다. 선택적 위치 인수 구문은이 사용 사례를 정확히 처리해야합니다.

아마도 별도의 문제로 들어가야 할 수도 있지만 원하는 곳으로 선택적 인수를 이동할 수있는 것 같습니다. 예를 들어 f(a = 1, b, c = 2) 는 f(x) = f(1, x, 2) 및 f(x, y) = f(x, y, 2)

임의의 위치에서 기본 인수를 활성화하려는 (인기없는) 시도에 대한 xref # 22460.

warn 을 warning (matlab에서도 사용함)로 변경하는 것은 큰 문제가 아니지만 제가 언급 할 것이라고 생각 했습니까?

throw 와 같이 동사이기 때문에 warn 좋아합니다.

나는 이것에 대해 매우 혼란스러워했습니다.

julia> f(;a=1,b=1) = a+b                                                                                                                              
f (generic function with 1 method)                                                                                                                    

julia> f(a=4,5)            # I intended to write f(a=4,b=5)                                                                                                                           
ERROR: MethodError: no method matching f(::Int64; a=4)                                                                                                
Closest candidates are:
  f(; a, b) at REPL[13]:1

키워드 함수를 정의 할 때와 마찬가지로 함수를 호출 할 때만 키워드를 마지막으로 허용하는 것이 좋습니다.

키워드 함수를 정의 할 때와 마찬가지로 함수를 호출 할 때만 키워드를 마지막으로 허용하는 것이 좋습니다.

다른 위치에 키워드를 전달하는 것이 유용하고 인체 공학적인 API가 많이 있습니다.

호기심에서 위치 및 키워드 인수에 대해 정의 된 평가 순서가 있습니까? 몇 가지 오래된 문제를 보았고 https://docs.julialang.org/en/latest/manual/functions/#Evaluation -Scope-of-Default-Values-1에서 범위에 대해 이야기했지만 예를 들어 인수는 왼쪽에서 오른쪽으로 평가되거나 모든 위치 인수가 모든 키워드 인수보다 먼저 평가되거나 정의 된 평가 순서 (또는 다른 항목)가없는 경우 평가됩니다.

@yurivish , 키워드는 문서를 참조하십시오 (https://github.com/JuliaLang/julia/issues/23926). 선택 사항의 경우 이야기가 조금 더 복잡 합니다 . 있습니다 . (https://discourse.julialang.org/에서 질문하는 것이 더 좋습니다.)

자체 문제로 볼 가치가없는 것 같지만 bits(1) 이 String 반환한다는 것이 항상 이상해 보입니다. BitVector 또는 Vector{Bool} 이어야합니다

Function 또는 Callable 디스패치하는 메서드 테이블에 대한 리뷰를 제안하고 싶습니다. 이러한 API가 우리가 원하는 방식인지 확인하고, 어떤 객체 든 덕 호출을 허용 할 수 있도록 테이블을 재구성 할 기회를 놓치고 있지 않은지 확인해 보겠습니다.

all 및 any , 이미 all(Generator(f, xs)) 에타 감소 된 all(f(x) for x in xs) 으로 사용 중단되는 것이 간단 해 보이므로 오버 헤드가 없어야합니다.

그것이 당신이 의미하는 바인지 확실하지 않지만, 경우에 대비해 언급 할 가치가 있다고 생각했습니다. 저는 제너레이터에 대한 기능적 스타일 API를 사용하지 않는 것에 대해 하드 코어 입니다. 우리는 any(f, x) 와 all(f, x) 를 가지고 있으며 널리 사용됩니다. 그것들을 제거하기 위해 -10000000 (또는 실제로 그러한 방법).

임 프로 생성기. 게으른 프로그래밍의 기본 구성 요소처럼 보이며 내 보내야합니다. all(Generator(f, xs)) all(f(x) for x in xs) 보다 정의 된 함수에 더 편리 할 때가 있습니다. 또한 균형을 회복하기 위해 +10000000

가능한 경우 여기에 구문이 적은 것을 선호합니다. "xs를 취하고, f를 모든 것에 적용하고, 모든 것이 참이면 참을 반환한다"라는 생각을 표현하는 것이 쉽고 읽기 쉽고 성능이 좋다면 왜 그것을 하나의 동사에 넣어야할까요?

f(x) for x in xs 의 불필요한 명사 x 가 우려되는 경우 Generator 내보내기에 대한 @bramtayl 의 제안 (아마도 Map 와 같은 더 나은 이름 사용?) 말이된다.

all(isnull, x) 같은 것은 all(isnull(v) for v in x) 보다 훨씬 간단합니다. all(isnull, x) 대신 NullableArrays에서 allnull 함수를 사용하지 않습니다. 구문이 사라지면 아마 다시 도입해야 할 것입니다.

어떻게 이름 바꾸기에 대한 strwidth 에 stringwidth (난이 캐릭터 라인에 문자열을 축약 한 유일한 수출 문자열 조작 함수라고 생각합니다)

실제로 textwidth (https://github.com/JuliaLang/julia/pull/23667)로 이름이 변경되었습니다.

IMO,이 문제는 너무 광범위하여 1.0 마일스톤을 갖지 못합니다. 곧 기능이 중단되기를 원합니다. 이를 수행하려면 여러 명의 소유자가 필요할 수 있으며 검토 할 기능 세트를 할당 할 수 있습니다.

또한, FemtoCleaner가 1.0 이후에 많은 것을 자동 업데이트 할 수있는 또 다른 곳입니다.

textwidth에 대한 의견 :

INFO: Testing Cairo
Test Summary:   | Pass  Total
Image Surface   |    7      7
Test Summary:   | Pass  Total
Conversions     |    4      4
Test Summary:   | Pass  Total
TexLexer        |    1      1
WARNING: both Compat and Cairo export "textwidth"; uses of it in module Main must be qualified
Samples        : Error During Test
  Got an exception of type LoadError outside of a <strong i="6">@test</strong>
  LoadError: UndefVarError: textwidth not defined
  Stacktrace:
   [1] include_from_node1(::String) at .\loading.jl:576
   [2] include(::String) at .\sysimg.jl:14
   [3] macro expansion at C:\Users\appveyor\.julia\v0.6\Cairo\test\runtests.jl:86 [inlined]
   [4] macro expansion at .\test.jl:860 [inlined]
   [5] anonymous at .\<missing>:?
   [6] include_from_node1(::String) at .\loading.jl:576
   [7] include(::String) at .\sysimg.jl:14
   [8] process_options(::Base.JLOptions) at .\client.jl:305
   [9] _start() at .\client.jl:371
  while loading C:\Users\appveyor\.julia\v0.6\Cairo\samples\sample_pango_text.jl, in expression starting on line 28

오류 메시지는 문제가 무엇인지에 대해 매우 명확하게 보입니다. Cairo 는 기본 메소드를 확장해야합니다.

help?>  Base.textwidth
  No documentation found.

  Binding Base.textwidth does not exist.

julia> versioninfo()
Julia Version 0.6.0

julia> Compat.textwidth
textwidth (generic function with 2 methods)

나는 메시지 (내가 travis를 통해 얻은)가 괜찮다는 것을 의심하지 않았지만 왜 Compat는 0.6이 아닌 경우 textwidth를 내보내나요?

그것이 Compat의 요점이기 때문에? 이 토론은 범위를 크게 벗어 났으므로 담론이나 여유로 계속 진행할 수 있습니다.

copy 를 shallowcopy 하고 deepcopy 를 copy 로 변경하는 것이 좋습니다. 최근 사본이 "얕은"사본이고 내가 작성한 함수는 배열의 배열을 변경하는 것입니다. copy 가 "깊은"복사를 수행하고 shallowcopy 와 같은 것을 얕은 복사에 사용하면 훨씬 더 직관적 일 것이라고 생각합니까? 지금 알고 있습니다. deepcopy 를 사용할 때 다른 많은 사용자가 동일한 문제에 부딪 힐 것이라고 생각합니다.

이 문제를 "내가 싫어하는 특정 항목"이 아닌 API 일관성을 위해 유지하도록 노력합시다.

Associative 이름이 Julia의 다른 모든 유형 이름과 상당히 일치하지 않는 것 같습니다.

첫째, 유형은 일반적으로 형용사가 아닙니다. 명사는 Association 이며 적어도 내가 찾은 일부 Mathematica 문서에서 사용됩니다.

AbstractDict 는 AbstractArray , AbstractRange , AbstractSet 및 AbstractString 와 같은 다른 유형과 훨씬 더 일관성이있을 것이라고 생각합니다 AbstractRange 프로토 타입 콘크리트 유형 Dict , Array , Range , Set 및 String .

예외 유형은 사방에 있습니다. 일부는 FooError 이고 다른 유형은 BarException . 일부는 내보내 지지만 대부분은 그렇지 않습니다. 일관성을 위해 통과를 사용할 수 있습니다.

그렇다면 FooError 또는 BarException 선호하는 것은 무엇입니까? 수출 여부?

저에게 BarException 은 어딘가에 모금 / 잡기 패턴을 포함합니다.

나는 많은 것을 선호하고 기능 세계의 다른 사람들도 제어 흐름이 더 직접적이고 예측 가능한 Some / None 패턴 (*)을 사용합니다.

따라서 FooError +1

(*) Some / Void ex Optional in Julia # 23642.

기능이 정지 된 상태에서 이러한 항목이 여전히 테이블에 있습니까? 특히 선택적 대 키워드 인수를 다루고 싶지만 여러 선택적 인수가있는 함수 목록 (대신 키워드 인수를 사용하는 가장 명확한 경우)은 꽤 깁니다.

이것을 봐주세요! 이러한 문제를 체계적으로 해결할 기회가 없었습니다.

BTW, 특성 이름 지정에 불일치가 있음을 확인 했습니다 : iteratorsize , iteratoreltype ,하지만 IndexStyle , TypeRangeStep , TypeArithmetic 및 TypeOrder . CamelCase 변형이 더 많고 최신 인 것처럼 보이므로 모든 곳에서 해당 규칙을 채택해야할까요?

그것들은 확실히 일관성이 있어야합니다. 홍보하고 싶습니까?

나는 이것이 https://github.com/JuliaLang/julia/pull/25356의 일부로 수정되어야한다고 생각합니다

편집 : https://github.com/JuliaLang/julia/issues/25440 참조

이것은 대부분 수행되거나 1.x 릴리스에서 수행 될 수 있습니다. 체크 박스를 업데이트 할 수 있지만, 분류 호출에서 체크 박스를 살펴 봤고 # 25395와 밑줄 감사를 제외한 모든 것이 완료되었습니다.

밑줄 감사

다음은 밑줄을 포함하고 더 이상 사용되지 않으며 문자열 매크로가 아닌 Base에서 내 보낸 모든 기호에 대한 분석입니다. 여기서 주목해야 할 중요한 점은이 이름이 내보내기 된 이름이라는 것입니다. 여기에는 사람들에게 적격이라고 부르는 수출되지 않은 이름은 포함되지 않습니다.

카테고리별로 구분했습니다. 그것이 성가신 것보다 더 유용하기를 바랍니다.

반사

해당 기능이있는 다음 매크로가 있습니다.

• [] @code_llvm , code_llvm
• [] @code_lowered , code_lowered
• [] @code_native , code_native
• [] @code_typed , code_typed
• [] @code_warntype , code_warntype

매크로에 적용되는 모든 변경 사항은 함수에도 유사하게 적용되어야합니다.

• [x] module_name -> nameof (# 25622)
• [x] module_parent -> parentmodule (# 25629, 이전 이름 ​​변경 시도는 # 25436 참조)
• [x] method_exists -> hasmethod (# 25615)
• [x] object_id -> objectid (# 25615)
• [] pointer_from_objref

pointer_from_objref 는 좀 더 설명적인 이름으로 할 수 있습니다. address ?

C interop의 별칭

밑줄이 포함 된 유형 별칭은 C_NULL , Cintmax_t , Cptrdiff_t , Csize_t , Cssize_t , Cuintmax_t 및 Cwchar_t _t 끝나는 이름은 해당 C 유형과 일치하도록 이름이 지정되므로 그대로 있어야합니다.

C_NULL 는 C에서 미러링되지 않는 밑줄을 포함하는 유일한 C 별칭입니다 (C에서는 NULL 이므로). 이것을 CNULL 라고 부르는 것을 고려할 수 있습니다.

• [] C_NULL

비트 카운팅

• [] count_ones
• [] count_zeros
• [] trailing_ones
• [] trailing_zeros
• [] leading_ones
• [] leading_zeros

이름 변경에 대한 설명은 # 23531을 참조하십시오. 나는 이것들에 대한 밑줄과 그 PR에서 제안 된 대체물 중 일부를 제거하는 것을 매우 선호합니다. 재고해야한다고 생각합니다.

안전하지 않은 작업

• [] unsafe_copyto!
• [] unsafe_load
• [] unsafe_pointer_to_objref
• [] unsafe_read
• [] unsafe_store!
• [] unsafe_string
• [] unsafe_trunc
• [] unsafe_wrap
• [] unsafe_write

이 상태로 유지하는 것이 좋습니다. 밑줄의 추악함은 그들의 위험성을 더욱 강조합니다.

인덱싱

• [] broadcast_getindex
• [] broadcast_setindex!
• [] to_indices

분명히 broadcast_getindex 및 broadcast_setindex! 가 존재합니다. 나는 그들이하는 일을 이해하지 못한다. 더 설명적인 이름을 사용할 수 있을까요?

흥미롭게도 to_indices , Base.to_index 의 단일 인덱스 버전은 내보내지지 않습니다.

흔적

• [] catch_backtrace
• [x] catch_stacktrace -> stacktrace(catch_backtrace()) (# 25615)

아마도 이들은 각각 backtrace 및 stacktrace 에 해당하는 catch 블록 일 것입니다.

작업, 프로세스 및 신호

• [] current_task
• [] task_local_storage
• [] disable_sigint
• [] reenable_sigint
• [] process_exited
• [] process_running

스트림

• [] redirect_stderr
• [] redirect_stdin
• [] redirect_stdout
• [x] nb_available -> bytesavailable (# 25634)

더 일반적인 IO -> IO 리디렉션 함수를 사용하면 이러한 모든 항목을 결합 할 수 있습니다 (예 : redirect(STDOUT, io) ). 그러면 밑줄과 내보내기가 모두 제거됩니다.

프로모션

• [] promote_rule
• [] promote_shape
• [] promote_type

promote_rule 에 대한 관련 토론은 # 23999를 참조하십시오.

인쇄

• [x] print_with_color -> printstyled (# 25522 참조)
• [] print_shortest (# 25745 참조)
• [] escape_string (# 25620 참조)
• [] unescape_string

escape_string 및 unescape_string 는 스트림으로 인쇄하거나 문자열을 반환 할 수 있다는 점에서 약간 이상합니다. 이동 / 이름 변경 제안은 # 25620을 참조하세요.

코드 로딩

• [] include_dependency
• [] include_string

include_dependency Base 외부에서도 사용됩니까? 일반적인 시나리오에서 include 대신 이것을 원하는 상황을 생각할 수 없습니다.

include_string 이것은 공식적으로 승인 된 eval(parse()) 버전이 아닙니까?

내가 분류하지 않은 것

• [x] gc_enable -> GC.enable (# 25616)
• [] get_zero_subnormals
• [] set_zero_subnormals
• [] time_ns

get_zero_subnormals 및 set_zero_subnormals 는 더 설명적인 이름을 사용할 수 있습니다. 내 보내야합니까?

method_exists => methodexists 및 object_id => objectid 대한 +1. catch_stacktrace 조차 존재하는 것도 어리석은 일입니다. stacktrace(catch_backtrace()) 정의로 더 이상 사용되지 않을 수 있습니다.

C_NULL 낮은 C* 이름에 밑줄이 없다는 주장도 삽니다.

다른 C 이름은 유형이고 C_NULL 는 상수입니다. 나는 그것이 어떻게 좋은지 생각하고 명명 지침을 따릅니다.

명명 지침을 따릅니다.

어떻게?

상수는 종종 모두 밑줄이있는 대문자입니다. C_NULL 뒤에옵니다. @ iamed2가 말했듯이 유형이 아니라 값이므로 Cfoo 명명 규칙이 반드시 적용되는 것은 아닙니다.

나는 실수로 https://github.com/JuliaLang/julia/blob/master/doc/src/manual/variables.md#stylistic -conventions가 상수를 참조한다고 생각했지만 그렇지 않습니다. 아마 그럴 것입니다.

벡터가 Julia 배열이 아닌 일반적인 힐베르트 공간에 대해 일관되고 수학적으로 건전한 인터페이스를 제안합니다. vecdot , vecnorm 등과 같은 함수 이름은 https : // github에 설명 된대로 inner 및 norm 의 일반 개념으로 대체 될 수 있습니다 . com / JuliaLang / julia / issues / 25565.

내가 몇 번 말했듯이, 이것은 사람이 바꾸고 싶은 것에 대한 포괄적 인 문제가 아닙니다.

이 우산 아래 1.0에 남아있는 유일한 항목은 # 25501과 # 25717입니다.

(get|set)_zero_subnormals 뭔가를하고 싶지만 가장 좋은 단기 해결책은 그냥 내 보내지 않는 것입니다.

아마도 검토해야 할 것은 map 및 collect 와 같은 컬렉션 작업의 컨텍스트에서 숫자가 처리되는 방식입니다. 전자는 스칼라를 반환하지만 후자는 0D 배열을 반환한다는 지적 이있었습니다.