ทำไมถึงมีงูหลามจำนวนมาก? การเปรียบเทียบการใช้งาน Python

ไพทอนน่าทึ่งมาก

น่าแปลกที่เป็นข้อความที่ค่อนข้างคลุมเครือ ฉันหมายถึงอะไรโดย 'Python' ฉันหมายถึง Python อินเทอร์เฟซ แบบนามธรรมหรือไม่ ฉันหมายถึง CPython การ ใช้งาน Python ทั่วไปหรือไม่ (และไม่ต้องสับสนกับ Cython ที่มีชื่อคล้ายกัน) หรือฉันหมายถึงอย่างอื่นทั้งหมด? บางทีฉันอาจหมายถึง Jython หรือ IronPython หรือ PyPy อย่างอ้อมค้อม หรือบางทีฉันอาจออกจากส่วนลึกไปแล้วและฉันกำลังพูดถึง RPython หรือ RubyPython (ซึ่งแตกต่างกันมาก)

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

ตลอดเวลาที่ฉันทำงานกับอินเทอร์เฟซ Python ฉันได้ใช้งานเครื่องมือ .*ython เหล่านี้เป็นจำนวนมาก แต่เมื่อไม่นานมานี้ ฉันไม่ได้ใช้เวลาในการทำความเข้าใจว่ามันคืออะไร ทำงานอย่างไร และทำไมจึงจำเป็น (ในแบบของพวกเขาเอง)

ในบทช่วยสอนนี้ ฉันจะเริ่มต้นจากศูนย์และย้ายไปยังการใช้งาน Python ต่างๆ โดยปิดท้ายด้วยการแนะนำ PyPy อย่างละเอียด ซึ่งฉันเชื่อว่าเป็นอนาคตของภาษา

ทุกอย่างเริ่มต้นด้วยความเข้าใจว่า 'Python' คืออะไรจริงๆ

หากคุณมีความเข้าใจเป็นอย่างดีเกี่ยวกับรหัสเครื่อง เครื่องเสมือน และอื่นๆ โปรดข้ามไปข้างหน้า

“ Python ถูกตีความหรือรวบรวมหรือไม่”

นี่เป็นจุดที่ทำให้เกิดความสับสนสำหรับผู้เริ่มต้นใช้งาน Python

สิ่งแรกที่ต้องตระหนักเมื่อทำการเปรียบเทียบคือ 'Python' คือ อินเทอร์เฟซ มีข้อกำหนดของสิ่ง ที่ Python ควร ทำและพฤติกรรมของมัน (เช่นเดียวกับอินเทอร์เฟซอื่นๆ) และมี การใช้งาน หลายอย่าง (เช่นเดียวกับอินเทอร์เฟซใด ๆ )

สิ่งที่สองที่ต้องตระหนักคือ 'ตีความ' และ 'คอมไพล์' เป็นคุณสมบัติของการ ใช้งาน ไม่ใช่ อินเทอร์เฟซ

ดังนั้นคำถามจึงไม่ได้มีรูปแบบที่ดีจริงๆ

ที่กล่าวว่าสำหรับการใช้งาน Python ทั่วไป (CPython: เขียนในภาษา C มักเรียกง่ายๆว่า 'Python' และแน่นอนว่าคุณใช้อะไรอยู่หากคุณไม่รู้ว่าฉันกำลังพูดถึงอะไร) คำตอบคือ: ตีความ ด้วยการรวบรวม บางส่วน CPython คอมไพล์ * ซอร์สโค้ด Python เป็น bytecode จากนั้น ตีความ bytecode นี้ ดำเนินการตามที่เกิดขึ้น

* หมายเหตุ: นี่ไม่ใช่ 'การรวบรวม' ในความหมายดั้งเดิมของคำ โดยทั่วไป เราจะบอกว่า 'การคอมไพล์' ใช้ภาษาระดับสูงและแปลงเป็นรหัสเครื่อง แต่เป็น 'การเรียบเรียง'

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

Bytecode เทียบกับรหัสเครื่อง

สิ่งสำคัญคือต้องเข้าใจความแตกต่างระหว่าง bytecode กับรหัสเครื่อง (aka โค้ดเนทีฟ) อาจแสดงให้เห็นได้ดีที่สุดด้วยตัวอย่าง:

