आपको पाथलीब का उपयोग क्यों करना चाहिए

अनुवादक से: नमस्कार, हेब्रा! मैं आपके लिए लेख का अनुवाद प्रस्तुत करता हूं कि आपको पैथलिब और इसकी निरंतरता का उपयोग क्यों करना चाहिए , वास्तव में, पैथलिब महान नहीं है । इस तरह के नए पायथन फीचर्स पर बहुत ध्यान दिया जा रहा है, जैसे कि asyncio,: = ऑपरेटर और वैकल्पिक टाइपिंग। एक ही समय में, इतना महत्वपूर्ण नहीं (हालांकि :: एक गंभीर नवाचार को कॉल करें) एक रडार के लिए एक भाषा गंभीर नवाचार नहीं बनती है), लेकिन एक भाषा में बहुत उपयोगी नवाचार। विशेष रूप से, एक विषय के लिए समर्पित लेखों की एक संख्या पर, मुझे नहीं मिला ( यहां एक पैराग्राफ को छोड़कर), इसलिए मैंने स्थिति को ठीक करने का फैसला किया।

जब मैंने कुछ साल पहले तत्कालीन नए पाथलिब मॉड्यूल की खोज की, तो मैंने अपने दिमाग के निचले हिस्से से फैसला किया कि यह os.path मॉड्यूल का सिर्फ थोड़ा अजीब वस्तु-उन्मुख संस्करण था। मैं गलत था। pathlib वास्तव में अद्भुत है !

इस लेख में मैं pathlib प्यार में पड़ने की कोशिश pathlib । मुझे उम्मीद है कि यह लेख आपको पायथन में फ़ाइलों के साथ काम करने के बारे में किसी भी स्थिति में pathlib का उपयोग करने के लिए pathlib ।

• भाग 1
  
  • os.path अजीब है
  • os ओवरलोडेड
  • glob
  • pathlib सरल चीजों को और भी आसान बनाता है
  • पथ ऑब्जेक्ट आपके कोड को अधिक स्पष्ट बनाते हैं
  • pathlib ?
  • pathlib ?
• भाग 2. सवालों के जवाब।
  
  • ईमानदार होने के लिए os.path और pathlib os.path
  • आपको रास्तों को सामान्य करने की चिंता करने की आवश्यकता नहीं है।
  • , , pathlib !
  • लेकिन मेरे पसंदीदा पुस्तकालय में मानक से बेहतर पथ है!
  • pathlib.Path और str सही मिश्रण नहीं है?
  • pathlib बहुत धीमा है
  • पठनीयता में सुधार
  • pathlib.Path

भाग 1

os.path अजीब है

os.path मॉड्यूल हमेशा वही रहा है जिसका उपयोग हमने तब किया था जब यह पायथन रास्तों पर आया था। सिद्धांत रूप में, आपकी ज़रूरत का सब कुछ है, लेकिन अक्सर यह बहुत सुरुचिपूर्ण नहीं दिखता है।

क्या मुझे इसे इस तरह आयात करना चाहिए?

 import os.path BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) TEMPLATES_DIR = os.path.join(BASE_DIR, 'templates') 

या तो?

 from os.path import abspath, dirname, join BASE_DIR = dirname(dirname(abspath(__file__))) TEMPLATES_DIR = join(BASE_DIR, 'templates') 

हो सकता है कि join फंक्शन में बहुत सामान्य नाम हो, और हमें कुछ इस तरह करना चाहिए:

 from os.path import abspath, dirname, join as joinpath BASE_DIR = dirname(dirname(abspath(__file__))) TEMPLATES_DIR = joinpath(BASE_DIR, 'templates') 

मेरे लिए, उपरोक्त सभी विकल्प बहुत सुविधाजनक नहीं हैं। हम स्ट्रिंग्स को स्ट्रिंग्स पास करते हैं जो स्ट्रिंग्स को वापस करते हैं जो हम स्ट्रिंग्स के साथ काम करने वाले अगले फ़ंक्शंस को पास करते हैं। यह सिर्फ इतना हुआ कि उन सभी में रास्ते हैं, लेकिन वे अभी भी सिर्फ लाइनें हैं।

