2015-11-14 15 views
10

क्या मुझे पाइथन पैकेज में एकमात्र मॉड्यूल को दिया गया नाम पैकेज के नाम से मेल खाना चाहिए?क्या एकल-मॉड्यूल पायथन पैकेज नामकरण के नियम हैं?

उदाहरण के लिए अगर मैं संरचना के साथ एक एकल मॉड्यूल के साथ एक पैकेज है

super-duper/ 
    super/ 
     __init.py___ 
     mycode.py 
     ... 

मैं PyPi पर एक पैकेज super-duper बना सकते हैं, जो जब स्थापित, site-packages में दो फ़ोल्डर नाम के साथ नहीं है कि होगा मैच:

super/ 
super_duper-1.2.3.dist-info/ 

कि मेरी परियोजना आयात करने के लिए मैं उपयोग

import super 
जिसका अर्थ है

बजाय वास्तविक पैकेज नाम से (super_duper)

यह आम बात (जल्दी हर दूसरे पैकेज मैं site-packages में देखते हैं के लिए फ़ोल्डर्स से पहचानने) जिसके लिए पैटर्न

same_name/ 
same_name-1.2.3.dist-info/ 

पालन के खिलाफ हो रहा है पीईपीआई पैकेज same-name

मैं बजाय (हमेशा) अपनी परियोजनाओं की संरचना करना चाहिए ताकि

super-duper/ 
    super_duper/ 
     __init.py___ 
     mycode.py 
     ... 

सुनिश्चित करने के लिए उस पैकेज नाम और मॉड्यूल आयात नाम "मैच":

import super_duper 

वहाँ एक प्रासंगिक सबसे अच्छा अभ्यास है या नियम मुझे निम्नलिखित का पालन करना चाहिए?

उत्तर

8

अपने प्रश्न का संक्षिप्त उत्तर है: (। जो सबसे प्रकाशित किया जाना चाहिए संकुल) हाँ, यह आम तौर पर अपने मॉड्यूल के नाम एक मॉड्यूल पैकेज के लिए पैकेज के नाम से मेल करने के लिए एक अच्छी आदत है

थोड़ा लंबा जवाब यह है कि नामकरण सम्मेलन हमेशा राजनीतिक होते हैं। पाइथन में भाषा मानकों को परिभाषित करने के लिए आम तौर पर स्वीकृत विधि एक प्रक्रिया है जिसे "पायथन एन्हांसमेंट प्रस्ताव" (पीईपी) कहा जाता है। पीईपी पीईपी संपादकों के एक समूह द्वारा शासित होते हैं और समीक्षा और टिप्पणी के लिए publicly indexed हैं।

मॉड्यूल होना चाहिए छोटा है, सभी लोअरकेस नाम:

वर्तमान में, वहाँ केवल एक "सक्रिय" (स्वीकार किए जाते हैं और कार्यान्वित) पीईपी मुझे लगता है कि के बारे में पता कर रहा हूँ मॉड्यूल नामकरण सम्मेलनों को शामिल किया गया है, जो पीईपी 8 है । अंडरस्कोर मॉड्यूल नाम में उपयोग किया जा सकता है यदि यह पठनीयता में सुधार करता है।पायथन पैकेज में छोटे, सभी-लोअरकेस नाम भी होना चाहिए, हालांकि अंडरस्कोर का उपयोग निराश हो गया है।

हालांकि, वहाँ मसौदा तैयार करने की प्रक्रिया में एक और प्रस्ताव अभी भी PEP 423 कहा जाता है की अनुशंसा है कि वास्तव में क्या आप अपनी पोस्ट में राज्य:

केवल एक पैकेज (या केवल एक ही मॉड्यूल) प्रति परियोजना, और उपयोग वितरित करें प्रोजेक्ट नाम के रूप में पैकेज (या मॉड्यूल) नाम।

  • यह परियोजना के नाम और वितरित पैकेज या मॉड्यूल नाम के बीच संभावित भ्रम से बचाता है।

  • यह नाम सुसंगत बनाता है।

  • यह स्पष्ट है: जब कोई प्रोजेक्ट नाम देखता है, तो वह पैकेज/मॉड्यूल नाम का अनुमान लगाता है, और इसके विपरीत।

  • यह पैकेज/मॉड्यूल नामों के बीच अंतर्निहित संघर्ष को भी सीमित करता है। एक ही नाम का उपयोग करके, जब आप पीईपीआई में प्रोजेक्ट नाम पंजीकृत करते हैं, तो आप मूल पैकेज/मॉड्यूल नाम उपलब्धता सत्यापन भी करते हैं।

