Perbincangan terkini mengenai amalan terbaik dataclass Python telah mencetuskan perdebatan komuniti yang lebih luas tentang pengendalian argumen kata kunci oleh bahasa tersebut dan keperluan untuk sintaks yang lebih ringkas. Perbualan bermula dengan cadangan untuk menggunakan argumen khusus kata kunci dalam dataclass tetapi dengan cepat berkembang menjadi pemeriksaan yang lebih mendalam terhadap sifat bertele-tele Python berbanding bahasa pengaturcaraan lain.
Perbandingan Sintaks Keyword-Only Python Dataclass
Dataclass tradisional:
@dataclass
class MyDataClass:
x: int
y: str
z: bool = True
Dataclass keyword-only (disyorkan):
@dataclass(kw_only=True)
class MyDataClass:
x: int
y: str
z: bool = True
Perbezaan penggunaan:
- Tradisional:
MyDataClass(1, 'foo', False)
- Keyword-only:
MyDataClass(x=1, y='foo', z=False)
Masalah Bertele-tele
Pembangun Python semakin kecewa dengan sifat berulang argumen kata kunci, terutamanya apabila nama pembolehubah sepadan dengan nama parameter dengan tepat. Keperluan semasa untuk menulis function(x=x, y=y, z=z)
terasa terlalu bertele-tele kepada ramai pengaturcara yang telah mengalami penyelesaian yang lebih elegan dalam bahasa lain.
Sintaks sifat ringkas JavaScript telah menjadi titik kecemburuan khusus di kalangan pembangun Python . Dalam JavaScript , pembangun boleh menulis {x, y, z}
sahaja daripada {x: x, y: y, z: z}
apabila nama sifat sepadan dengan nama pembolehubah. Ciri ini mengurangkan pengulangan kod dengan ketara dan meningkatkan kebolehbacaan.
Percubaan Penyelesaian yang Gagal
Komuniti Python telah cuba menangani isu ini melalui saluran rasmi. PEP 736 mencadangkan sintaks ringkas menggunakan notasi fn(x=, y=, z=)
, tetapi cadangan ini akhirnya ditolak. Ramai pembangun menyatakan lega dengan penolakan ini, merasakan sintaks yang dicadangkan adalah janggal dan tidak memberikan penyelesaian elegan yang mereka harapkan.
Berdasarkan penampilannya, perasaan yang saya dapat ialah cadangan sintaks yang baik dan mudah telah ditolak kerana perdebatan remeh.
Beberapa pendekatan alternatif telah dicadangkan oleh ahli komuniti. Ada yang mencadangkan menggunakan sintaks seperti OCaml dengan notasi tilde, manakala yang lain mencadangkan pendekatan awalan titik bertindih Julia . Walau bagaimanapun, tiada satu pun daripada alternatif ini mendapat daya tarikan yang ketara atau pertimbangan rasmi.
Cadangan Penyelesaian Sintaks Ringkas Python
Bahasa | Sintaks Semasa | Sintaks Ringkas | Status |
---|---|---|---|
JavaScript | {x: x, y: y, z: z} |
{x, y, z} |
Tersedia |
Python (PEP 736) | fn(x=x, y=y, z=z) |
fn(x=, y=, z=) |
Ditolak |
Gaya OCaml | fn(x=x, y=y) |
fn(~x, ~y) |
Dicadangkan |
Gaya Julia | fn(x=x, y=y) |
fn(;x, y) |
Dicadangkan |
Penyelesaian sementara Python semasa:
f(**{x, y, z})
- Menggunakan pembukaan kamus tetapi kurang mudah dibaca
Penyelesaian Sementara dan Penyelesaian Semasa
Walaupun tiada sintaks ringkas asli, pembangun Python telah menemui penyelesaian sementara yang kreatif. Satu pendekatan melibatkan penggunaan pembukaan kamus dengan f(**{x, y, z})
, walaupun sintaks ini tidak begitu elegan dan boleh mengelirukan untuk dibaca.
Komuniti juga telah menerima TypedDict sebagai penyelesaian untuk dokumentasi yang lebih baik dan sokongan IDE apabila berurusan dengan argumen kata kunci. Pendekatan ini membantu menangani beberapa masalah berkaitan penggunaan ** kwargs , terutamanya dalam perpustakaan seperti boto3 di mana dokumentasi parameter secara sejarahnya lemah.
Perdebatan Falsafah yang Lebih Luas
Perbincangan telah mendedahkan ketegangan asas dalam falsafah reka bentuk Python . Sesetengah pembangun berhujah bahawa keutamaan Python untuk sintaks eksplisit dan ad-hoc berbanding primitif yang boleh digabungkan sedang membawa bahasa ke arah kerumitan yang tidak perlu. Mereka bimbang bahawa Python sedang menghampiri situasi yang serupa dengan C++ , di mana sintaks menjadi begitu luas sehingga sedikit pembangun memahaminya secara menyeluruh.
Yang lain mempertahankan pendekatan semasa Python , berhujah bahawa sintaks eksplisit dan liputan perpustakaan standard yang komprehensif mengurangkan keperluan untuk kebergantungan luaran dan menjadikan kod lebih mudah dibaca dalam jangka panjang.
Kesimpulan
Walaupun pencetus segera untuk perbincangan ini adalah amalan terbaik dataclass, ia telah mendedahkan kebimbangan yang lebih mendalam tentang evolusi Python dan reka bentuk sintaks. Komuniti kekal berpecah sama ada Python memerlukan sintaks yang lebih ringkas untuk corak biasa atau sama ada pendekatan eksplisit semasa lebih baik melayani matlamat bahasa untuk kebolehbacaan dan kebolehselenggaraan. Semasa Python terus berkembang, perdebatan ini berkemungkinan akan mempengaruhi keputusan reka bentuk bahasa masa depan dan arah PEP yang akan datang.
Rujukan: Tip: Use keyword-only arguments in Python dataclasses