os.path फ़ंक्शन में इनपुट और आउटपुट के लिए स्ट्रिंग्स का उपयोग करना बहुत असुविधाजनक है क्योंकि आपको कोड को अंदर से बाहर पढ़ना होगा। मैं इन कॉल को नेस्टेड से अनुक्रमिक में बदलना चाहता हूं। यही वह pathlib जो आपको करने की अनुमति देता है!

 from pathlib import Path BASE_DIR = Path(__file__).resolve().parent.parent TEMPLATES_DIR = BASE_DIR.joinpath('templates') 

os.path मॉड्यूल को नेस्टेड फ़ंक्शन कॉल की आवश्यकता होती है, लेकिन pathlib हमें समतुल्य परिणाम के साथ Path क्लास के तरीकों और विशेषताओं के लिए लगातार कॉल की चेन बनाने की अनुमति देता है ।

मुझे पता है कि आप क्या सोचते हैं: बंद करो, ये Path ऑब्जेक्ट पहले जैसे नहीं हैं, हम अब पथ लाइनों पर काम नहीं करते हैं! हम बाद में इस मुद्दे पर वापस आएंगे (संकेत: लगभग किसी भी स्थिति में, ये दोनों दृष्टिकोण विनिमेय हैं)।

os ओवरलोडेड

क्लासिक os.path मॉड्यूल पथ के साथ काम करने के लिए डिज़ाइन किया गया है। लेकिन जब आप पथ के साथ कुछ करना चाहते हैं (उदाहरण के लिए, एक निर्देशिका बनाएं), तो आपको दूसरे मॉड्यूल तक पहुंचने की आवश्यकता होगी, अक्सर os ।

os में फ़ाइलों और निर्देशिकाओं के साथ काम करने के लिए उपयोगिताओं का एक समूह होता है: mkdir , getcwd , chmod , stat , remove , rename , rmdir । इसके अलावा chdir , link , walk , listdir , makedirs , renames , removedirs , removedirs , removedirs । और सामान का एक पूरा गुच्छा जो फ़ाइल सिस्टम से संबंधित नहीं है: fork , putenv , getlogin , getlogin , getlogin , system , ... कुछ दर्जन से अधिक चीजें जो मैं यहां उल्लेख नहीं करूंगा।

os मॉड्यूल कार्यों की एक विस्तृत श्रृंखला के लिए डिज़ाइन किया गया है; यह ऑपरेटिंग सिस्टम से जुड़ी हर चीज के साथ एक ऐसा बॉक्स है। os में कई उपयोगिताएं हैं, लेकिन नेविगेट करना हमेशा आसान नहीं होता है: अक्सर मॉड्यूल में थोड़ा सा उकसाना आवश्यक होता है इससे पहले कि आप पाते हैं कि आपको क्या चाहिए।

pathlib अधिकांश फ़ाइल सिस्टम फ़ंक्शन को Path ऑब्जेक्ट में स्थानांतरित करता है।

यहाँ वह कोड है जो src/__pypackages__ बनाता है और src/__pypackages__ हमारी .editorconfig फ़ाइल का नाम बदल src/.editorconfig :

 import os import os.path os.makedirs(os.path.join('src', '__pypackages__'), exist_ok=True) os.rename('.editorconfig', os.path.join('src', '.editorconfig')) 

यहां Path का उपयोग करते हुए समान कोड है

 from pathlib import Path Path('src/__pypackages__').mkdir(parents=True, exist_ok=True) Path('.editorconfig').rename('src/.editorconfig') 

ध्यान दें कि दूसरा कोड नमूना पढ़ना बहुत आसान है, क्योंकि यह बाएं से दाएं व्यवस्थित है - यह सभी तरीकों की श्रृंखला के लिए धन्यवाद है।

glob बारे में मत भूलना

केवल os और os.path में फ़ाइल सिस्टम से संबंधित विधियाँ नहीं हैं। यह glob बारे में भी ध्यान देने योग्य है, जिसे बेकार नहीं कहा जा सकता है।

हम एक विशिष्ट पैटर्न द्वारा फ़ाइलों की खोज करने के लिए glob.glob फ़ंक्शन का उपयोग कर सकते हैं:

 from glob import glob top_level_csv_files = glob('*.csv') all_csv_files = glob('**/*.csv', recursive=True) 

pathlib मॉड्यूल भी इसी तरह के तरीके प्रदान करता है:

 from pathlib import Path top_level_csv_files = Path.cwd().glob('*.csv') all_csv_files = Path.cwd().rglob('*.csv') 

pathlib मॉड्यूल पर स्विच करने के बाद, glob की आवश्यकता पूरी तरह से गायब हो जाती है : आपको जो कुछ भी चाहिए वह पहले से ही Path ऑब्जेक्ट्स का एक अभिन्न अंग है