• C คอมไพล์เป็นรหัสเครื่อง ซึ่งจะรันบนโปรเซสเซอร์ของคุณโดยตรง แต่ละคำสั่งจะสั่งให้ CPU ของคุณเคลื่อนย้ายสิ่งต่างๆ
• Java คอมไพล์เป็น bytecode ซึ่งรันบน Java Virtual Machine (JVM) ซึ่งเป็นนามธรรมของคอมพิวเตอร์ที่รันโปรแกรม แต่ละคำสั่งจะได้รับการจัดการโดย JVM ซึ่งโต้ตอบกับคอมพิวเตอร์ของคุณ

กล่าวโดยย่อ: รหัสเครื่องเร็วกว่ามาก แต่ bytecode นั้นพกพาได้และปลอดภัย กว่า

รหัสเครื่องจะดูแตกต่างกันไปขึ้นอยู่กับเครื่องของคุณ แต่ bytecode จะเหมือนกันในทุกเครื่อง อาจมีคนบอกว่ารหัสเครื่องได้รับการปรับให้ เหมาะ กับการตั้งค่าของคุณ

กลับไปที่การนำ CPython ไปใช้งาน กระบวนการ toolchain มีดังนี้:

1. CPython รวบรวมซอร์สโค้ด Python ของคุณเป็น bytecode
2. bytecode นั้นจะถูกดำเนินการบน CPython Virtual Machine

VM ทางเลือก: Jython, IronPython และอื่นๆ

ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้ Python มีการนำไปใช้งาน หลาย อย่าง ดังที่ได้กล่าวไว้ก่อนหน้านี้ CPython ที่พบบ่อยที่สุดคือ แต่มีสิ่งอื่นที่ควรกล่าวถึงเพื่อประโยชน์ของคู่มือการเปรียบเทียบนี้ นี่เป็นการใช้งาน Python ที่เขียนด้วยภาษา C และถือเป็นการใช้งาน 'เริ่มต้น'

แล้วการใช้งาน Python ทางเลือกล่ะ? ที่โดดเด่นกว่าคือ Jython ซึ่งเป็นการนำ Python ไปใช้งานที่เขียนด้วย Java ที่ใช้ JVM ในขณะที่ CPython สร้าง bytecode เพื่อทำงานบน CPython VM, Jython สร้าง Java bytecode เพื่อรันบน JVM (นี่เป็นสิ่งเดียวกันกับที่เกิดขึ้นเมื่อคุณคอมไพล์โปรแกรม Java)

“ทำไมคุณถึงใช้วิธีอื่น?” คุณอาจถาม ประการหนึ่ง การใช้งาน Python ที่แตกต่างกันเหล่านี้เล่นได้ดีกับเทคโนโลยี stacks ที่แตกต่างกัน

CPython ช่วยให้เขียน C-extensions สำหรับโค้ด Python ได้ง่ายมาก เพราะในท้ายที่สุดมันจะถูกเรียกใช้งานโดยล่ามภาษา C ในทางกลับกัน Jython ทำให้การทำงานกับโปรแกรม Java อื่นๆ ทำได้ง่ายมาก: คุณสามารถนำเข้าคลาส Java ใดๆ โดยไม่ต้องใช้ความพยายามเพิ่มเติม เรียกและใช้งานคลาส Java ของคุณจากภายในโปรแกรม Jython ของคุณ (นอกเสียจาก: ถ้าคุณไม่ได้คิดเรื่องนี้ให้ละเอียด นี่มันบ้าจริงๆ เราอยู่ในจุดที่คุณสามารถผสมและผสมภาษาต่างๆ และคอมไพล์มันทั้งหมดลงไปที่เนื้อหาเดียวกันได้ (ตามที่ Rostin ได้กล่าวไว้ โปรแกรมที่ มีโค้ดผสม Fortran และ C มาระยะหนึ่งแล้ว แน่นอนว่านี่ไม่ใช่เรื่องใหม่ แต่มันก็ยังเจ๋งอยู่))

