ทำไมผู้คนถึงลังเลที่จะใช้ Python 3

221

Python 3 เปิดตัวในเดือนธันวาคม 2551 เวลาผ่านไปนานมากแล้ว แต่จนถึงทุกวันนี้นักพัฒนาหลายคนลังเลที่จะใช้ Python 3 แม้แต่กรอบงานที่ได้รับความนิยมอย่าง Django ก็ไม่สามารถทำงานร่วมกับ Python 3 ได้ แต่ก็ยังต้องพึ่งพา Python 2

แน่นอนว่า Python 3 มีความเข้ากันไม่ได้กับ Python 2 และบางคนจำเป็นต้องพึ่งพาความเข้ากันได้แบบย้อนหลัง แต่ Python 3 ยังไม่พอสำหรับโปรเจ็กต์ส่วนใหญ่ที่จะเปลี่ยนหรือเริ่มต้นด้วย Python 3

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

— แฮมโวค
แหล่งที่มา

3

มีโครงการใหม่มากมายที่เริ่มใช้ Python 2 หรือไม่ หรือเป็นเพียงโครงการระยะยาวอย่าง Django?

— Carson63000

3

คุณสามารถอ้างอิงการสนทนา / แหล่งข้อมูลบางส่วนได้หรือไม่?

— Michael Easter

12

@Michael Easter - เขาไม่จำเป็นต้องทำ เพียงตรวจสอบแท็กหลามบน SO; ผู้คนจำนวนมากมีความเห็นว่า "เรียนรู้ 2.x, 3.x ยังไม่พร้อม"

— โกง

5

คุณไม่เคยเห็นPame 3 Wall of Shameไหม?

— detly

7

@detly ตอนนี้ก็เรียกPython 3 Wall of Superpower

— freeforall tousez

249

โปรดทราบว่าฉันไม่ได้อัปเดตคำตอบนี้อีกต่อไป ฉันมี Python 3 Q & A ที่ยาวขึ้นในเว็บไซต์ส่วนตัวของฉันที่http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

คำตอบก่อนหน้า:

(อัปเดตสถานะกันยายน 2555)

เรา (เช่นผู้พัฒนาหลัก Python) คาดการณ์เมื่อ Python 3.0 ถูกปล่อยออกมาซึ่งใช้เวลาประมาณ 5 ปีสำหรับ 3.x ในการเป็นตัวเลือก "เริ่มต้น" สำหรับโครงการใหม่ในซีรีย์ 2.x การคาดการณ์นั้นเป็นเหตุให้ระยะเวลาการบำรุงรักษาตามแผนสำหรับการเปิดตัว 2.7 นั้นยาวนาน

Python 3.0 รีลีสดั้งเดิมนั้นกลับกลายเป็นว่ามีปัญหาร้ายแรงเกี่ยวกับประสิทธิภาพของ IO ที่ไม่ดีซึ่งทำให้มันใช้ไม่ได้อย่างมีประสิทธิภาพสำหรับการใช้งานส่วนใหญ่ดังนั้นจึงเหมาะสมกว่าที่จะเริ่มต้นไทม์ไลน์จากการเปิดตัว Python 3.1 ในปลายเดือนมิถุนายน 2009 ปัญหาประสิทธิภาพการทำงานของ IO ยังเป็นสาเหตุที่ทำให้ไม่มีการเปิดตัวการบำรุงรักษา 3.0.z: ไม่มีเหตุผลที่ดีที่ใคร ๆ ก็อยากจะติดกับ 3.0 มากกว่าการอัพเกรดเป็น 3.1)

ในช่วงเวลาของการเขียน (กันยายน 2555) นั่นหมายความว่าขณะนี้เราอยู่ในช่วงเปลี่ยนผ่าน 3 ปีและการคาดการณ์ดังกล่าวยังคงเป็นไปอย่างต่อเนื่อง