pathlib सरल चीजों को और भी आसान बनाता है

pathlib कई कठिन परिस्थितियों को सरल करता है, लेकिन कुछ सरल कोड स्निपेट को और भी आसान बना देता है ।

एक या एक से अधिक फ़ाइलों में सभी पाठ पढ़ना चाहते हैं?

आप फ़ाइल को खोल सकते हैं, सामग्री पढ़ सकते हैं, और ब्लॉक के with फाइल को बंद कर सकते हैं:

 from glob import glob file_contents = [] for filename in glob('**/*.py', recursive=True): with open(filename) as python_file: file_contents.append(python_file.read()) 

या आप Path ऑब्जेक्ट पर read_text विधि का उपयोग कर सकते हैं और एक ही परिणाम को एक अभिव्यक्ति में प्राप्त करने के लिए सूचियां उत्पन्न कर सकते हैं:

 from pathlib import Path file_contents = [ path.read_text() for path in Path.cwd().rglob('*.py') ] 

लेकिन अगर आपको किसी फाइल में लिखने की जरूरत हो तो क्या होगा?

यहाँ यह open का उपयोग करने जैसा दिखता है:

 with open('.editorconfig') as config: config.write('# config goes here') 

या आप write_text विधि का उपयोग कर सकते हैं:

 Path('.editorconfig').write_text('# config goes here') 

यदि किसी कारण से आपको संदर्भ प्रबंधक के रूप में या व्यक्तिगत प्राथमिकताओं के लिए open का उपयोग करने की आवश्यकता है, तो Path विकल्प के रूप में open विधि प्रदान करता है:

 from pathlib import Path path = Path('.editorconfig') with path.open(mode='wt') as config: config.write('# config goes here') 

या, Python 3.6 से शुरू होकर, आप अपने Path सीधे open लिए पास कर सकते हैं:

 from pathlib import Path path = Path('.editorconfig') with open(path, mode='wt') as config: config.write('# config goes here') 

पथ ऑब्जेक्ट आपके कोड को अधिक स्पष्ट बनाते हैं

निम्नलिखित चर क्या संकेत देते हैं? उनके अर्थ का अर्थ क्या है?

 person = '{"name": "Trey Hunner", "location": "San Diego"}' pycon_2019 = "2019-05-01" home_directory = '/home/trey' 

प्रत्येक चर एक रेखा की ओर इशारा करता है। लेकिन उनमें से प्रत्येक के अलग-अलग अर्थ हैं: पहला JSON है, दूसरा तारीख है, और तीसरा फ़ाइल पथ है।

वस्तुओं का यह प्रतिनिधित्व थोड़ा अधिक उपयोगी है:

 from datetime import date from pathlib import Path person = {"name": "Trey Hunner", "location": "San Diego"} pycon_2019 = date(2019, 5, 1) home_directory = Path('/home/trey') 

JSON ऑब्जेक्ट्स को डिक्शनरी में डिसेर्बलाइज़ किया जा सकता है, डेट्स को मूल रूप से datetime.date का उपयोग करके दर्शाया जा सकता है, और फ़ाइल पथ ऑब्जेक्ट्स को Path रूप में दर्शाया जा सकता है

Path ऑब्जेक्ट का उपयोग करने से आपका कोड अधिक स्पष्ट हो जाता है। यदि आप तारीखों के साथ काम करना चाहते हैं, तो आप date उपयोग करते हैं। यदि आप फ़ाइल पथों के साथ काम करना चाहते हैं, तो Path उपयोग करें।

मैं OOP का बहुत बड़ा समर्थक नहीं हूं। कक्षाएं अमूर्तता की एक अतिरिक्त परत जोड़ती हैं, और अमूर्त कभी-कभी इसे सरल बनाने के बजाय प्रणाली को जटिल बनाते हैं। उसी समय, मेरा मानना ​​है कि pathlib.Path एक उपयोगी अमूर्त है । बहुत जल्दी, यह एक स्वीकृत निर्णय बन जाता है।

PEP 519 के लिए धन्यवाद, Path साथ काम करने के लिए मानक बन जाते हैं। पायथन 3.6 के समय, अधिकांश os , shutil , os.path इन वस्तुओं के साथ सही os.path काम करती हैं। आप अपने कोड आधार के लिए पारदर्शी, pathlib स्विच कर सकते हैं!