ตัวอย่างเช่น นี่คือรหัส Jython ที่ถูกต้อง:

 [Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51 >>> from java.util import HashSet >>> s = HashSet(5) >>> s.add("Foo") >>> s.add("Bar") >>> s [Foo, Bar]

IronPython เป็นอีกหนึ่งการใช้งาน Python ที่ได้รับความนิยม โดยเขียนด้วยภาษา C# ทั้งหมด และกำหนดเป้าหมายไปที่ .NET stack โดยเฉพาะอย่างยิ่ง มันทำงานบนสิ่งที่คุณอาจเรียกว่า .NET Virtual Machine ซึ่งเป็น Common Language Runtime (CLR) ของ Microsoft ซึ่งเทียบได้กับ JVM

คุณอาจบอกว่า Jython : Java :: IronPython : C# พวกมันทำงานบน VM ตามลำดับ คุณสามารถนำเข้าคลาส C# จากโค้ด IronPython และคลาส Java จากโค้ด Jython ของคุณ ฯลฯ

เป็นไปได้โดยสิ้นเชิงที่จะอยู่รอดโดยไม่ต้องสัมผัสกับการใช้งาน Python ที่ไม่ใช่ CPython แต่มีข้อดีที่ควรได้รับจากการเปลี่ยน ซึ่งส่วนใหญ่ขึ้นอยู่กับกลุ่มเทคโนโลยีของคุณ ใช้ภาษาที่ใช้ JVM เป็นจำนวนมากหรือไม่ Jython อาจเหมาะสำหรับคุณ ทุกอย่างเกี่ยวกับ .NET stack? บางทีคุณควรลอง IronPython (และบางทีคุณอาจมีอยู่แล้ว)

ยังไงก็ตาม: แม้ว่านี่จะไม่ใช่ เหตุผลที่ จะใช้การนำไปใช้งานที่แตกต่างออกไป แต่โปรดทราบว่าการใช้งานเหล่านี้จริง ๆ แล้วมีพฤติกรรมที่แตกต่างออกไปนอกเหนือจากวิธีที่พวกเขาปฏิบัติต่อซอร์สโค้ด Python ของคุณ อย่างไรก็ตาม ความแตกต่างเหล่านี้มักมีเพียงเล็กน้อย และจะค่อยๆ หายไปหรือปรากฏขึ้นเมื่อเวลาผ่านไป เนื่องจากการใช้งานเหล่านี้อยู่ภายใต้การพัฒนาอย่างแข็งขัน ตัวอย่างเช่น IronPython ใช้สตริง Unicode ตามค่าเริ่มต้น อย่างไรก็ตาม CPython มีค่าเริ่มต้นเป็น ASCII สำหรับเวอร์ชัน 2.x (ล้มเหลวด้วย UnicodeEncodeError สำหรับอักขระที่ไม่ใช่ ASCII) แต่รองรับสตริง Unicode โดยค่าเริ่มต้นสำหรับ 3.x

การรวบรวมแบบทันเวลา: PyPy และอนาคต

ดังนั้นเราจึงมีการใช้งาน Python ที่เขียนด้วยภาษา C หนึ่งรายการใน Java และอีกหนึ่งรายการใน C# ขั้นตอนต่อไปของตรรกะ: การใช้งาน Python ที่เขียนใน… Python (ผู้อ่านที่มีการศึกษาจะสังเกตว่าสิ่งนี้ทำให้เข้าใจผิดเล็กน้อย)

นี่คือสิ่งที่อาจสร้างความสับสน ก่อนอื่น เรามาพูดถึงการรวบรวม Just-in-time (JIT) กันก่อน

JIT: ทำไมและอย่างไร

จำได้ว่ารหัสเครื่องดั้งเดิมนั้นเร็วกว่า bytecode มาก แล้วถ้าเราสามารถคอมไพล์ bytecode บางส่วนของเราแล้วรันเป็นโค้ดเนทีฟล่ะ? เราต้องจ่ายราคาบางส่วนเพื่อคอมไพล์ bytecode (เช่น เวลา) แต่ถ้าผลลัพธ์ที่ได้เร็วกว่านั้นก็จะดีมาก! นี่คือแรงจูงใจของการรวบรวม JIT ซึ่งเป็นเทคนิคไฮบริดที่ผสมผสานประโยชน์ของล่ามและคอมไพเลอร์ ในแง่พื้นฐาน JIT ต้องการใช้การคอมไพล์เพื่อเร่งความเร็วของระบบที่ตีความ

ตัวอย่างเช่น วิธีการทั่วไปที่ใช้โดย JITs:

1. ระบุ bytecode ที่ถูกเรียกใช้งานบ่อยๆ
2. รวบรวมเป็นรหัสเครื่องดั้งเดิม
3. แคชผลลัพธ์
4. เมื่อใดก็ตามที่ตั้งค่าให้รัน bytecode เดียวกัน ให้คว้าโค้ดเครื่องที่คอมไพล์ไว้ล่วงหน้าและเก็บเกี่ยวผลประโยชน์ (เช่น การเพิ่มความเร็ว) แทน

นี่คือสิ่งที่เกี่ยวกับการนำ PyPy ไปใช้งาน: การนำ JIT ไปยัง Python (ดู ภาคผนวก สำหรับความพยายามครั้งก่อน) แน่นอนว่ายังมีเป้าหมายอื่นๆ อีก: PyPy ตั้งเป้าที่จะข้ามแพลตฟอร์ม หน่วยความจำเบา และรองรับการทับซ้อนกัน แต่ JIT เป็นจุดขายของมันจริงๆ จากการทดสอบโดยเฉลี่ยหลายครั้ง ได้มีการกล่าวกันว่าสามารถปรับปรุงประสิทธิภาพได้ 6.27 เท่า สำหรับรายละเอียด โปรดดูแผนภูมินี้จาก PyPy Speed ​​Center:

PyPy นั้นยากที่จะเข้าใจ

PyPy มีศักยภาพมหาศาล และ ณ จุดนี้มันเข้ากันได้กับ CPython อย่างมาก (ดังนั้นจึงสามารถเรียกใช้ Flask, Django เป็นต้น)

แต่มีความสับสนมากมายเกี่ยวกับ PyPy (ดูตัวอย่าง ข้อเสนอที่ไร้สาระนี้เพื่อสร้าง PyPyPy…) ในความคิดของฉัน นั่นเป็นเพราะว่าจริงๆ แล้ว PyPy เป็นสองสิ่ง:

1. ล่าม Python ที่เขียนด้วย RPython (ไม่ใช่ Python (ฉันเคยโกหกมาก่อน)) RPython เป็นเซตย่อยของ Python ที่มีการพิมพ์แบบสแตติก ใน Python นั้น “แทบจะเป็นไปไม่ได้เลย” ที่จะให้เหตุผลอย่างเข้มงวดเกี่ยวกับประเภท (ทำไมมันจึงยากนัก ให้พิจารณาข้อเท็จจริงที่ว่า:

    x = random.choice([1, "foo"])

   จะเป็นรหัส Python ที่ถูกต้อง (ให้เครดิตกับ Ademan) ชนิดของ x คืออะไร? เราจะให้เหตุผลเกี่ยวกับประเภทของตัวแปรได้อย่างไรในเมื่อประเภทไม่ได้บังคับใช้อย่างเข้มงวด) ด้วย RPython คุณยอมเสียความยืดหยุ่นบางอย่างไป แต่แทนที่จะทำให้เหตุผลเกี่ยวกับการจัดการหน่วยความจำและสิ่งอื่น ๆ ง่ายขึ้นมาก ซึ่งช่วยให้สามารถเพิ่มประสิทธิภาพได้

2. คอมไพเลอร์ที่คอมไพล์โค้ด RPython สำหรับเป้าหมายต่างๆ และเพิ่มใน JIT แพลตฟอร์มเริ่มต้นคือ C นั่นคือคอมไพเลอร์ RPython-to-C แต่คุณสามารถกำหนดเป้าหมาย JVM และอื่นๆ ได้

เพื่อความชัดเจนในคู่มือเปรียบเทียบ Python นี้ ฉันจะอ้างถึงสิ่งเหล่านี้เป็น PyPy (1) และ PyPy (2)

ทำไมคุณถึงต้องการสองสิ่งนี้และทำไมต้องอยู่ภายใต้หลังคาเดียวกัน? คิดแบบนี้: PyPy (1) เป็นล่ามที่เขียนด้วย RPython ดังนั้นจึงใช้โค้ด Python ของผู้ใช้และคอมไพล์เป็น bytecode แต่ตัวล่ามเอง (เขียนใน RPython) จะต้องถูกตีความโดยการใช้ Python อื่นเพื่อเรียกใช้ใช่ไหม

เราสามารถใช้ CPython เพื่อเรียกใช้ล่ามได้ แต่นั่นจะไม่เร็วมาก

แนวคิดก็คือเราใช้ PyPy (2) (เรียกว่า RPython Toolchain) เพื่อรวบรวมล่ามของ PyPy ลงไปเป็นโค้ดสำหรับแพลตฟอร์มอื่น (เช่น C, JVM หรือ CLI) เพื่อรันบนเครื่องของเรา โดยเพิ่ม JIT เป็น ดี. มันวิเศษมาก: PyPy เพิ่ม JIT ให้กับล่ามแบบไดนามิกสร้างคอมไพเลอร์ของตัวเอง! ( อีกครั้งที่มันไร้สาระ: เรากำลังรวบรวมล่าม เพิ่มในคอมไพเลอร์แบบสแตนด์อโลนที่แยกจากกันอีกตัวหนึ่ง )

ในท้ายที่สุด ผลลัพธ์ที่ได้คือไฟล์เรียกทำงานแบบสแตนด์อโลนที่ตีความซอร์สโค้ดของ Python และใช้ประโยชน์จากการเพิ่มประสิทธิภาพ JIT ซึ่งเป็นสิ่งที่เราต้องการ! เป็นคำหนึ่ง แต่บางทีแผนภาพนี้อาจช่วยได้:

เพื่อย้ำอีกครั้งว่าความงามที่แท้จริงของ PyPy ก็คือเราสามารถเขียนล่าม Python หลายๆ ตัวใน RPython ด้วยตัวเองโดยไม่ต้องกังวลเกี่ยวกับ JIT จากนั้น PyPy จะใช้งาน JIT ให้เรา โดยใช้ RPython Toolchain/PyPy (2)

ที่จริงแล้ว หากเราได้สิ่งที่เป็นนามธรรมมากขึ้น ในทางทฤษฎี คุณสามารถเขียนล่ามสำหรับภาษา ใดก็ได้ ป้อนให้ PyPy และรับ JIT สำหรับภาษานั้น นี่เป็นเพราะ PyPy มุ่งเน้นที่การเพิ่มประสิทธิภาพล่ามจริง มากกว่ารายละเอียดของภาษาที่กำลังแปล

พูดนอกเรื่องสั้น ๆ ฉันอยากจะพูดถึงว่า JIT นั้นน่าทึ่งมาก มันใช้เทคนิคที่เรียกว่าการติดตาม ซึ่งดำเนินการดังนี้:

1. เรียกใช้ล่ามและตีความทุกอย่าง (เพิ่มในไม่มี JIT)
2. ทำโปรไฟล์เล็กน้อยของโค้ดที่แปลแล้ว
3. ระบุการดำเนินการที่คุณเคยทำมาก่อน
4. รวบรวมบิตของรหัสเหล่านี้ลงไปที่รหัสเครื่อง

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

ในการสรุป: เราใช้คอมไพเลอร์ RPython-to-C ของ PyPy (หรือแพลตฟอร์มเป้าหมายอื่น) เพื่อรวบรวมล่ามที่ใช้ RPython ของ PyPy

ห่อ

หลังจากการเปรียบเทียบการใช้งาน Python เป็นเวลานาน ฉันต้องถามตัวเองว่า ทำไมมันถึงยอดเยี่ยมขนาดนี้ เหตุใดความคิดบ้าๆ นี้จึงควรค่าแก่การใฝ่หา ฉันคิดว่า Alex Gaynor พูดได้ดีในบล็อกของเขา: “[PyPy is the future] เพราะ [it] ให้ความเร็วที่ดีกว่า ความยืดหยุ่นที่มากกว่า และเป็นแพลตฟอร์มที่ดีกว่าสำหรับการเติบโตของ Python”

ในระยะสั้น:

• รวดเร็วเพราะรวบรวมซอร์สโค้ดเป็นโค้ด เนทีฟ (โดยใช้ JIT)
• มีความยืดหยุ่นเพราะเพิ่ม JIT ให้กับล่ามของคุณ ด้วยการทำงานเพิ่มเติมเพียงเล็กน้อย
• มีความยืดหยุ่น (อีกครั้ง) เพราะคุณสามารถเขียนล่ามใน RPython ซึ่งขยายได้ง่ายกว่าพูด C (อันที่จริง มันง่ายมากที่มีบทช่วยสอนสำหรับการเขียนล่ามของคุณเอง)

ภาคผนวก: ชื่อ Python อื่นๆ ที่คุณอาจเคยได้ยิน

• Python 3000 (Py3k): การตั้งชื่อทางเลือกสำหรับ Python 3.0 ซึ่งเป็นรุ่น Python ที่เข้ากันไม่ได้แบบย้อนหลังซึ่งเปิดตัวในปี 2008 ทีมงาน Py3k คาดการณ์ว่าจะใช้เวลาประมาณห้าปีกว่าที่เวอร์ชันใหม่นี้จะนำมาใช้อย่างสมบูรณ์ และในขณะที่นักพัฒนา Python ส่วนใหญ่ (คำเตือน: การอ้างสิทธิ์เล็กน้อย) ยังคงใช้ Python 2.x ต่อไป ผู้คนต่างตระหนักถึง Py3k มากขึ้น

• Cython: superset ของ Python ที่รวมการโยงเพื่อเรียกใช้ฟังก์ชัน C
  • เป้าหมาย: อนุญาตให้คุณเขียนส่วนขยาย C สำหรับโค้ด Python ของคุณ
  • ยังให้คุณเพิ่มการพิมพ์แบบคงที่ให้กับโค้ด Python ที่มีอยู่ ทำให้สามารถคอมไพล์และบรรลุประสิทธิภาพเหมือน C
  • สิ่งนี้คล้ายกับ PyPy แต่ไม่เหมือนกัน ในกรณีนี้ คุณกำลังบังคับให้พิมพ์รหัสของผู้ใช้ก่อนที่จะส่งต่อไปยังคอมไพเลอร์ ด้วย PyPy คุณจะเขียน Python แบบเก่าธรรมดา และคอมไพเลอร์จะจัดการการเพิ่มประสิทธิภาพใดๆ
    
    

• Numba: “คอมไพเลอร์เฉพาะทางแบบทันเวลา” ที่เพิ่ม JIT ให้กับโค้ด Python ที่มี คำอธิบายประกอบ ในแง่พื้นฐานที่สุด คุณให้คำใบ้แก่มัน และทำให้โค้ดบางส่วนของคุณเร็วขึ้น Numba เป็นส่วนหนึ่งของการแจกจ่าย Anaconda ซึ่งเป็นชุดของแพ็คเกจสำหรับการวิเคราะห์และการจัดการข้อมูล

• IPython: แตกต่างอย่างมากจากสิ่งอื่นที่กล่าวถึง สภาพแวดล้อมการคำนวณสำหรับ Python โต้ตอบด้วยการสนับสนุนชุดเครื่องมือ GUI และประสบการณ์เบราว์เซอร์ ฯลฯ

• Psyco: โมดูลส่วนขยาย Python และหนึ่งในความพยายามของ Python JIT รุ่นแรกๆ อย่างไรก็ตาม ตั้งแต่นั้นมา มันถูกทำเครื่องหมายว่า "ไม่ได้รับการดูแลและตาย" อันที่จริง Armin Rigo หัวหน้านักพัฒนาของ Psyco ตอนนี้ทำงานบน PyPy แล้ว

การเชื่อมโยงภาษา Python

• RubyPython: สะพานเชื่อมระหว่าง Ruby และ Python VM อนุญาตให้คุณฝังโค้ด Python ลงในรหัส Ruby ของคุณ คุณกำหนดตำแหน่งที่ Python เริ่มต้นและหยุด และ RubyPython จัดการข้อมูลระหว่าง VM

• PyObjc: การโยงภาษาระหว่าง Python และ Objective-C ซึ่งทำหน้าที่เป็นสะพานเชื่อมระหว่างพวกเขา ในทางปฏิบัติ หมายความว่าคุณสามารถใช้ไลบรารี Objective-C (รวมถึงทุกสิ่งที่คุณต้องการเพื่อสร้างแอปพลิเคชัน OS X) จากโค้ด Python และโมดูล Python จากโค้ด Objective-C ของคุณ ในกรณีนี้ จะสะดวกที่ CPython เขียนด้วย C ซึ่งเป็นสับเซตของ Objective-C

• PyQt: ในขณะที่ PyObjc ให้คุณผูกกับส่วนประกอบ OS X GUI แต่ PyQt ทำเช่นเดียวกันสำหรับเฟรมเวิร์กแอปพลิเคชัน Qt ให้คุณสร้างอินเทอร์เฟซกราฟิกที่สมบูรณ์ เข้าถึงฐานข้อมูล SQL ฯลฯ เครื่องมืออื่นที่มีจุดมุ่งหมายเพื่อนำความเรียบง่ายของ Python มาสู่เฟรมเวิร์กอื่น

JavaScript Frameworks

• pyjs (Pyjamas): เฟรมเวิร์กสำหรับสร้างแอปพลิเคชันเว็บและเดสก์ท็อปใน Python ประกอบด้วยคอมไพเลอร์ Python-to-JavaScript ชุดวิดเจ็ต และเครื่องมืออื่นๆ

• Brython: Python VM ที่เขียนด้วย JavaScript เพื่ออนุญาตให้เรียกใช้โค้ด Py3k ในเบราว์เซอร์