ในขณะที่ผู้คนที่พิมพ์รหัส Python 3 มักถูกกัดโดยการเปลี่ยนแปลงทางไวยากรณ์เช่นprintกลายเป็นฟังก์ชั่น แต่จริงๆแล้วก็ไม่ได้ยุ่งยากสำหรับการย้ายพอร์ตไลบรารีเพราะ2to3เครื่องมือแปลงอัตโนมัติจัดการมันได้อย่างมีความสุข

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

แม้แต่ไลบรารีมาตรฐานใน Python 3.0 และ 3.1 ยังมีปัญหาการจัดการ Unicode ทำให้การย้ายไลบรารีจำนวนมากเป็นเรื่องยาก (โดยเฉพาะที่เกี่ยวข้องกับเว็บเซอร์วิส)

3.2 แก้ไขปัญหาเหล่านั้นได้มากโดยให้เป้าหมายที่ดีขึ้นสำหรับห้องสมุดและกรอบงานเช่น Django 3.2 ยังได้นำเวอร์ชันการทำงานแรกของwsgiref(มาตรฐานหลักที่ใช้สำหรับการสื่อสารระหว่างเว็บเซิร์ฟเวอร์และเว็บแอปพลิเคชันที่เขียนด้วย Python) สำหรับ 3.x ซึ่งเป็นข้อกำหนดเบื้องต้นที่จำเป็นสำหรับการนำไปใช้ในพื้นที่เว็บ

การอ้างอิงที่สำคัญเช่น NumPy และ SciPy ในขณะนี้ได้รับการ ported การติดตั้งและการจัดการการพึ่งพาเครื่องมือชอบzc.buildout, pipและvirtualenvที่มีอยู่สำหรับ 3.x, พีระมิด 1.3 ปล่อยสนับสนุนหลาม 3.2 ที่จะเกิดขึ้น Django 1.5 เปิดตัวรวมถึงการทดลองหลาม 3 การสนับสนุนและ 12.0 การเปิดตัวของ เฟรมเวิร์กเครือข่าย Twisted ตัดการสนับสนุน Python 2.5 เพื่อปูทางสำหรับการสร้างเวอร์ชันที่รองรับ Python 3

นอกเหนือจากความคืบหน้าเกี่ยวกับไลบรารีและกรอบการทำงานร่วมกันของ Python 3 การใช้งานล่าม PyPy ที่รวบรวม JIT ซึ่งเป็นที่นิยมนั้นกำลังทำงานอย่างแข็งขันบนการสนับสนุน Python 3

เครื่องมือสำหรับการจัดการกระบวนการโยกย้ายได้ปรับปรุงอย่างชัดเจน นอกเหนือจาก2to3เครื่องมือที่ให้ไว้เป็นส่วนหนึ่งของ CPython (ซึ่งขณะนี้ถือว่าเหมาะสมที่สุดสำหรับการแปลงครั้งเดียวของแอปพลิเคชันซึ่งไม่ต้องการการสนับสนุนสำหรับซีรีย์ 2.x) นอกจากนี้ยังมีpython-modernizeซึ่งใช้2to3โครงสร้างพื้นฐานเพื่อกำหนดเป้าหมาย ชุดย่อยทั่วไป (ใหญ่) ของ Python 2 และ Python 3 เครื่องมือนี้สร้างรหัสฐานเดียวที่จะทำงานบนทั้ง Python 2.6+ และ Python 3.2+ ด้วยความช่วยเหลือของsixไลบรารีความเข้ากันได้ ธ 3.3 ปล่อยยังช่วยขจัดสาเหตุหนึ่งที่สำคัญของ "เสียง" เมื่อมีการย้ายการใช้งานที่มีอยู่ Unicode ตระหนักถึง: งูหลาม 3.3 อีกครั้งสนับสนุนคำนำหน้า 'U' สำหรับตัวอักษรของสตริง (มันไม่จริงทำอะไรในหลาม 3 - มันเพิ่งถูกเรียกคืนเพื่อหลีกเลี่ยงไม่ได้ตั้งใจทำให้การโยกย้ายไปยังหลาม 3 ยากสำหรับผู้ใช้ที่มีความโดดเด่นอยู่แล้วได้อย่างถูกต้องข้อความและตัวอักษรไบนารีของพวกเขาในหลาม 2)