pathlib में क्या कमी है?

हालांकि pathlib शांत है, यह व्यापक नहीं है। निश्चित रूप से कई संभावनाएं हैं जिन्हें मैं मॉड्यूल में शामिल करना चाहूंगा ।

पहली बात जो दिमाग में आती है, वह रास्ते के तरीकों में कमी के बराबर है। हालाँकि, आप फ़ाइल और निर्देशिकाओं को कॉपी / डिलीट / मूविंग करने के लिए Path को shutil सकते हैं, आप उन्हें Path ऑब्जेक्ट पर विधियों के रूप में कॉल नहीं कर सकते।

इसलिए, फ़ाइलों की प्रतिलिपि बनाने के लिए, आपको ऐसा कुछ करने की आवश्यकता है:

 from pathlib import Path from shutil import copyfile source = Path('old_file.txt') destination = Path('new_file.txt') copyfile(source, destination) 

os.chdir पद्धति का कोई एनालॉग भी नहीं है। इसका मतलब है कि यदि आपको वर्तमान निर्देशिका को बदलने की आवश्यकता है तो आपको इसे आयात करने की आवश्यकता है:

 from pathlib import Path from os import chdir parent = Path('..') chdir(parent) 

os.walk फ़ंक्शन के बराबर भी नहीं है। यद्यपि आप बहुत अधिक कठिनाई के बिना walk की भावना में अपना कार्य लिख सकते हैं।

मुझे उम्मीद है कि एक दिन pathlib.Path ऑब्जेक्ट्स में उल्लिखित कुछ संचालन के तरीके होंगे। लेकिन इस परिदृश्य में भी, मुझे os.path और अन्य सभी os.path तुलना में कुछ और के साथ pathlib का उपयोग करना बहुत आसान लगता है ।

क्या pathlib का उपयोग करना हमेशा आवश्यक होता है?

पायथन 3.6 के साथ शुरू, पथ लगभग हर जगह काम करते हैं जो आप तार का उपयोग करते हैं । इसलिए मुझे लगता है कि यदि आप पायथन 3.6 और उससे अधिक का उपयोग कर रहे हैं तो pathlib का उपयोग न करने का कोई कारण नहीं है ।

यदि आप पायथन 3 के पुराने संस्करण का उपयोग कर रहे हैं, तो आप किसी भी समय स्ट्रिंग को प्राप्त करने के लिए Path ऑब्जेक्ट को एक स्ट्रिंग में लपेट सकते हैं यदि आपको लाइनों के देश में लौटने की आवश्यकता है। यह बहुत सुंदर नहीं है, लेकिन यह काम करता है:

 from os import chdir from pathlib import Path chdir(Path('/home/trey')) #   Python 3.6+ chdir(str(Path('/home/trey'))) #      

भाग 2. सवालों के जवाब।

पहला भाग प्रकाशित होने के बाद, कुछ लोगों के कुछ प्रश्न थे। किसी ने कहा कि मैंने os.path और pathlib बेईमानी से तुलना की है। कुछ लोगों ने कहा कि os.path उपयोग करना पायथन समुदाय में इतना os.path हुआ है कि एक नई लाइब्रेरी में स्विच करने में बहुत लंबा समय लगेगा। मैंने प्रदर्शन के बारे में कुछ प्रश्न भी देखे।

इस भाग में, मैं इन मुद्दों पर टिप्पणी करना चाहूंगा। इसे pathlib प्रोटेक्शन और पीईपी 519 के लिए एक लव लेटर दोनों माना जा सकता है।

ईमानदार होने के लिए os.path और pathlib तुलना करें

पिछले भाग में, मैंने निम्नलिखित दो कोड अंशों की तुलना की:

 import os import os.path os.makedirs(os.path.join('src', '__pypackages__'), exist_ok=True) os.rename('.editorconfig', os.path.join('src', '.editorconfig')) 

 from pathlib import Path Path('src/__pypackages__').mkdir(parents=True, exist_ok=True) Path('.editorconfig').rename('src/.editorconfig') 

यह एक अनुचित तुलना की तरह लग सकता है, क्योंकि पहले उदाहरण में os.path.join का उपयोग os.path.join सुनिश्चित करता है कि सभी प्लेटफॉर्म पर सही सीमांकक का उपयोग किया जाता है, जो मैंने दूसरे उदाहरण में नहीं किया। वास्तव में, सब कुछ क्रम में है, क्योंकि पथ स्वचालित रूप से पथ विभाजकों को सामान्य करता है

