stream=True मुळे प्रॉक्सीद्वारे येणाऱ्या प्रतिसादाचा बॉडी पूर्ण डाउनलोड होण्यापूर्वीच प्रक्रिया सुरू करता येते. CSV साठी csv.reader ला मजकूर-ओळ इटरेटर द्या, जेणेकरून अवतरण चिन्हांमधील डेलिमीटर आणि बहु-ओळ रेकॉर्ड CSV डेटाच राहतील.

अर्धविराम वापरणाऱ्या उदाहरणात्मक UTF-8 फाइलसाठी:

import csv
import requests

routes = {'https': 'http://proxy.example:8080'}
with requests.get(
    'https://data.example/observations.csv',
    proxies=routes,
    stream=True,
    timeout=(5, 30),
) as response:
    response.raise_for_status()
    response.encoding = 'utf-8'
    lines = (
        line + '\n'
        for line in response.iter_lines(
            chunk_size=65536, decode_unicode=True)
    )
    for record in csv.reader(lines, delimiter=';'):
        if record and record[0] == 'wanted':
            print(record)
            break

फाइलचे प्रत्यक्ष एन्कोडिंग आणि डायलेक्ट निवडा. अनुमत सार्वजनिक-प्रॉक्सी मार्गावर सार्वजनिक CSV डाउनलोडसाठी, HTTP प्रॉक्सी सूची routes URL साठी उमेदवार देते. ही आवृत्ती भौतिक ओळ-शेवट LF मध्ये सामान्यीकृत करते: iter_lines ते काढून टाकते आणि जनरेटर CSV पार्सरसाठी नवीन ओळ पुन्हा जोडतो. अवतरण चिन्हांतील फील्ड दुसऱ्या भौतिक ओळीवर चालू राहिल्यास हे महत्त्वाचे ठरते.

एम्बेड केलेल्या CRLF अक्षरांचे बाइट-अचूक जतन आवश्यक असलेल्या कार्यप्रवाहांसाठी, त्या ओळ-शेवट टिकवणारी स्ट्रीमिंग मजकूर-आवरण रचना वापरा. उदाहरणातील जाणीवपूर्वक सामान्यीकरण रेकॉर्ड-केंद्रित प्रक्रियेसाठी योग्य आहे जिथे LF हे इच्छित प्रतिनिधित्व आहे.

एक प्रतिसाद, अनेक वाचन

इटरेटर एका HTTP प्रतिसादातून तुकडे वापरतो. तो प्रत्येक ओळीसाठी नवीन विनंती पाठवत नाही. HTTP Range विनंत्या वेगळी पद्धत आहेत आणि त्या नैसर्गिकरित्या CSV रेकॉर्डच्या सीमा ओळखत नाहीत.

response.text कॉल करणे किंवा सर्व ओळी सूचीत गोळा करणे संपूर्ण सामग्री पुन्हा मेमरीत आणेल. स्ट्रीमिंगला तरीही वाहतूक बफर आणि सध्याच्या रेकॉर्डसाठी जागा लागते, ज्यात स्वतः मोठे फील्ड असू शकते.

प्रतिसाद संदर्भ लूपमधून बाहेर पडताना बॉडी बंद करतो, लवकर जुळणी झाल्यासही. वाचन कालमर्यादा येणाऱ्या डेटाच्या प्रतीक्षेला मर्यादित करते, मोठ्या फाइल हस्तांतरणाच्या एकूण आयुष्याला नाही.

संबंधित लेख