ดังนั้นเราจึงค่อนข้างมีความสุขกับความคืบหน้าของสิ่งต่าง ๆ - ยังมีเวลาอีกเกือบ 2 ปีที่จะอยู่ในกรอบเวลาเดิมของเรา

เนื่องจากโครงการจำนวนมากไม่ได้ดูแลจัดการข้อมูลเมตาของแพ็กเกจ Python อย่างถูกต้องและบางโครงการที่มีผู้ดูแลระบบที่ใช้งานน้อยได้ถูกแยกเพื่อเพิ่มการสนับสนุน Python 3 สแกนเนอร์ PyPI อัตโนมัติล้วนๆยังคงให้มุมมองเชิงลบมากเกินไป สนับสนุน.

ทางเลือกที่ต้องการสำหรับการรับข้อมูลเกี่ยวกับระดับการรองรับ Python 3 บน PyPI คือhttp://py3ksupport.appspot.com/

รายการนี้จัดทำโดย Brett Cannon (นักพัฒนาหลัก Python เป็นเวลานาน) เป็นการส่วนตัวสำหรับบัญชี metadata โครงการที่ไม่ถูกต้องการสนับสนุน Python 3 ซึ่งอยู่ในเครื่องมือควบคุมแหล่งที่มา แต่ยังไม่มีในรุ่นอย่างเป็นทางการและโครงการที่มีการปรับปรุงล่าสุด หรือทางเลือกที่รองรับ Python 3 ในหลายกรณีไลบรารีที่ยังไม่พร้อมใช้งานบน Python 3 ขาดการพึ่งพาคีย์และ / หรือการขาด Python 3 ในโครงการอื่น ๆ ลดความต้องการของผู้ใช้ (เช่นเมื่อกรอบ Django หลักพร้อมใช้งานบน Python 3 เครื่องมือที่เกี่ยวข้องเช่น South และ django-celery มีแนวโน้มที่จะเพิ่มการสนับสนุน Python 3 และความพร้อมของ Python 3 ที่รองรับทั้ง Pyramid และ Django ทำให้มีโอกาสมากขึ้นที่การสนับสนุน Python 3 จะถูกนำไปใช้ในเครื่องมืออื่น ๆ เช่น gevent)

ไซต์ที่http://getpython3.com/มีลิงก์ที่ยอดเยี่ยมไปยังหนังสือและแหล่งข้อมูลอื่น ๆ สำหรับ Python 3 ระบุถึงห้องสมุดหลักและกรอบการทำงานที่สนับสนุน Python 3 แล้วและให้ข้อมูลบางอย่างเกี่ยวกับวิธีที่นักพัฒนาสามารถขอความช่วยเหลือทางการเงินจาก PSF ในการย้ายโปรเจ็กต์หลักไปยัง Python 3

แหล่งข้อมูลที่ดีอีกอย่างคือหน้าวิกิชุมชนเกี่ยวกับปัจจัยที่ควรพิจารณาเมื่อเลือกเวอร์ชัน Python สำหรับโครงการใหม่: http://wiki.python.org/moin/Python2orPython3

— ncoghlan
แหล่งที่มา

3

อัปเดตตามความคืบหน้าในช่วง 18 เดือนที่ผ่านมา (และตั้งข้อสังเกตอย่างชัดเจนถึงความจริงที่ว่า 3.1 เป็นการเปิดตัวการผลิตจริง 3.x ครั้งแรกเนื่องจากประสิทธิภาพการทำงาน IO ที่ไม่ดีใน 3.0)

— ncoghlan

1

ในระดับหนึ่ง (เช่นเรารู้ว่ามันช้ากว่าระบบย่อย io ใน 2.6 อย่างมาก) แต่ผลกระทบต่อการใช้งานทั่วไปนั้นแย่กว่าที่เราคาดไว้มาก (มาตรฐาน IO ของเราดีขึ้นอย่างเห็นได้ชัดตั้งแต่นั้นมาดังนั้นจึงไม่มีโอกาส จัดส่งวันนี้)