हम Path ऑब्जेक्ट को विंडोज पर एक स्ट्रिंग में परिवर्तित करके यह साबित कर सकते हैं:

 >>> str(Path('src/__pypackages__')) 'src\\__pypackages__' 

इससे कोई फ़र्क नहीं पड़ता कि हम joinpath मेथड का उपयोग करते हैं, पथ लाइन में '/' , / ऑपरेटर ( Path की एक और अच्छी सुविधा), या Path constructor के लिए व्यक्तिगत तर्क पास करते हैं, हमें वही परिणाम मिलता है:

 >>> Path('src', '.editorconfig') WindowsPath('src/.editorconfig') >>> Path('src') / '.editorconfig' WindowsPath('src/.editorconfig') >>> Path('src').joinpath('.editorconfig') WindowsPath('src/.editorconfig') >>> Path('src/.editorconfig') WindowsPath('src/.editorconfig') 

अंतिम उदाहरण ने उन लोगों से कुछ भ्रम पैदा किया, जिन्होंने सुझाव दिया pathlib कि पथ स्ट्रिंग में \ / को बदलने के लिए पर्याप्त नहीं pathlib । सौभाग्य से, सब कुछ क्रम में है!

Path ऑब्जेक्ट्स के साथ, आपको अब स्लैश की दिशा के बारे में चिंता करने की आवश्यकता नहीं है: / का उपयोग करके अपने सभी रास्तों को परिभाषित करें, और परिणाम किसी भी प्लेटफ़ॉर्म के लिए अनुमानित होगा।

आपको रास्तों को सामान्य करने की चिंता करने की आवश्यकता नहीं है।

यदि आप लिनक्स या मैक चला रहे हैं, तो यह गलती से आपके कोड में बग को जोड़ देता है जो केवल विंडोज उपयोगकर्ताओं को प्रभावित करते हैं। यदि आप वर्तमान प्लेटफ़ॉर्म के लिए उपयुक्त स्लैश को बदलने के लिए os.path.join और \ या os.path.normcase के उपयोग की सावधानीपूर्वक निगरानी नहीं करते हैं, तो आप कोड लिख सकते हैं जो विंडोज पर सही ढंग से काम नहीं करेगा ।

यहाँ विंडोज-विशिष्ट बग का एक उदाहरण दिया गया है:

 import sys import os.path directory = '.' if not sys.argv[1:] else sys.argv[1] new_file = os.path.join(directory, 'new_package/__init__.py') 

इसके अलावा, ऐसा कोड हर जगह सही ढंग से काम करेगा:

 import sys from pathlib import Path directory = '.' if not sys.argv[1:] else sys.argv[1] new_file = Path(directory, 'new_package/__init__.py') 

पहले, प्रोग्रामर पथों को बदलने और सामान्य करने के लिए जिम्मेदार था, जैसे पायथन 2 में, प्रोग्रामर यह तय करने के लिए जिम्मेदार था कि बाइट्स के बजाय यूनिकोड का उपयोग कहां किया जाए। यह अब आपका काम नहीं है - Path आपके लिए ऐसी सभी समस्याओं को हल करता है।

मैं विंडोज का उपयोग नहीं करता हूं, और मेरे पास विंडोज कंप्यूटर नहीं है। लेकिन बहुत से लोग जो मेरे कोड का उपयोग करेंगे वे बहुत संभावना है कि विंडोज का उपयोग करेंगे, और मैं चाहता हूं कि सब कुछ उनके लिए सही ढंग से काम करे।

यदि कोई मौका है कि आपका कोड विंडोज पर चलेगा, तो आपको गंभीरता से pathlib पर स्विच करने पर विचार करना चाहिए।

सामान्यीकरण के बारे में चिंता न करें : जब भी फ़ाइल पथ की बात आती है, तो Path उपयोग करें।

शांत लगता है, लेकिन मेरे पास एक तृतीय-पक्ष पुस्तकालय है जो pathlib उपयोग नहीं करता है!

आपके पास एक बड़ा कोड बेस है जो पथ के रूप में स्ट्रिंग्स के साथ काम करता है। pathlib स्विच क्यों करें यदि इसका मतलब है कि सब कुछ फिर से लिखना होगा?

