ประสบการณ์การทำงานของ Python“ PEP-302 ใหม่นำเข้า hooks” [ปิด]

ฉันเป็นหนึ่งในนักพัฒนาของ Ruby (CRuby) เรากำลังทำงานกับการเปิดตัว Ruby 2.0 (วางแผนที่จะเปิดตัว 2012 / กุมภาพันธ์)

Python มี"PEP302: hooks นำเข้าใหม่" (2003):

PEP นี้เสนอให้เพิ่มชุดนำเข้า hooks ใหม่ที่เสนอการปรับแต่งที่ดีขึ้นของกลไกการนำเข้า Python ตรงกันข้ามกับตะขอนำเข้าปัจจุบันตะขอรูปแบบใหม่สามารถถูกแทรกลงในโครงร่างที่มีอยู่ได้เพื่อให้สามารถควบคุมได้ละเอียดยิ่งขึ้นว่าโมดูลถูกค้นพบได้อย่างไรและโหลดอย่างไร

เรากำลังพิจารณาที่จะเปิดตัวฟีเจอร์ที่คล้ายกับ PEP302 ไปสู่ ​​Ruby 2.0 (CRuby 2.0) ฉันต้องการยื่นข้อเสนอที่สามารถชักชวน Matz ปัจจุบัน CRuby สามารถโหลดสคริปต์จากระบบไฟล์ในแบบมาตรฐานเท่านั้น

หากคุณมีประสบการณ์หรือข้อพิจารณาเกี่ยวกับ PEP 302 โปรดแบ่งปัน

ตัวอย่าง:

1. มันเป็นสเป็คที่ยอดเยี่ยม ไม่จำเป็นต้องเปลี่ยน
2. เกือบดี แต่มีปัญหานี้ ...
3. ถ้าฉันสามารถย้อนกลับไปปี 2003 ได้ฉันจะเปลี่ยนสเป็คเป็น ...

ฉันเป็นผู้ดูแลโมดูล Runpy ของ Python และเป็นหนึ่งในผู้ดูแลระบบการนำเข้าในปัจจุบัน ในขณะที่ระบบการนำเข้าของเรานั้นมีความยืดหยุ่นอย่างน่าประทับใจ แต่ผมขอแนะนำไม่ให้ใช้การขายส่งโดยไม่ต้องปรับแต่งเล็กน้อย - เนื่องจากข้อกังวลเกี่ยวกับความเข้ากันได้ของระบบย้อนหลัง

สิ่งหนึ่งที่เจ็บปวดกับ PEP 302 ใน Python คือระยะเวลาที่เราใช้ในการแปลงระบบการนำเข้าหลักไปใช้ สำหรับส่วนที่ดีขึ้นของทศวรรษใคร ๆ ก็ทำอะไรที่ซับซ้อนด้วย hooks นำเข้าติดดำเนินการสองชิ้น: หนึ่งจัดการ PEP 302 รถตักที่สอดคล้อง (เช่นการนำเข้า zip) และการจัดการที่สองกลไกการนำเข้าระบบไฟล์มาตรฐาน เฉพาะในอนาคตที่จะถึงนี้ 3.3 ที่จัดการ PEP 302 loader จะดูแลจัดการโมดูลที่อิมพอร์ตผ่านกลไกการนำเข้าระบบไฟล์มาตรฐาน พยายามอย่าทำผิดซ้ำ ๆ หากคุณสามารถหลีกเลี่ยงได้

PEP 420 (นำไปใช้กับ Python 3.3) ทำให้การเพิ่มเติมบางอย่างในโปรโตคอลเพื่อให้ผู้นำเข้ามีส่วนร่วมในแพ็คเกจเนมสเปซ นอกจากนี้ยังแก้ไขปัญหาการตั้งชื่อในคำจำกัดความ Finder API (แทนที่ "find_module" ที่มีชื่อไม่ถูกต้องด้วย "find_loader" ที่แม่นยำยิ่งขึ้น) หวังว่าทั้งหมดนี้จะได้รับการบันทึกไว้อย่างชัดเจนในสเป็คภาษาตามเวลาที่ 3.3rc1 หมุนรอบในเวลาสองสามสัปดาห์