— ncoghlan

6

กรอบเวลาที่เสนอดูเหมือนจะไม่กระตือรือร้นในปี 2558: |

— zetah

1

วิธีที่ฉันเห็นมัน (และฉันจะถูกเผาที่เสาของบางคน) นี่คือการเข้ารหัสด้านหน้า Py3 ละเมิด (และยังคงทำเช่นนี้ไป) Zen of Python ใน "ลัทธิปฏิบัตินิยมเต้นจุดบริสุทธิ์" : Py3 เป็นการเข้ารหัสที่บริสุทธิ์ Py2 กำลังเข้ารหัส - ใช้งานได้จริง

— Jürgen A. Erhard

2

Py3 ยังคงใช้งานได้ดีเกี่ยวกับการเข้ารหัส (ไม่เช่นนั้นเราจะไม่มีตัวแทนสำรอง) เราเพิ่งพบผู้ใช้ * ระวังตัวจำนวนมากที่ไม่สนใจฟังการทำงานของระบบปฏิบัติการบนแพลตฟอร์มเช่น Windows, .NET และ JVM ( รวมถึง Android) ฉันได้เขียนเพิ่มเติมเกี่ยวกับเรื่องนี้ที่developerblog.redhat.com/2014/09/09/… ผลกระทบหลักเกิดจาก "ข้อผิดพลาดไม่ควรผ่านไปอย่างเงียบ ๆ " เนื่องจากเราเปลี่ยนข้อผิดพลาดที่ขึ้นกับข้อมูลซึ่งทำให้ mojibake เป็นข้อผิดพลาดประเภทโครงสร้าง บ่นเกี่ยวกับการผสมข้อมูลไบนารีและข้อมูลข้อความ

— ncoghlan

48

ฉันเชื่อว่าความลังเลมากมายมาจากสองสิ่ง:

หากยังไม่พังอย่าแก้ไข
[ไลบรารี XYZ] ที่เราต้องการไม่มีพอร์ต 3.0

มีความแตกต่างเล็กน้อยกับวิธีการทำงานของภาษาหลักที่ระบุไว้ในเอกสารนี้ ยกตัวอย่างเช่นการเปลี่ยน "การพิมพ์" จากคำสั่งเป็นฟังก์ชั่นจะเป็นการทำลายรหัส Python 2.x จำนวนมากและนั่นเป็นวิธีที่ง่ายที่สุดเท่านั้น พวกเขากำจัดคลาสแบบเก่าออกไปอย่างสมบูรณ์ใน 3.0 อันที่จริงแล้วภาษาต่างกันมากดังนั้นการย้ายรหัสเก่าจึงไม่ง่ายอย่างที่บางคนคิด

— TZHX
แหล่งที่มา

2

ปัญหาการพึ่งพาไม่ได้ -a- พอร์ตเป็นแบบเรียกซ้ำเช่นกัน สิ่งที่จำเป็นสำหรับห้องสมุดที่ใช้กันอย่างแพร่หลายที่มีการพึ่งพาน้อยหรือไม่มีเลยนอก stdlib ไปยังพอร์ตซึ่งสามารถเริ่มปฏิกิริยาลูกโซ่

— Tony Meyer

10

ฉันจะเปลี่ยนคำสั่ง พวกเราหลายคนเดินไปเดินมารอแพคเกจเฉพาะเพื่อโยกย้ายไปยัง 3

— S.Lott

1

@ Tony - นั่นเป็นเหตุผลว่าทำไมฉันถึงคิดว่ามันดีสำหรับ 3.0 ที่ Numpy พร้อมใช้งานแล้ว @ S.Lott - ฉันเดาว่ามันขึ้นอยู่กับว่า 3 เสนอสิ่งที่คุณต้องการ พูดตามตรงฉันเพิ่งย้ายจาก 2.5 ไปเป็น 2.7 - ฉันไม่ได้เป็นหนึ่งในคนที่ติดตาม "ล่าสุดและยิ่งใหญ่ที่สุด"