आइए कल्पना करें कि आपके पास निम्नलिखित कार्य हैं:

 import os import os.path def make_editorconfig(dir_path): """Create .editorconfig file in given directory and return filename.""" filename = os.path.join(dir_path, '.editorconfig') if not os.path.exists(filename): os.makedirs(dir_path, exist_ok=True) open(filename, mode='wt').write('') return filename 

फ़ंक्शन एक निर्देशिका लेता है और .editorconfig एक .editorconfig फ़ाइल बनाता है, कुछ इस तरह से:

 >>> import os.path >>> make_editorconfig(os.path.join('src', 'my_package')) 'src/my_package/.editorconfig' 

यदि आप पंक्तियों को Path प्रतिस्थापित करते हैं, तो सब कुछ भी काम करेगा:

 >>> from pathlib import Path >>> make_editorconfig(Path('src/my_package')) 'src/my_package/.editorconfig' 

लेकिन ... कैसे?

os.path.join Path ऑब्जेक्ट्स को स्वीकार करता है (पायथन 3.6 के बाद से)। वही os.makedirs बारे में कहा जा सकता है।
वास्तव में, अंतर्निहित open फ़ंक्शन Path स्वीकार करता है, shutil Path स्वीकार करता है Path और मानक पुस्तकालय में स्ट्रिंग को स्वीकार करने के लिए उपयोग की जाने वाली सभी चीजें अब Path और तार दोनों के साथ काम करना चाहिए।

हमें इसके लिए PEP 519 को धन्यवाद देना चाहिए, जिसने अमूर्त वर्ग os.PathLike प्रदान किया और घोषणा की कि फ़ाइल पथों के साथ काम करने के लिए सभी अंतर्निहित उपयोगिताओं को अब तार और Path दोनों के साथ काम करना चाहिए।

लेकिन मेरे पसंदीदा पुस्तकालय में पथ, मानक से बेहतर है!

आप पहले से ही एक तृतीय-पक्ष लाइब्रेरी का उपयोग कर रहे हैं जो इसका Path कार्यान्वयन प्रदान करता है, जो मानक एक से अलग है। शायद आप उसे ज्यादा पसंद करते हैं।

उदाहरण के लिए, django-environ , path.py , plumbum और visidata प्रत्येक में अपनी Path ऑब्जेक्ट्स होते हैं। इन पुस्तकालयों में से कुछ pathlib से पुराने हैं, और pathlib से विरासत में लेने का फैसला किया है ताकि उन्हें ऐसे कार्यों में पारित किया जा सके जो पथ के रूप में उम्मीद करते हैं। PEP 519 के लिए धन्यवाद, अपने कोड में तीसरे पक्ष के पुस्तकालयों को एकीकृत करना आसान होगा, और स्ट्रै से विरासत की आवश्यकता के बिना।

आइए कल्पना करें कि आप pathlib का उपयोग नहीं करना चाहते हैं, क्योंकि Path अपरिवर्तनीय वस्तुएं हैं, और आप वास्तव में अपने राज्य को बदलना चाहते हैं। PEP 519 के साथ, आप Path का अपना सबसे अच्छा परिवर्तनशील संस्करण बना सकते हैं। ऐसा करने के लिए, बस __fspath__ विधि लागू करें

Path का कोई भी स्व-लिखित कार्यान्वयन अब मूल रूप से पायथन में निर्मित कार्यों के साथ काम कर सकता है जो फ़ाइल पथ की अपेक्षा करते हैं। यहां तक ​​कि अगर आपको pathlib पसंद नहीं है, तो इसके अस्तित्व का तथ्य अपने स्वयं के Path साथ तीसरे पक्ष के पुस्तकालयों के लिए एक बड़ा प्लस है

लेकिन pathlib.Path और str सही मिश्रण नहीं है?

आप शायद सोचते हैं: यह सब, ज़ाहिर है, बहुत अच्छा है, लेकिन क्या कभी-कभी लाइन-एंड-कभी-पथ के साथ यह दृष्टिकोण मेरे कोड में कुछ जटिलता जोड़ देगा?

इस सवाल का जवाब हां, कुछ हद तक है। लेकिन इस समस्या का एक बहुत सरल समाधान है।

PEP 519 ने PathLike अलावा कुछ और चीजें PathLike : सबसे पहले, यह किसी भी PathLike को स्ट्रिंग में बदलने का एक तरीका है, और दूसरी बात, यह किसी PathLike को Path में बदलने का एक तरीका है।

