Scikit-learn: अभिसरण प्रगति पर रिपोर्ट करने के लिए पायथन लॉगिंग का उपयोग करें, यह लंबे समय तक चलने वाले कार्यों के लिए स्तर की जानकारी है

इस पर https://github.com/GaelVaroquaux/scikit-learn/tree/progress_logger पर काम शुरू हो गया है।

जो किया जाना बाकी है, वह संभवत: काफी यांत्रिक कार्य है।

नए ग्रेडिएंट बूस्टिंग मॉड्यूल में भी काम है।

लॉगिंग वास्तव में मेरे अनुभव में उपयोग करना इतना आसान नहीं है, इसलिए -1 इस पर।

क्या कोई इस पर काम कर रहा है?

हम कैसे एक लकड़हारा जोड़ते हैं जो डिफ़ॉल्ट रूप से STDOUT पर प्रिंट करता है? यह काफी सरल होना चाहिए, है ना?

यह मुद्दा 2011 से खुला है और इसलिए मुझे आश्चर्य है कि क्या इसे ठीक किया जा रहा है। मैंने RFECV के साथ इस समस्या का सामना किया है (https://github.com/scikit-learn/scikit-learn/blob/a24c8b464d094d2c468a16ea9f8bf8d42d949f84/sklearn/feature_selection/rfe.py#L273)। मैं प्रगति को प्रिंट करना चाहता था लेकिन डिफ़ॉल्ट वर्बोज़ प्रिंटिंग बहुत सारे संदेश प्रिंट करता है। मैं यह काम करने के लिए बंदर पैच sys.stdout नहीं करना चाहता था और लॉगर को ओवरराइड करना सरल और साफ समाधान होगा।

sklearn में अन्य जारी किए गए हैं जैसे #8105 और #10973 जो sklearn में वास्तविक लॉगिंग से लाभान्वित होंगे। कुल मिलाकर, मुझे लगता है कि लॉगिंग स्केलेर के लिए एक बढ़िया अतिरिक्त होगा।

इस पर काम करने के लिए आपका स्वागत है। शायद एक कॉलबैक सिस्टम से बेहतर है
लॉगिंग

मैं अभी थोड़ा व्यस्त हूं लेकिन मैं किसी भी रूप में स्केलेन में अनुकूलन योग्य लॉगिंग का समर्थन करता हूं (हालांकि मैं मानक पायथन लॉगिंग पसंद करता हूं)।

क्या इस बारे में कोई चर्चा हुई है कि जब स्किकिट-लर्न लॉगिंग का उपयोग करना शुरू करेगा तो verbose=True क्या अर्थ होगा? हम इसके साथ dask-ml में थोड़ा निपट रहे हैं: https://github.com/dask/dask-ml/pull/528।

यह देखते हुए कि पुस्तकालयों को लॉगिंग कॉन्फ़िगरेशन नहीं करना चाहिए, यह उपयोगकर्ता पर निर्भर करता है कि वह चीजों को उचित रूप से लॉग करने के लिए अपने "एप्लिकेशन" (जो सिर्फ एक स्क्रिप्ट या इंटरैक्टिव सत्र हो सकता है) को कॉन्फ़िगर कर सकता है। यह हमेशा सही ढंग से करना आसान नहीं होता है।

https://github.com/dask/dask-ml/pull/528 में मेरा प्रस्ताव verbose=True लिए है जिसका अर्थ है "मेरे लिए अस्थायी रूप से लॉगिंग कॉन्फ़िगर करें"। आप लॉगिंग को कॉन्फ़िगर करने के लिए एक संदर्भ प्रबंधक का उपयोग कर सकते INFO स्तर के संदेश वर्तमान व्यवहार से मेल खाने के लिए स्टडआउट पर मुद्रित हों।

क्या अस्थायी रूप से इसका मतलब यह भी है कि हैंडलर सेट अप उसके लिए विशिष्ट है
अनुमानक या अनुमानक प्रकार?

dask/dask-ml#528 में मेरा प्रस्ताव वर्बोज़ = ट्रू के लिए है जिसका अर्थ है "मेरे लिए अस्थायी रूप से लॉगिंग कॉन्फ़िगर करें"।

यह एक अच्छा संतुलन लगता है। लॉगिंग मॉड्यूल का उपयोग करना उपयोगकर्ता के अनुकूल नहीं है। एक और "हैक" डिफ़ॉल्ट रूप से info का उपयोग करना होगा, लेकिन जब कोई उपयोगकर्ता verbose=True सेट करता है तो लॉग को warning बढ़ाया जा सकता है। यह काम करेगा क्योंकि चेतावनियां डिफ़ॉल्ट रूप से प्रदर्शित होती हैं।

मुझे लगता है कि जब उपयोगकर्ता अधिक मांगता है तो विशिष्ट संदेशों का स्तर बदल जाता है
वर्बोसिटी इसके बिल्कुल विपरीत है कि कैसे लॉगिंग मॉड्यूल का मतलब है
काम। लेकिन स्थानीय हैंडलर चेतावनी से सूचना से डीबग में बदल सकता है
वर्बोज़ बढ़ने पर स्ट्रीम पर स्तर

@ jnothman की टिप्पणी मेरे विचारों से मेल खाती है। scikit-learn हमेशा संदेश उत्सर्जित करेगा, और वर्बोज़ कीवर्ड लॉगर स्तर और हैंडलर को नियंत्रित करता है।

लेकिन स्थानीय हैंडलर चेतावनी से सूचना से डीबग में बदल सकता है
वर्बोज़ बढ़ने पर स्ट्रीम पर स्तर

ठीक है, चलो इसके साथ चलते हैं। वर्तमान में लॉगिंग स्तर https://docs.python.org/3/library/logging.html#logging -levels हैं। डिफ़ॉल्ट रूप से, हम INFO उपयोग कर सकते हैं, जो डिफ़ॉल्ट रूप से उत्सर्जित नहीं होता है। जब verbose=1 , तो हमारे पास हैंडलर परिवर्तन जानकारी -> चेतावनी, और डीबग -> जानकारी होती है। जब हम verbose>=2 सेट करते हैं, तब भी हमारे पास जानकारी -> चेतावनी होती है लेकिन डीबग -> चेतावनी भी होती है, और अनुमानक verbose>=2 व्याख्या कर सकता है जिसका अर्थ है "वर्बोज़ बढ़ने पर अधिक डीबग संदेश उत्सर्जित करें"। विभिन्न अनुमानकों के बीच यह अर्थ भिन्न हो सकता है।

तुम क्या सोचते हो?

नमस्ते, मुझे इस मुद्दे में बहुत दिलचस्पी है। मुझे logging साथ कुछ अनुभव है और अगर कुछ आम सहमति और योजना तक पहुंच जाती है तो यहां एक वृद्धि को लागू करने में मदद करना अच्छा लगेगा।

यहां उल्लिखित विचारों को फिर से लिखने में मददगार हो सकता है:

1. कॉलबैक पैटर्न का उपयोग करें
2. verbose आधार पर संदेश का स्तर बदलें

    if verbose:
        logger.debug(message)
    else:
        logger.info(message)

1. logger . के आधार पर verbose के स्तर को बदलें

    if verbose:
        logger.selLevel("DEBUG")

1. वर्बोज़ के आधार पर स्तर DEBUG साथ एक हैंडलर जोड़ें

    if verbose:
        verbose_handler = logging.StreamHandler()
        verbose_handler.setLevel("DEBUG")
        logger.addHandler(verbose_handler)

इन विकल्पों पर मेरा विचार:

विकल्प 1 या विकल्प 4 शायद सबसे अच्छा होगा।

• विकल्प 1 (कॉलबैक) अच्छा है कि यह सबसे अज्ञेयवादी है (लोग अपनी इच्छानुसार चीजों को लॉग कर सकते हैं)। लेकिन यह मैसेजिंग/स्टेट कैप्चर के नजरिए से कम लचीला हो सकता है। (क्या कॉलबैक केवल कुछ आंतरिक लूप पुनरावृत्ति के अनुसार एक या एक बार कॉल नहीं किए जाते हैं?)
• विकल्प 2, जैसा कि यहां चर्चा की गई है, मुझे लगता है कि logging पुस्तकालय का दुरुपयोग कर रहा है
• विकल्प 3 काम करता है लेकिन, मुझे लगता है, logging पुस्तकालय का उपयोग करने के उद्देश्य के हिस्से को हरा देता है। यदि sklearn logging का उपयोग करता है, तो उपयोगकर्ता स्वयं logging माध्यम से वर्बोसिटी को समायोजित कर सकते हैं, उदाहरण के लिए import logging; logging.getLogger("sklearn").setLevel("DEBUG") ।
• विकल्प 4 शायद सबसे विहित है। दस्तावेज़ NullHandler s के अलावा लाइब्रेरी कोड में _not_ बनाने वाले हैंडलर का सुझाव देते हैं, लेकिन मुझे लगता है कि यहां यह समझ में आता है, क्योंकि स्केलेर में verbose झंडे हैं। इस मामले में, लॉग प्रिंटिंग लाइब्रेरी की "फीचर" है।

पांचवां विकल्प verbose झंडे को हटाना, हर जगह logging उपयोग करना और उपयोगकर्ताओं को logging API के माध्यम से वर्बोसिटी को समायोजित करने देना होगा। यह वही है जो logging लिए डिज़ाइन किया गया था।

@grisaitis धन्यवाद! https://github.com/scikit-learn/scikit-learn/issues/17439 और https://github.com/scikit-learn/scikit-learn/pull/16925#issuecomment -638956487 में हाल ही में संबंधित चर्चाएं भी देखें (कॉलबैक के संबंध में)। आपकी मदद की बहुत सराहना की जाएगी, मुख्य मुद्दा यह है कि हमने अभी तक तय नहीं किया है कि कौन सा दृष्टिकोण सबसे अच्छा होगा :)

मैं वर्बोज़ को हटाने का समर्थन करूंगा, जैसा कि मुझे प्रति-अनुमानक कॉन्फ़िगरेशन मिल रहा है
निराशाजनक, और वर्बोज़ के संख्यात्मक मान मनमाने ढंग से, खराब
प्रलेखित, आदि। प्रति वर्ग विन्यास होने से नियंत्रित किया जाएगा
एकाधिक स्किकिट-लर्नर नाम सीखें।

पांचवां विकल्प वर्बोज़ फ़्लैग को हटाना, हर जगह लॉगिंग का उपयोग करना और उपयोगकर्ताओं को लॉगिंग एपीआई के माध्यम से वर्बोसिटी को समायोजित करने देना होगा। यह वही है जो लॉगिंग के लिए डिज़ाइन किया गया था।

मैं वर्बोज़ को हटाने का समर्थन करूंगा, जैसा कि मुझे प्रति-अनुमानक कॉन्फ़िगरेशन मिल रहा है
निराशाजनक, और वर्बोज़ के संख्यात्मक मान मनमाने ढंग से, खराब
प्रलेखित,

मुझे लगता है कि verbose से छुटकारा पाना और लॉगिंग स्तरों का उपयोग करना बहुत अच्छा होगा। केवल नकारात्मक पक्ष जो मैं देख रहा हूं वह यह है कि यह लॉगिंग को थोड़ा कम खोजने योग्य बना देगा।

साथ ही, एक चीज जो लॉगिंग प्रदान करती है वह यह है कि आप प्रत्येक लॉगिंग संदेश में अतिरिक्त जानकारी संलग्न कर सकते हैं, न कि केवल स्ट्रिंग्स। तो उपयोगी सामान का पूरा निर्देश। इसलिए यदि आप सीखने के दौरान नुकसान की रिपोर्ट करना चाहते हैं, तो आप ऐसा कर सकते हैं और संख्यात्मक मान संग्रहीत कर सकते हैं। इससे भी अधिक, आप दोनों संख्यात्मक मान को संख्या के रूप में संग्रहीत कर सकते हैं और उपयोगकर्ता के अनुकूल स्ट्रिंग को प्रारूपित करने के लिए इसका उपयोग कर सकते हैं, जैसे: logger.debug("Current loss: %(loss)s", {'loss': loss}) । मुझे यह सामान्य रूप से बहुत उपयोगी लगता है और अगर स्केलेर इसे भी उजागर करता है तो मुझे अच्छा लगेगा।

मुझे लगता है कि मॉड्यूल या अनुमानक स्तर के लॉगर अभी के लिए थोड़ा अधिक है और हमें कुछ सरल से शुरू करना चाहिए जो हमें इसे बाद में विस्तारित करने की अनुमति देता है।
साथ ही, हम जो कुछ भी करते हैं, उसे उपयोगकर्ताओं को वर्तमान व्यवहार को उचित रूप से आसानी से पुन: पेश करने की अनुमति देनी चाहिए।

लॉगिंग और जॉबलिब कैसे इंटरैक्ट करते हैं? लॉगिंग स्तर संरक्षित नहीं है (जैसा कि मुझे लगता है अपेक्षित):

import logging
logger = logging.getLogger('sklearn')
logger.setLevel(2)

def get_level():
    another_logger = logging.getLogger('sklearn')
    return another_logger.level

results = Parallel(n_jobs=2)(
    delayed(get_level)() for _ in range(2)
)
results

```
[0, 0]

But that's probably not needed, since this works:
```python
import logging
import sys
logger = logging.getLogger('sklearn')
logger.setLevel(1)

handler = logging.StreamHandler(sys.stdout)
logger.addHandler(handler)


def log_some():
    another_logger = logging.getLogger('sklearn')
    another_logger.critical("log something")

results = Parallel(n_jobs=2)(
    delayed(log_some)() for _ in range(2)
)

ईमानदारी से, मुझे पूरा यकीन नहीं है कि यह कैसे काम करता है।

स्टडआउट और स्टडर दोनों ज्यूपिटर बीटीडब्ल्यू में दिखाई नहीं देते हैं।

मेरा सपना: एक पंक्ति के साथ वर्तमान व्यवहार का अनुमान प्राप्त करने में सक्षम होने के कारण, इसके बजाय आसानी से प्रगति सलाखों या साजिश अभिसरण का उपयोग करने में सक्षम होना।

पुनः वर्बोज़: वर्बोज़ को पदावनत करने के लिए शायद यह क्लीनर है, लेकिन वर्बोज़ को बहिष्कृत करना और अनुमानक-स्तर लॉगिंग नहीं होने से एक अनुमानक को लॉग करना थोड़ा मुश्किल हो जाएगा लेकिन दूसरा नहीं। मुझे लगता है कि उपयोगकर्ता को संदेशों को फ़िल्टर करना ठीक है, हालांकि।

हे सब, दोस्ताना जवाब और जानकारी के लिए धन्यवाद। मैं अन्य मुद्दों को पढ़ता हूं और कुछ विचार रखता हूं।

joblib मुश्किल होगा। हालांकि मेरे पास कुछ विचार हैं।

@amueller जो बहुत अजीब है। मैंने आपका उदाहरण पुन: पेश किया। चीजों के साथ काम करते हैं concurrent.futures.ProcessPoolExecutor है, जो मुझे लगता है कि joblib का उपयोग करता है ...

ऐसा लगता है जैसे joblib राज्य को logging । किसी भी joblib विशेषज्ञों के पास इस बात का विचार है कि क्या हो सकता है?

import concurrent.futures
import logging
import os

logger = logging.getLogger("demo🙂")
logger.setLevel("DEBUG")

handler = logging.StreamHandler()
handler.setFormatter(
    logging.Formatter("%(process)d (%(processName)s) %(levelname)s:%(name)s:%(message)s")
)
logger.addHandler(handler)

def get_logger_info(_=None):
    another_logger = logging.getLogger("demo🙂")
    print(os.getpid(), "another_logger:", another_logger, another_logger.handlers)
    another_logger.warning(f"hello from {os.getpid()}")
    return another_logger

if __name__ == "__main__":
    print(get_logger_info())

    print()
    print("concurrent.futures demo...")
    with concurrent.futures.ProcessPoolExecutor(2) as executor:
        results = executor.map(get_logger_info, range(2))
        print(list(results))

    print()
    print("joblib demo (<strong i="17">@amueller</strong>'s example #2)...")
    from joblib import Parallel, delayed
    results = Parallel(n_jobs=2)(delayed(get_logger_info)() for _ in range(2))
    print(results)

जो आउटपुट

19817 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19817 (MainProcess) WARNING:demo🙂:hello from 19817
<Logger demo🙂 (DEBUG)>

concurrent.futures demo...
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

joblib demo (<strong i="21">@amueller</strong>'s example #2)...
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

मुझे लगता है कि आपको मुख्य प्रक्रिया में मुख्य लॉगर को लॉगिंग संदेश भेजने के लिए जॉबलिब स्पॉन प्रक्रियाओं को कॉन्फ़िगर करना चाहिए। तब कोई केवल मुख्य प्रक्रिया में लॉगिंग को नियंत्रित कर सकता है। कुछ इस तरह या इस । तो लॉगिंग कतार सिंक और स्रोत हैं और आप उन्हें एक साथ जोड़ सकते हैं। हम इसे अपने क्लस्टर पर उपयोग करते हैं, सभी मशीनों पर सभी श्रमिकों से सभी लॉगिंग को केंद्रीय स्थान पर भेजने के लिए, इसे उपयोगकर्ता के कंप्यूटर पर दिखाने के लिए।

@mitar मैं सहमत हूं, मुझे लगता है कि यह सबसे अच्छी शर्त हो सकती है। (जरूरी नहीं कि नेटवर्क-आधारित कतारें, बल्कि अंतर-प्रक्रिया संचार कतारें)

मैं वास्तव में logging के QueueHandler / QueueListener का उपयोग करके joblib और concurrent.futures साथ परीक्षण करने के लिए वास्तव में एक उदाहरण कोडिंग कर रहा हूं। यहां पालन करेंगे।

आपके अन्य सुझाव को भी पसंद करें:

साथ ही, एक चीज जो लॉगिंग प्रदान करती है वह यह है कि आप प्रत्येक लॉगिंग संदेश में अतिरिक्त जानकारी संलग्न कर सकते हैं, न कि केवल स्ट्रिंग्स। तो उपयोगी सामान का पूरा निर्देश। इसलिए यदि आप सीखने के दौरान नुकसान की रिपोर्ट करना चाहते हैं, तो आप ऐसा कर सकते हैं और संख्यात्मक मान संग्रहीत कर सकते हैं। इससे भी अधिक, आप दोनों संख्यात्मक मान को संख्या के रूप में संग्रहीत कर सकते हैं और उपयोगकर्ता के अनुकूल स्ट्रिंग को प्रारूपित करने के लिए इसका उपयोग कर सकते हैं, जैसे: logger.debug("Current loss: %(loss)s", {'loss': loss}) । मुझे यह सामान्य रूप से बहुत उपयोगी लगता है और अगर स्केलेर इसे भी उजागर करता है तो मुझे अच्छा लगेगा।

मैंने extra परम और एक कस्टम हैंडलर वर्ग का उपयोग करके गाऊसी मिश्रण मॉडलिंग का एक दृश्य लागू किया। राज्य को पास करने के लिए बहुत अच्छी तरह से काम करता है, और उपयोगकर्ता को यह तय करने देता है कि राज्य को कैसे संभालना है।

joblib की विशिष्टताओं को भी फिर से देखें जिन्हें मैंने ऊपर देखा है ... मैं इसे स्वीकार करने जा रहा हूं जैसा कि है और दायरे से बाहर है। एक कतार आधारित डिजाइन वैसे भी सबसे अधिक लचीला होगा।

QueueHandler का उपयोग करने की एकमात्र सीमा, जिसके बारे में मैं सोच सकता हूं, यह है कि कोई भी extra राज्य ( logger.debug("message", extra={...} ) यह है कि extra dict कतार के लिए क्रमबद्ध होना चाहिए। तो कोई numpy सरणी नहीं। :/ हालांकि किसी अन्य मुद्दे के बारे में नहीं सोच सकता

मैं वास्तव में अभी QueueHandler/QueueListener का उपयोग करके एक उदाहरण कोडिंग कर रहा हूं,

हां, आपको हमेशा कतार हैंडलर का उपयोग करना चाहिए, क्योंकि आप कभी नहीं जानते कि सॉकेट ब्लॉकों पर कब भेजा जाता है और आप लॉगिंग अवरुद्ध होने के कारण मॉडल को धीमा नहीं करना चाहते हैं।

साथ ही, आपको extra का उपयोग करने की भी आवश्यकता नहीं है। मुझे लगता है कि logger.debug("message %(foo)s", {'foo': 1, 'bar': 2}) बस काम करता है।

हां, आपको हमेशा कतार हैंडलर का उपयोग करना चाहिए, क्योंकि आप कभी नहीं जानते कि सॉकेट ब्लॉकों पर कब भेजा जाता है और आप लॉगिंग अवरुद्ध होने के कारण मॉडल को धीमा नहीं करना चाहते हैं।

joblib मामले के लिए, अगर हमने QueueHandler / QueueListener , तो हमें प्रक्रिया पूल में किस स्थिति में जाना होगा? बस queue , है ना?

साथ ही, आपको extra का उपयोग करने की भी आवश्यकता नहीं है। मुझे लगता है कि logger.debug("message %(foo)s", {'foo': 1, 'bar': 2}) बस काम करता है।

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

जॉबलिब मामले के लिए, यदि हमने QueueHandler/QueueListener लागू किया है, तो हमें प्रक्रिया पूल में किस राज्य को पास करना होगा? बस कतार, है ना?

मुझे ऐसा लगता है। मैंने इस प्रक्रिया की सीमाओं का उपयोग नहीं किया है, लेकिन ऐसा लगता है कि उनके पास मल्टीप्रोसेसिंग के लिए एक दस्तावेज समर्थन है, इसलिए इसे जॉबलिब के साथ भी काम करना चाहिए। मैं उसी प्रक्रिया के अंदर QueueHandler/QueueListener का उपयोग कर रहा हूं। लॉगिंग को डिकूप करने के लिए लॉगिंग ट्रांसपोर्ट से लिखता है। तो QueueHandler -> QueueListener -> केंद्रीय लॉगिंग सेवा को भेजें। लेकिन प्रलेखन से ऐसा लगता है कि यह मल्टीप्रोसेसिंग कतार के माध्यम से काम कर सकता है।

मुझे राज्य को टेक्स्ट में परिवर्तित किए बिना लॉग इन करना भी उपयोगी लगता है

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

@grisaitis FYI करें यदि आप किसी कमिट में किसी नाम का उल्लेख करते हैं, तो हर बार जब आप कमिट के साथ कुछ भी करते हैं (जैसे इसे रीबेस करना या इसे मर्ज करना या इसे पुश करना), व्यक्ति को एक ईमेल मिलता है, इसलिए यह आमतौर पर हतोत्साहित होता है;)

उस एंड्रियास के बारे में खेद है! यह शर्मनाक है... मैं सिर्फ अच्छी तरह से प्रलेखित काम करने की कोशिश कर रहा था। भविष्य में बचना होगा।

उस रेपो में मुझे पता चला कि कैसे एक QueueHandler/QueueListener कॉम्बो के साथ लॉगिंग joblib साथ काम कर सकती है। अच्छा काम करने लगता है।

पहले चरण के रूप में मैं स्केलेर के एक हिस्से में उस दृष्टिकोण के साथ लॉगिंग लागू करूंगा जहां joblib का उपयोग किया जाता है। शायद पहनावा मॉडल में से एक। एक नया पीआर खोलेंगे।

जॉबलिब मामले के लिए, यदि हमने QueueHandler / QueueListener लागू किया है,

हां, ऐसा लगता है कि मल्टीप्रोसेसिंग के मामले में लॉगिंग मॉड्यूल और कॉलबैक का उपयोग करने पर मॉनिटरिंग थ्रेड (यहां QueueListener ) को शुरू/बंद करना आवश्यक होगा (https:// में मल्टीप्रोसेसिंग के साथ कॉलबैक का अनुमानित उदाहरण: github.com/scikit-learn/scikit-learn/pull/16925#issuecomment-656184396

तो मुझे लगता है कि मैंने "काम" के ऊपर जो किया वह एकमात्र कारण था कि यह stdout पर मुद्रित था जो साझा संसाधन था और print python3 में थ्रेडसेफ या ऐसा कुछ है?

तो मुझे लगता है कि मैंने "काम" के ऊपर जो किया वह एकमात्र कारण था कि यह stdout पर मुद्रित था जो साझा संसाधन था और प्रिंट python3 या ऐसा कुछ में थ्रेडसेफ है?

प्रिंट थ्रेड सुरक्षित नहीं है। वे सिर्फ एक ही फाइल डिस्क्रिप्टर को प्रिंट करते हैं। संभवत: अधिक समय तक चलने पर आप देखेंगे कि संदेश कभी-कभी अंतःस्थापित हो जाते हैं और रेखाएं मिश्रित हो जाती हैं।