— TZHX

1

การใช้งานโค้ดเก่าด้วยความช่วยเหลือของ2to3ไม่ยากอย่างที่บางคนกลัวเช่นกัน

— ncoghlan

5

มันไม่ได้ช่วยอะไรเลยเกี่ยวกับทุก ๆ OS ที่รวม Python ไว้ใน distro (OSX, Linux และอื่น ๆ ) ยังคงติดอยู่ใน Python 2 รุ่นเก่า ๆ ทำไมเขียนสำหรับ Python 3 เมื่อไม่มีใครสามารถใช้รหัสของคุณได้ กับ internals ของระบบปฏิบัติการของพวกเขา?

— Ant

28

ไม่มีเหตุผลบังคับสำหรับธุรกิจที่มีอยู่ในการใช้เวลาเงินและความพยายามในการโยกย้ายไปยังบางสิ่งบางอย่างในขณะที่ไม่มีการเปลี่ยนแปลงในชุดคุณลักษณะที่มีอยู่ ฉันหมายความว่ารหัสฐานในซีรีย์ Python 2 เปิดตัวและดำเนินธุรกิจมาเป็นเวลานานมีความเสถียรทดสอบและมีคุณสมบัติของผลิตภัณฑ์ในปัจจุบันทั้งหมด ทำไมไม่มีใครใช้เวลาเงินและความพยายามเพียงแค่ย้าย Python 3 เพียงเพื่อการโยกย้ายไปยังมัน

นอกจากโพสต์การโยกย้ายมั่นใจว่าไม่มีความล้มเหลวในการถดถอยและสิ่งที่ปวดหัวไม่สามารถหลีกเลี่ยงได้

สำหรับโครงการใหม่นโยบายเรียบง่ายและเรียบง่ายทุกอย่างเริ่มจากประเด็นต่อไปนี้:

distro อย่าง Ubuntu ส่ง Python 3 ในการติดตั้งเริ่มต้นหรือไม่
ระบบนิเวศของห้องสมุดสำหรับ Python 3 คืออะไร
เฟรมเวิร์กและอื่น ๆ สามารถทำงานร่วมกับ Python 3 ได้ ฯลฯ

เป็นกระบวนการ 'เลือกภาษาใหม่' ตามปกติของคุณ นี่คือที่ปัญหาไก่ไข่เข้ามาไม่กี่คนที่ใช้มันเพราะมีคนไม่มากที่ใช้มัน ในท้ายที่สุดไม่มีใครรู้สึกอยากย้ายไปอยู่เลย

การทำลายความเข้ากันได้ย้อนหลังนั้นไม่เคยเป็นเรื่องที่ดีเลยในตอนท้ายคุณจะต้องมีผู้ใช้เป็นเปอร์เซ็นต์ที่ดีเสมอ

— Kamaal
แหล่งที่มา

14

ในช่วงเวลาที่ Python 2.0 เปิดตัว Python ก็ได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว มีผู้ใช้ใหม่จำนวนมากที่ใช้เวอร์ชันล่าสุดตามธรรมชาติเนื่องจากไม่มีการพึ่งพาเวอร์ชันเก่า ด้วยผู้คนจำนวนมากที่ใช้ 2.0 เป็นค่าเริ่มต้นจึงมีแรงกดดันอย่างมากต่อนักพัฒนาห้องสมุดและอื่น ๆ

เมื่อถึงเวลาที่ปล่อย Python 3.0 นั้นมีผู้ใช้จำนวนมากที่ต้องพึ่งพา Python 2.0 และการเติบโตแบบเลขชี้กำลัง

โดยส่วนตัวแล้วฟีเจอร์ใหม่ใน Python 2 วันดูเหมือนจะน่าสนใจมากกว่าฟีเจอร์ที่จัดทำโดย Python 3

ฉันเคยคิดว่า Python 3 จะเข้ามาแทนที่ในที่สุด แต่ตอนนี้ฉันยังไม่แน่ใจ แต่ไม่ใช่ Python ที่มีปัญหานี้ ท้ายที่สุดมีกี่คนที่ใช้ Perl 6 อย่างซื่อสัตย์? นั่นเป็นเรื่องที่ค่อนข้างยาวกว่า Python 3, IIRC