आइए दो वस्तुओं को लें - एक स्ट्रिंग और Path (या जो भी fspath विधि के साथ है):

 from pathlib import Path import os.path p1 = os.path.join('src', 'my_package') p2 = Path('src/my_package') 

os.fspath फ़ंक्शन दोनों ऑब्जेक्ट को सामान्य करता है और उन्हें स्ट्रिंग्स में बदलता है:

 >>> from os import fspath >>> fspath(p1), fspath(p2) ('src/my_package', 'src/my_package') 

इस स्थिति में, Path इन दोनों वस्तुओं को एक निर्माता में ले जा सकता है और उन्हें Path परिवर्तित कर सकता है:

 >>> Path(p1), Path(p2) (PosixPath('src/my_package'), PosixPath('src/my_package')) 

इसका मतलब है कि यदि आवश्यक हो तो आप make_editorconfig वापस Path बदल सकते हैं:

 >>> from pathlib import Path >>> Path(make_editorconfig(Path('src/my_package'))) PosixPath('src/my_package/.editorconfig') 

हालांकि, निश्चित रूप से, सबसे अच्छा समाधान make_editorconfig का उपयोग करके pathlib को फिर से लिखना होगा।

pathlib बहुत धीमा है

मैंने pathlib प्रदर्शन के बारे में कई बार देखा है। यह सच है - pathlib धीमा हो सकता है। हजारों Path ऑब्जेक्ट्स बनाना प्रोग्राम व्यवहार को महत्वपूर्ण रूप से प्रभावित कर सकता है।

मैंने दो अलग-अलग कार्यक्रमों का उपयोग करके अपने कंप्यूटर पर pathlib और os.path के प्रदर्शन को मापने का निर्णय लिया जो वर्तमान निर्देशिका में सभी .py फ़ाइलों की तलाश करते हैं .py

यहाँ os.walk का संस्करण है:

 from os import getcwd, walk extension = '.py' count = 0 for root, directories, filenames in walk(getcwd()): for filename in filenames: if filename.endswith(extension): count += 1 print(f"{count} Python files found") 

और यहाँ Path.rglob साथ संस्करण है:

 from pathlib import Path extension = '.py' count = 0 for filename in Path.cwd().rglob(f'*{extension}'): count += 1 print(f"{count} Python files found") 

फ़ाइल सिस्टम के साथ काम करने वाले कार्यक्रमों के प्रदर्शन का परीक्षण करना एक मुश्किल काम है, क्योंकि ऑपरेटिंग समय काफी बदल सकता है। मैंने प्रत्येक स्क्रिप्ट को 10 बार चलाने का फैसला किया और प्रत्येक कार्यक्रम के लिए सर्वोत्तम परिणामों की तुलना की।

दोनों कार्यक्रमों में उस निर्देशिका में 97507 फाइलें मिलीं जिनमें मैंने उन्हें चलाया था। पहले वाले ने 1.914 सेकंड में काम किया, दूसरा वाला 3.430 सेकंड में समाप्त हुआ।

जब मैंने extension='' पैरामीटर सेट किया, तो इन कार्यक्रमों में लगभग 600,000 फाइलें मिलती हैं, और अंतर बढ़ता है। पहला कार्यक्रम 1.888 सेकंड में काम किया, और दूसरा 7.485 सेकंड में।

इसलिए, मेरे होम डायरेक्टरी में लॉन्च होने पर, pathlib एक्सटेंशन वाली फ़ाइलों के लिए pathlib लगभग दोगुना है , और चार गुना धीमा है । pathlib और os बीच सापेक्ष प्रदर्शन का अंतर व्यापक है।

मेरे मामले में, यह गति बहुत अधिक नहीं बदलती है। मैंने अपनी निर्देशिका में सभी फ़ाइलों को खोजा और 6 सेकंड खो दिए। यदि मेरे पास 10 मिलियन फ़ाइलों को संसाधित करने का कार्य है, तो मैं सबसे अधिक संभावना इसे फिर से लिखूंगा। लेकिन जबकि ऐसी कोई जरूरत नहीं है, आप इंतजार कर सकते हैं।

यदि आपके पास कोड का एक गर्म टुकड़ा है और pathlib स्पष्ट रूप से इसके संचालन को नकारात्मक रूप से प्रभावित करता है, तो इसे वैकल्पिक के साथ बदलने के साथ कुछ भी गलत नहीं है। आपको कोड का अनुकूलन नहीं करना चाहिए, जो एक अड़चन नहीं है - यह समय की एक अतिरिक्त बर्बादी है, जो आमतौर पर बहुत अधिक निकास के बिना खराब पठनीय कोड की ओर जाता है।