यह ध्यान रखें कि इस पीईपी एक "आस्थगित" राज्य है, जिसका अर्थ यह नहीं पीईपी संपादकों द्वारा पुष्टि की गई है में अब भी है महत्वपूर्ण है, और एक अन्य प्रस्ताव (विशेष रूप से के कार्यान्वयन द्वारा अवरुद्ध है पीईपी 440 में मॉड्यूल मेटाडेटा सिंटैक्स के लिए एक अद्यतन)। हालांकि, 423 के मूल प्रस्ताव के बाद से उस समय कोई प्रतिस्पर्धी मानकों का मसौदा तैयार नहीं किया गया है, और अधिकांश सामग्री काफी विवादास्पद प्रतीत होती है, इसलिए मैं उम्मीद करता हूं कि भविष्य में इसे बहुत अधिक परिवर्तन किए बिना स्वीकार किया जाए।

+0

पीईपी 423 जाने के रास्ते की तरह लगता है। मैं उदाहरण में अवधि ('.') के उपयोग के बारे में उलझन में हूं। क्या मैं 'super.dder' के साथ हर जगह' super_duper' को प्रतिस्थापित कर सकता हूं? – orome

+0

पीईपी 423 स्थगित कर दिया गया क्योंकि पीईपी 426 का मसौदा तैयार किया जा रहा था। हालांकि पीईपी 426 प्रभावी रूप से त्याग दिया गया है, लेकिन मुझे डर है कि यह 423 पर लागू होता है। [कुछ परिवर्तन लंबित हैं] (https://mail.python.org/pipermail/python-dev/2013-July/127207.html) उदाहरण के लिए, कभी लागू नहीं किया गया है। –

+1

@raxacoricofallapatorius उदाहरण में अवधि वास्तव में नामस्थान है - पीईपी 423 यह भी बताती है कि यदि एक पैकेज एक इकाई के स्वामित्व में है, तो पैकेज के नाम का पहला भाग मालिक का नाम होना चाहिए। यह विवादों से बचने में मदद करता है, ताकि यदि आप "पिरामिड" नामक पैकेज बनाते हैं, और मैं "पिरामिड" नामक एक पूरी तरह से अलग पैकेज बना देता हूं, तो तीसरा उपयोगकर्ता दोनों को स्थापित कर सकता है और उन्हें अलग कर सकता है। – mwobey

2

आपके पास सही विचार है। परंपरा है कि मैं सबसे अक्सर इस्तेमाल किया देखा है, और यह मेरे लिए अच्छी तरह से बाहर काम किया है:

/superduper 
    /superduper 
     __init__.py 
     code.py 
    /.git 
    setup.py 
    README.rst 

आपको लगता है कि सबसे अजगर devs setuptools मॉड्यूल नाम के लिए कोई भी विशेष वर्ण (के साथ सभी लोअर केस पसंद करते हैं, pexpect, matplotlib, आदि)।
आपके शीर्ष-स्तरीय प्रोजेक्ट फ़ोल्डर को गिट रेपो नाम से भी मेल खाना चाहिए, ताकि जब आप क्लोन गिट करते हैं तो यह परिवर्तित नहीं होता है।

मेरी सबसे अच्छी सलाह, कुछ अच्छी स्थापित परियोजनाओं के स्रोत पर एक नज़र डालें, और उन्होंने जो किया है उसकी नकल करें।

3
PEP 8 से

:

ओवरराइड सिद्धांत

नाम है कि उपयोगकर्ता के लिए दिखाई दे रहे हैं के रूप में एपीआई के सार्वजनिक भाग सम्मेलनों कि कार्यान्वयन के बजाय उपयोग को प्रतिबिंबित पालन करना चाहिए।

पैकेज और मॉड्यूल नाम

मॉड्यूल छोटा है, सभी लोअरकेस नाम होना चाहिए। अंडरस्कोर मॉड्यूल नाम में इस्तेमाल किया जा सकता है अगर यह पठनीयता में सुधार करता है। पायथन पैकेज में शॉर्ट, ऑल-लोअरकेस नाम भी होना चाहिए, हालांकि अंडरस्कोर का उपयोग निराश होता है।

यहां केवल एक चीज है जो आपके प्रश्न को संबोधित करने के लिए प्रतीत होती है कि पैकेज नामों में अंडरस्कोर निराश हैं।

वर्तमान में काम करता है में अन्य Peps सामान्य (426, 423) में अजगर पैकेजिंग में विसंगतियों के कुछ पता करने के लिए होते हैं, लेकिन जब तक उन हल कर रहे हैं कि मैं क्या PEP 20 के तहत सबसे अधिक समझ में आता है के साथ जाना होगा। यदि super आयात करने के लिए पर्याप्त है, तो मैं उस के साथ जाने के इच्छुक हूं (हालांकि यदि ऐसा है, तो पीपीपी पैकेज नाम के लिए इसका उपयोग क्यों न करें?)।

मुझे नहीं लगता कि सम्मेलन निर्देश देता है कि वे समान हैं, लेकिन व्यवहार में वे दोनों एक ही लक्ष्य को प्राप्त करने की कोशिश कर रहे हैं, इस प्रकार ज्यादातर मामलों में इसका अंत हो जाता है।

5

कोई दिशानिर्देश नहीं हैं जो मुझे पता है कि आपके प्रोजेक्ट नाम को स्थापित पैकेज या मॉड्यूल से मेल खाने की आवश्यकता है। deferred draft PEP-423 Naming conventions and recipes related to packaging है, लेकिन इसे प्रभावी रूप से त्याग दिया जाता है (pending update कभी लागू नहीं किया गया था)।

आप कहते हैं कि आप देखा, लेकिन आप शायद जहां इस परियोजना का नाम और पैकेज निहित मेल नहीं खाते कुछ मौजूदा उदाहरण याद किया:

  • BeautifulSoup project PyPI पर परियोजना का नाम है, जो पैकेज को स्थापित करता है के लिए beautifulsoup4 का उपयोग करता bs4

  • dateutil Python package पीपीपीआई पर python-dateutil के रूप में उपलब्ध है। python- के साथ पीईपीआई परियोजना नामों को उपसर्ग करना काफी आम है, मैंने आज पीपीपीआई पर 1512 ऐसे पैकेजों की गणना की।

  • Viivakoodi project पाइबरकोड का एक कांटा है। उनके viivakoodi PyPI project में barcode पैकेज स्थापित करता है। एक और ऐसी कांटा परियोजना Pillow है, जो पाइथन छवि पुस्तकालय का एक कांटा है। यह पीपीपीआई under that name पर उपलब्ध है लेकिन पैकेज PIL पैकेज स्थापित करता है।

उसने कहा, व्यक्तिगत रूप से मैं इसे पीपीपीआई परियोजना के नाम और मैच के लिए निहित पैकेज के लिए पसंद करता हूं; यह भ्रम को कम करता है। प्रोजेक्ट कांटे के लिए सबसे उल्लेखनीय अपवाद है जहां लक्ष्य माइग्रेशन को आसान बनाने के लिए पुराने पैकेज नाम को बनाए रखना है।

+0

दूसरा उदाहरण दिलचस्प है, क्योंकि यह एक समीकरण को हटा देता है जिसे मैंने अस्तित्व में रखा था: पैकेज नाम के बीच, और पीपीपी पर नाम। तो वास्तव में तीन चीजें हैं: पैकेज नाम, पीपीपी पर नाम, और पैकेज में 'अकेला) मॉडल का उपयोग करने के लिए 'आयात' के साथ उपयोग किया गया नाम। मुझे इस बात से सहमत होना शामिल है कि कम से कम भ्रमित करने के लिए सभी तीन समान हैं। – orome

संबंधित मुद्दे