— Steve314
แหล่งที่มา

3

เฮ้ฉันยังใช้ Fortran77 อยู่ :) และ "คุณสมบัติ" จริงส่วนใหญ่จาก Python 3 ได้รับการ backported เป็น 2.6 และ 2.7 โดยไม่มีปัญหาด้านความเข้ากันได้มากมาย สิ่งเดียวที่ Python 3 เสนอจริงๆคือไวยากรณ์ "สะอาดกว่า"

— TZHX

3

การเปรียบเทียบ Python 3 กับ Perl 6 ผิด Python 3 เป็นการกระโดดที่เพิ่มขึ้นจาก Python 2 ในขณะที่ Perl 6 เป็นการออกแบบใหม่ทั้งหมด Perl 5 และ Perl 6 เป็นภาษาพี่สาวและจะยังคงอยู่ร่วมกันเป็นเวลานาน ในทางกลับกัน Python 3 วางแผนที่จะแทนที่ Python 2 ไม่ใช่แค่ co อยู่ นี่คือความแตกต่างที่ยิ่งใหญ่

— kamaal

1

Perl 6 ยังอยู่ระหว่างการพัฒนา ใช่ Rakudo Perl คือการติดตั้ง Perl6 ที่ใกล้เคียงที่สุด แต่ยังไม่ได้ใช้งานทุกอย่าง ยังไม่มีการเตรียมการสำหรับการติดตั้ง Perl 6

— Htbaa

1

@Htbaa สำหรับคำจำกัดความมากมายของความสมบูรณ์และความพร้อม Perl 6 เสร็จสมบูรณ์และพร้อมสำหรับการผลิต สิ่งนี้อาจใช้เวลาสักครู่เพื่อให้ตรงกับข้อมูลจำเพาะที่สมบูรณ์มีสิ่งที่คล้ายกันกับภาษาอื่นด้วย ตัวอย่างเช่น GCC จนกระทั่งเมื่อไม่นานมานี้ค่อนข้างไม่ตรงกับข้อกำหนด C ++ ทั้งหมด การออกแบบและการใช้ภาษาเป็นกระบวนการที่ช้ามาก

— kamaal

1

rakudo.org/node/75 Rakudo ดาวได้รับการปล่อยตัวกลับมานาน คุณต้องลอง

— kamaal

11

จุกใหญ่สำหรับฉันซึ่งฉันคิดว่าไม่สามารถแก้ไขได้ด้วยการแปลอัตโนมัติคือการหารจำนวนเต็ม ฉันมีรหัสทางวิทยาศาสตร์ที่พึ่งพา x / 2 โดยให้ x ถูกปัดเศษลง (เมื่อ x เป็นจำนวนเต็ม)

Python 3 จะไม่ทำเช่นนั้น แต่จะให้คำตอบ. 5 (สำหรับเลขคี่)
ฉันไม่สามารถแทนที่ทั้งหมด / ในรหัสของฉันด้วย // เพราะบางครั้งฉันทำการหารแบบลอยตัวและต้องการให้มีการทำงานแบบลอย

ดังนั้นสำหรับฉันที่จะย้ายไปยัง python 3 ฉันจะต้องลากผ่านบรรทัดของหมื่นบรรทัดตรวจสอบทุก / และดูว่าฉันสามารถคิดออกว่าควรจะเป็น / หรือ //

— Sharky
แหล่งที่มา

7

"-Q ตัวเลือก" (2.2-2.7) สามารถเพิ่มคำเตือนสำหรับการแบ่ง นอกจากนี้fixdiv.pyใช้คำเตือนเหล่านี้เพื่ออัปเดตนิพจน์ในสคริปต์ของคุณ

— Eryk Sun

10

Python 3 เป็นการดีที่จะเริ่มโครงการใหม่ถ้าไลบรารีทั้งหมดที่คุณต้องการได้รับการย้ายไปยัง Py3k แล้ว