पठनीयता में सुधार

मैं pathlib का उपयोग करते हुए कुछ pathlib उदाहरणों के साथ विचारों की इस धारा को समाप्त करना चाहूंगा। मैंने कोड के कुछ छोटे उदाहरणों को लिया जो फाइलों के साथ काम करते हैं और उन्हें pathlib साथ काम करते हैं। मैं आपके न्यायालय पर टिप्पणी के बिना अधिकांश कोड छोड़ दूंगा - यह तय करूंगा कि आपको कौन सा संस्करण सबसे अच्छा लगा।

यहाँ make_editorconfig फ़ंक्शन है जिसे हमने पहले देखा था:

 import os import os.path def make_editorconfig(dir_path): """Create .editorconfig file in given directory and return filename.""" filename = os.path.join(dir_path, '.editorconfig') if not os.path.exists(filename): os.makedirs(dir_path, exist_ok=True) open(filename, mode='wt').write('') return filename 

और यहाँ pathlib में फिर से लिखा गया संस्करण है:

 from pathlib import Path def make_editorconfig(dir_path): """Create .editorconfig file in given directory and return filepath.""" path = Path(dir_path, '.editorconfig') if not path.exists(): path.parent.mkdir(exist_ok=True, parent=True) path.touch() return path 

यहाँ एक सांत्वना कार्यक्रम है जो एक निर्देशिका के साथ एक पंक्ति लेता है और .gitignore फाइल की सामग्री को प्रिंट करता है, अगर यह मौजूद है:

 import os.path import sys directory = sys.argv[1] ignore_filename = os.path.join(directory, '.gitignore') if os.path.isfile(ignore_filename): with open(ignore_filename, mode='rt') as ignore_file: print(ignore_file.read(), end='') 

pathlib साथ एक ही बात:

 from pathlib import Path import sys directory = Path(sys.argv[1]) ignore_path = directory / '.gitignore' if ignore_path.is_file(): print(ignore_path.read_text(), end='') 

यहां एक प्रोग्राम है जो वर्तमान फ़ोल्डर और सबफ़ोल्डर में सभी डुप्लिकेट फ़ाइलों को प्रिंट करता है:

 from collections import defaultdict from hashlib import md5 from os import getcwd, walk import os.path def find_files(filepath): for root, directories, filenames in walk(filepath): for filename in filenames: yield os.path.join(root, filename) file_hashes = defaultdict(list) for path in find_files(getcwd()): with open(path, mode='rb') as my_file: file_hash = md5(my_file.read()).hexdigest() file_hashes[file_hash].append(path) for paths in file_hashes.values(): if len(paths) > 1: print("Duplicate files found:") print(*paths, sep='\n') 

सी pathlib साथ एक ही बात:

 from collections import defaultdict from hashlib import md5 from pathlib import Path def find_files(filepath): for path in Path(filepath).rglob('*'): if path.is_file(): yield path file_hashes = defaultdict(list) for path in find_files(Path.cwd()): file_hash = md5(path.read_bytes()).hexdigest() file_hashes[file_hash].append(path) for paths in file_hashes.values(): if len(paths) > 1: print("Duplicate files found:") print(*paths, sep='\n') 

, , -, . pathlib .

pathlib.Path

.

/ pathlib.Path . , .

 >>> path1 = Path('dir', 'file') >>> path2 = Path('dir') / 'file' >>> path3 = Path('dir/file') >>> path3 WindowsPath('dir/file') >>> path1 == path2 == path3 True 

Python (. open ) Path , , pathlib , !

 from shutil import move def rename_and_redirect(old_filename, new_filename): move(old, new) with open(old, mode='wt') as f: f.write(f'This file has moved to {new}') 

 >>> from pathlib import Path >>> old, new = Path('old.txt'), Path('new.txt') >>> rename_and_redirect(old, new) >>> old.read_text() 'This file has moved to new.txt' 

pathlib , , PathLike . , , , PEP 519 .

 >>> from plumbum import Path >>> my_path = Path('old.txt') >>> with open(my_path) as f: ... print(f.read()) ... This file has moved to new.txt 

pathlib , ( , ), , .

, pathlib . Python :

 from pathlib import Path gitignore = Path('.gitignore') if gitignore.is_file(): print(gitignore.read_text(), end='') 

pathlib — . !