ปัญหาที่น่าสังเกตอีกประการหนึ่งก็คือวิธีการจัดทำเอกสารโดยเฉพาะใน PEP 302 นั้นมีกระบวนการทางรัฐทั่วโลกมากเกินไป อย่าตามพวกเราไปตามเส้นทางนั้น - ลองห่อหุ้มสถานะในโมเดลวัตถุที่สอดคล้องกันมากขึ้นดังนั้นจึงง่ายขึ้นเล็กน้อยที่จะเลือกนำเข้าโมดูลอื่น ๆ (โมดูลส่วนขยาย C เป็นสิ่งที่ขาดไม่ได้ในการทำให้การห่อหุ้มมีประสิทธิภาพอย่างสมบูรณ์ มีประโยชน์)

PEP 406 (http://www.python.org/dev/peps/pep-0406/) กล่าวถึงวิวัฒนาการที่เข้ากันได้ย้อนหลังของแนวทางของ Python พร้อมการห่อหุ้มสถานะที่ดีขึ้น หากคุณมีโมเดลสภาวะห่อหุ้มตั้งแต่เริ่มต้นคุณสามารถกำหนด API ของคุณได้ตามความต้องการและหลีกเลี่ยงการให้ผู้นำเข้าและรถตักสามารถเข้าถึงสถานะทั่วโลกได้เลย

ชิ้นส่วนที่ขาดหายไปอีกชิ้นใน PEP 302 คือความสามารถในการขอผู้นำเข้าตัววนซ้ำสำหรับโมดูลที่จัดหาโดยผู้นำเข้านั้น (จำเป็นสำหรับสิ่งต่างๆเช่นยูทิลิตี้ค้างและยูทิลิตี้เอกสารอัตโนมัติที่ดึงเอกสาร) เนื่องจากมันมีประโยชน์อย่างไม่น่าเชื่อคุณอาจจะดีกว่าที่จะทำให้มันเป็นมาตรฐานตั้งแต่เริ่มต้น: http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules (เราจะยกระดับสิ่งนี้ให้เป็นรูปแบบที่ระบุไว้อย่างเป็นทางการ API ใน Python 3.4)

และความคิดเห็นสุดท้ายของฉันคือคุณควรดูการแบ่งความรับผิดชอบอย่างใกล้ชิดระหว่างระบบการนำเข้าและวัตถุตัวโหลด โดยเฉพาะอย่างยิ่งให้พิจารณาแยก "load_module" API เป็นขั้นตอน "init_module" และ "exec_module" แยกต่างหาก ซึ่งจะช่วยให้คุณลดระดับที่ตัวตักจำเป็นต้องโต้ตอบโดยตรงกับสถานะการนำเข้า

PEP 302 และ importlib เป็นจุดเริ่มต้นที่ดีสำหรับระบบการนำเข้าที่ยืดหยุ่นมากขึ้น แต่มีข้อผิดพลาดอย่างแน่นอนที่เราทำซึ่งควรหลีกเลี่ยง

ถัดจาก ncoghlan ฉันเป็นผู้ดูแลระบบการนำเข้าของ Python และเป็นผู้สร้างการนำไปใช้ในปัจจุบันคือ importlib (http://docs.python.org/dev/py3k/library/importlib.html) ทุกอย่างที่ Nick พูดว่าฉันเห็นด้วยดังนั้นฉันแค่ต้องการเพิ่มข้อมูลพิเศษ

ก่อนอื่นอย่าพึ่งพา PEP 302 มากเกินไปโดยตรง แต่ลองดูว่า importlib มีอะไรบ้างในแง่ของคลาสพื้นฐานที่เป็นนามธรรมเป็นต้นสำหรับความเข้ากันได้แบบย้อนหลังนั้นต้องเข้ากันได้กับ PEP 302 แต่ฉันต้องเพิ่มบางส่วนของฉัน API ของตัวเองเพื่อเสร็จสิ้นการสนับสนุนให้มีความยืดหยุ่นอย่างแท้จริง

อีกจุดสำคัญคือคุณให้ความยืดหยุ่นกับนักพัฒนาสองส่วน หนึ่งคือความสามารถในการจัดเก็บรหัสในวิธีอื่นนอกเหนือจากระบบไฟล์โดยตรงเป็นไฟล์เดี่ยว ๆ (ฉันเรียกสิ่งนี้ว่าback-end ของที่เก็บข้อมูลสำหรับการนำเข้า) เช่นนี่เป็นการอนุญาตให้โค้ดอยู่ในไฟล์ zip ฐานข้อมูล sqlite เป็นต้น การสนับสนุนอื่น ๆ คือการอนุญาตให้ควบคุมโค้ดก่อนหรือหลังกระบวนการในบางวิธีเช่น Quixote (https://www.mems-exchange.org/software/quixote/) และการใช้ทางเลือกของตัวอักษรสตริงที่ไม่ได้กำหนดให้ ตัวแปรจะสนับสนุนได้ง่ายกว่ามาก

ในขณะที่ต้องการหลังไม่ค่อยมีอดีตคือที่คุณต้องกังวลเกี่ยวกับการสนับสนุน และนี่คือที่ที่คุณจะต้องกำหนด API การโต้ตอบของระบบไฟล์ใหม่ เนื่องจากบางคนต้องการสินทรัพย์ที่จัดเก็บเป็นไฟล์พร้อมรหัสคุณจึงต้องเตรียมวิธีที่ดีในการอ่านไฟล์ค้นหาไฟล์ ฯลฯ เรายังต้องใช้ส่วนของ API เพื่อค้นหาไฟล์ข้อมูลที่มีอยู่แสดงรายการ ฯลฯ .

แต่คุณต้องมี API ที่เป็นรหัสเฉพาะด้วย ดังที่ Nick ได้กล่าวไว้คุณต้องใช้ API ในการค้นหาโมดูลที่มีในแพ็คเกจ ฯลฯ ซึ่งไม่ได้เจาะจงเฉพาะไฟล์ มีความเป็นคู่แปลก ๆ ที่มี API สำหรับจัดการกับโมดูลที่คุณแยกแนวคิดของไฟล์ออกไป แต่สุดท้ายคุณก็จำเป็นต้องให้ APIs เข้าถึงข้อมูลสินทรัพย์ที่มีลักษณะเหมือนไฟล์ และทันทีที่คุณพยายามที่จะใช้อันใดอันหนึ่งเพื่อหลีกเลี่ยงการซ้ำซ้อนน่านน้ำจะมืดมนจริงๆ (เช่นคนที่ต้องพึ่งพาโครงสร้างไฟล์พา ธ ที่คาดหวัง ฯลฯ โดยไม่สนใจความจริงเส้นทางอาจไม่ใช่เส้นทางที่แท้จริง เพราะมันเป็นไฟล์ zipfile ที่มีรหัสไม่ใช่แค่ไฟล์) IOW คุณจะต้องใช้ API ที่คล้ายกันสองตัว แต่คุณจะดีขึ้นในระยะยาว

ดังที่ Nick กล่าวว่าวิธีแก้ปัญหาของเราเป็นจุดเริ่มต้นที่ดี แต่ไม่ใช่ว่าฉันจะทำวันนี้ถ้าฉันออกแบบ API ตั้งแต่เริ่มต้น

PEP 302 ช่วยให้คุณสามารถเชื่อมโยงไปยังกลไกการนำเข้า Python ซึ่งหมายความว่าคุณสามารถนำเข้ารหัสจากแหล่งอื่นเช่นฐานข้อมูลไฟล์ซิปและอื่น ๆ

ในการอิมพลีเมนต์ Python ของการนำเข้ามีประวัติอันยาวนานของความซับซ้อนที่จะทำให้เข้าใจได้ง่ายในไม่ช้าโดยการนำ Python มาใช้ในการนำเข้า

ฉันควรจะแนะนำให้คิดยาวและหนักหน่วงเกี่ยวกับเคสมุม ถ้าอย่างนั้นคุณก็น่าจะได้ประโยชน์