หากนี่ไม่ใช่ตัวเลือกการใช้ Python 2.7 เป็นสิ่งที่ดีที่สุดของทั้งสองโลก: คุณมีไลบรารี่ที่สร้างขึ้นสำหรับ Python 2.x มากที่สุดและคุณสามารถค่อยๆเปลี่ยนรหัสของคุณให้ใช้งานได้กับ Py3k ดังนั้นการโยกย้ายนั้นง่ายเมื่อคุณตัดสินใจ มัน. รายการของสารพัดไวยากรณ์จาก Py3k ที่คุณมีอยู่แล้วใน 2.7 __future__ค่อนข้างยาวก็ไม่ลืมที่จะนำเข้าจาก รายการโปรดของฉันคือ Unicode โดยค่าเริ่มต้นและการแบ่งมักจะลอย

— 9000
แหล่งที่มา

10

จากมุมมองของบริการเว็บ: ไม่มีเฟรมเวิร์กเซิร์ฟเวอร์หลักหรือเว็บเฟรมเวิร์กรองรับ Python3

อัปเดต: เห็นได้ชัดว่าเป็นกรณีในต้นปี 2011 ณ ตอนนี้ (ปลายปี 2013) เฟรมเวิร์กหลักส่วนใหญ่ทำงานกับ Python3 อย่างไรก็ตามบางส่วนยังเข้ากันไม่ได้ ตัวอย่างมีนัยสำคัญจะได้รับการบิดที่มันยังคงทำงานในความคืบหน้า

— vartec
แหล่งที่มา

BTW, Django เพิ่งเริ่มให้การสนับสนุน Python3 ในเวอร์ชัน 1.5

— 9000

1

Django 1.6 รองรับ Python 3 อย่างเป็นทางการแล้ว Flask รองรับ

— chhantyal

8

ไม่มีเหตุผลที่น่าสนใจที่ฉันได้เห็นการใช้ P3K เว้นแต่ว่าคุณกำลังทำงานหนัก i18n ในการจู่โจมของฉันฉันได้พบ Unicode ที่แพร่หลายเป็นอุปสรรคต่อการทำงานของฉัน (ASCII) และเครื่องกำเนิดไฟฟ้าภาคบังคับที่จะอุดตันรหัสของฉัน

ในไม่กี่ปีที่ผ่านมา 3 จะนำเสนอสภาพแวดล้อมที่น่าสนใจมากขึ้น แต่ไม่ใช่วันนี้

— พอลนาธาน
แหล่งที่มา

4

การแจกแจงไม่ทำให้ Python3 พร้อมใช้งาน มีบางสิ่งที่น่าสนใจซึ่งเปลี่ยนไปจาก Python2 อยู่แล้ว แต่รุ่นลินุกซ์หลัก ๆ อย่าง Debian, Ubuntu และอื่น ๆ นั่นเป็นเหตุผลหลักสำหรับฉันในฐานะผู้เขียนแอปพลิเคชันไม่ให้ทำเช่นกัน

แม้ว่าฉันจะเตรียมการเปลี่ยนแปลงและพยายามหลีกเลี่ยงการสร้างไวยากรณ์ที่ไม่เข้ากันฉันไม่สามารถทดสอบได้อย่างถูกต้อง มันเดือดลงไปในปัญหาไก่และไข่จริงๆ

— มาริโอ
แหล่งที่มา

4

สิ่งนี้อาจเป็นจริงเพียงครั้งเดียว แต่ "apt-get install python3" และ "yum install python3" ทำงานได้เป็นเวลานาน เครื่องมือเช่นสารพิษและบริการต่างๆเช่น Shining Panda CI ทำให้ตรงไปตรงมาเพื่อทดสอบกับ Python หลายรุ่น

— ncoghlan

ตอนนี้ distros เหล่านี้จำนวนมากติดตั้ง python3 โดยค่าเริ่มต้นซึ่งแตกต่างจากภาษาการเขียนโปรแกรมอื่น ๆ

— Antti Haapala