Python 커널 재시작 메커니즘 제공이러한 위시리스트 요청을 하게 된 계기는 무엇이었나요?
JMP에서 실행하기 위한 Python 코드를 개발하려면 일반적으로 Github 저장소를 복제하고 JMP를 다음과 같이 코드의 로컬 복사본으로 지정해야 합니다.
jmputils.jpip('install','myrepo c:\\pathto\\myrepo')
어떤 개선을 원하시나요?
사용자가 JMP를 닫았다가 다시 열지 않고도 Python 커널을 다시 시작할 수 있는 메커니즘(버튼, API, ??)을 제공합니다.
왜 이 아이디어가 중요한가요?
코드 개발 중에 로컬 코드에 수많은 변경 사항이 있으며, 각각 새 코드를 Python 커널에 로드해야 합니다. 현재 Python 커널에 새 로컬 코드를 로드하는 유일한 방법은 JMP를 닫았다가 다시 시작하는 것입니다. 이렇게 하면 개발 속도가 상당히 느려지고 일부 개발자에게는 방해가 될 수 있습니다.
자동화 및 스크립팅Re: Python 커널 재시작 메커니즘 제공먼저 편집기에서 코드를 변경하고 다시 실행하면 변경 사항이 적용됩니다.
가져온 코드라면
mycode를 가져오다
# 'mycode' 패키지를 강제로 다시 로드해야 할 때
import importlib
importlib.reload(내 코드)
이는 기존 Python 동작입니다. 대부분의 경우 Python이 명령줄에서 실행되고 스크립트 와 Python이 실행 사이에 종료되기 때문에 이 동작을 볼 수 없습니다. JMP가 Python 공유 라이브러리를 로드하므로 이러한 경우 JMP를 Python으로 생각해야 합니다. Python 대화형 콘솔(예: IDLE)에서 동일한 작업을 수행하여 변경 사이에 종료하지 않으면 동일한 동작을 볼 수 있습니다. Python 환경은 환경이 공유되기 때문에 JMP가 종료될 때까지 처음 사용할 때부터 라이브 상태를 유지합니다. 이것이 JSL/Python 통합이 구현될 수 있는 방법입니다.
아니요, importlib.reload(package)가 이 요구를 충족하기 때문에 지금은 '재시작'을 제공하지 않습니다.
독립적인 Python 하위 인터프리터를 시작하는 기능을 조사하고 있습니다. 이를 통해 필요할 때 더 깨끗한 환경에서 스크립트를 실행하는 것과 같은 많은 추가 기능을 사용할 수 있습니다. 하위 인터프리터에 대한 조사는 JMP 19가 Python 3.13.x로 업그레이드되는 이유 중 하나입니다. 업데이트 및 보안 라이프사이클은 3.13.x 업데이트의 주요 원동력입니다.
Re: Python 커널 재시작 메커니즘 제공 - 상태가 현재 계획되지 않음으로 변경됨Re: Python 커널 재시작 메커니즘 제공음. 저는 백그라운드에서 다른 Python 스크립트 창과 작업 간에 모든 변수를 공유할 수 있는 가능성을 즐깁니다.
Application Builder에 이런 옵션이 있었으면 좋겠네요!
하지만 솔직히 조금 "실험적"이라는 느낌이 듭니다.
재시작을 통해 커널을 재설정하는 것은 1995년 이래로 우리에게 익숙한 방식입니다. 매우 편안합니다.
다른 많은 (!!!) Python IDE가 이 기능을 제공하는데, 다른 IDE는 코드를 실행한 후 커널을 닫습니다.
"더 깨끗한 환경에서 스크립트 실행"
... 유망한 것 같네요.
그러면 해당 하위 통역사를 시작(또는 재시작)하는 것이 자동으로 가능해질 겁니다.
왜 "아니요"인지 궁금하네요. 이게 JMP에서 놓친 기능을 제공해주는 건가요?
Re: Python 커널 재시작 메커니즘 제공가장 큰 문제는 메모리에 로드된 공유 라이브러리를 실행 중인 프로세스에서 언로드할 수 없다는 것입니다. 이는 Python 자체뿐만 아니라 NumPy와 같은 공유 라이브러리가 있는 가져온 Python 패키지에도 적용됩니다. Python은 다른 프로세스 공간에서 실행되지 않고 JMP 자체 내에서 일부로 실행됩니다. 예, Py_Finalize()를 호출할 수 있으며 이후 Py_Initialize()를 호출하여 인터프리터를 두 번째로 초기화할 수 있습니다. 과거에 제가 겪었던 문제는 NumPy가 두 번째 인터프리터 초기화 후 가져오기에 특별히 잘 반응하지 않았다는 것입니다. JMP가 불안정해지고 충돌이 발생하기 쉬웠으며, 특히 재시작 후 NumPy를 가져올 때 그러했습니다. 다른 IDE가 Python을 어떻게 처리하는지는 살펴보지 않았지만 Python을 내장하는 대신 Python 인스턴스를 실행하고 있을 가능성이 큽니다.
우리는 이전 버전에서 JMP 18의 메모리 처리를 꽤 많이 정리했으므로, 이런 재시작이 가능한지 확인하기 위해 이것을 다시 살펴볼 가치가 있을 수 있습니다. 그것은 우리의 메모리 처리였을 수도 있고, 공유 라이브러리를 로드하는 NumPy 및 기타 패키지의 문제일 수도 있습니다.
