$\"The$ $\"The$
Picture by Creator<\/span><\/center>
\n\u00a0<\/p>\n
#\u00a0<\/span>Introduction<\/h2>\n
\u00a0
Most Python builders deal with logging as an afterthought. They throw round print()<\/code> statements throughout growth, perhaps swap to primary logging later, and assume that’s sufficient. However when points come up in manufacturing, they be taught they’re lacking the context wanted to diagnose issues effectively.<\/p>\n
Correct logging strategies provide you with visibility into software habits, efficiency patterns, and error situations. With the precise method, you may hint consumer actions, establish bottlenecks, and debug points with out reproducing them domestically. Good logging turns debugging from guesswork into systematic problem-solving.<\/p>\n
This text covers the important logging patterns that Python builders can use. You’ll discover ways to construction log messages for searchability, deal with exceptions with out shedding context, and configure logging for various environments. We’ll begin with the fundamentals and work our method as much as extra superior logging methods that you need to use in tasks immediately. We will likely be utilizing solely the logging module<\/a><\/strong>.<\/p>\n
You could find the code on GitHub<\/a><\/strong>.<\/p>\n
\u00a0<\/p>\n
#\u00a0<\/span>Setting Up Your First Logger<\/h2>\n\u00a0
As a substitute of leaping straight to complicated configurations, allow us to perceive what a logger really does. We’ll create a primary logger that writes to each the console and a file.
\u00a0<\/p>\n\nimport logging\n\nlogger = logging.getLogger('my_app')\nlogger.setLevel(logging.DEBUG)\n\nconsole_handler = logging.StreamHandler()\nconsole_handler.setLevel(logging.INFO)\n\nfile_handler = logging.FileHandler('app.log')\nfile_handler.setLevel(logging.DEBUG)\n\nformatter = logging.Formatter(\n    '%(asctime)s - %(title)s - %(levelname)s - %(message)s'\n)\nconsole_handler.setFormatter(formatter)\nfile_handler.setFormatter(formatter)\n\nlogger.addHandler(console_handler)\nlogger.addHandler(file_handler)\n\nlogger.debug('It is a debug message')\nlogger.information('Utility began')\nlogger.warning('Disk house operating low')\nlogger.error('Failed to hook up with database')\nlogger.crucial('System shutting down')<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
Here’s what every bit of the code does.<\/p>\n
The getLogger()<\/code> perform creates a named logger occasion. Consider it as making a channel on your logs. The title ‘my_app’ helps you establish the place logs come from in bigger purposes.<\/p>\n
We set the logger stage to DEBUG<\/code>, which implies it can course of all messages. Then we create two handlers: one for console output and one for file output. Handlers management the place logs go.<\/p>\n
The console handler solely exhibits INFO<\/code> stage and above, whereas the file handler captures all the things, together with DEBUG<\/code> messages. That is helpful since you need detailed logs in recordsdata however cleaner output on display screen.<\/p>\n
The formatter determines how your log messages look. The format string makes use of placeholders like %(asctime)s<\/code> for the timestamp and %(levelname)s<\/code> for severity.<\/p>\n
\u00a0<\/p>\n#\u00a0<\/span>Understanding Log Ranges and When to Use Every<\/h2>\n\u00a0
Python’s logging module<\/a><\/strong> has 5 commonplace ranges, and figuring out when to make use of every one is necessary for helpful logs.<\/p>\n
Right here is an instance:
\u00a0<\/p>\n
\nlogger = logging.getLogger('payment_processor')\nlogger.setLevel(logging.DEBUG)\n\nhandler = logging.StreamHandler()\nhandler.setFormatter(logging.Formatter('%(levelname)s: %(message)s'))\nlogger.addHandler(handler)\n\ndef process_payment(user_id, quantity):\n    logger.debug(f'Beginning fee processing for consumer {user_id}')\n\n    if quantity <= 0:\n        logger.error(f'Invalid fee quantity: {quantity}')\n        return False\n\n    logger.information(f'Processing ${quantity} fee for consumer {user_id}')\n\n    if quantity > 10000:\n        logger.warning(f'Giant transaction detected: ${quantity}')\n\n    attempt:\n        # Simulate fee processing\n        success = charge_card(user_id, quantity)\n        if success:\n            logger.information(f'Cost profitable for consumer {user_id}')\n            return True\n        else:\n            logger.error(f'Cost failed for consumer {user_id}')\n            return False\n    besides Exception as e:\n        logger.crucial(f'Cost system crashed: {e}', exc_info=True)\n        return False\n\ndef charge_card(user_id, quantity):\n    # Simulated fee logic\n    return True\n\nprocess_payment(12345, 150.00)\nprocess_payment(12345, 15000.00)<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
Allow us to break down when to make use of every stage:<\/p>\n\nDEBUG<\/strong> is for detailed info helpful throughout growth. You’d use it for variable values, loop iterations, or step-by-step execution traces. These are often disabled in manufacturing.\n<\/li>\n
INFO<\/strong> marks regular operations that you just need to report. Beginning a server, finishing a process, or profitable transactions go right here. These verify your software is working as anticipated.\n<\/li>\n
WARNING<\/strong> alerts one thing sudden however not breaking. This contains low disk house, deprecated API utilization, or uncommon however dealt with conditions. The applying continues operating, however somebody ought to examine.\n<\/li>\n
ERROR<\/strong> means one thing failed however the software can proceed. Failed database queries, validation errors, or community timeouts belong right here. The particular operation failed, however the app retains operating.\n<\/li>\nCRITICAL<\/strong> signifies critical issues which may trigger the applying to crash or lose information. Use this sparingly for catastrophic failures that want quick consideration.\n<\/li>\n<\/ul>\nWhenever you run the above code, you’ll get:
\u00a0<\/p>\n\nDEBUG: Beginning fee processing for consumer 12345\nDEBUG:payment_processor:Beginning fee processing for consumer 12345\nINFO: Processing $150.0 fee for consumer 12345\nINFO:payment_processor:Processing $150.0 fee for consumer 12345\nINFO: Cost profitable for consumer 12345\nINFO:payment_processor:Cost profitable for consumer 12345\nDEBUG: Beginning fee processing for consumer 12345\nDEBUG:payment_processor:Beginning fee processing for consumer 12345\nINFO: Processing $15000.0 fee for consumer 12345\nINFO:payment_processor:Processing $15000.0 fee for consumer 12345\nWARNING: Giant transaction detected: $15000.0\nWARNING:payment_processor:Giant transaction detected: $15000.0\nINFO: Cost profitable for consumer 12345\nINFO:payment_processor:Cost profitable for consumer 12345\nTrue<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
Subsequent, allow us to proceed to grasp extra about logging exceptions.<\/p>\n
\u00a0<\/p>\n#\u00a0<\/span>Logging Exceptions Correctly<\/h2>\n\u00a0
When exceptions happen, you want extra than simply the error message; you want the complete stack hint. Right here is learn how to seize exceptions successfully.
\u00a0<\/p>\n\nimport json\n\nlogger = logging.getLogger('api_handler')\nlogger.setLevel(logging.DEBUG)\n\nhandler = logging.FileHandler('errors.log')\nformatter = logging.Formatter(\n    '%(asctime)s - %(title)s - %(levelname)s - %(message)s'\n)\nhandler.setFormatter(formatter)\nlogger.addHandler(handler)\n\ndef fetch_user_data(user_id):\n    logger.information(f'Fetching information for consumer {user_id}')\n\n    attempt:\n        # Simulate API name\n        response = call_external_api(user_id)\n        information = json.hundreds(response)\n        logger.debug(f'Acquired information: {information}')\n        return information\n    besides json.JSONDecodeError as e:\n        logger.error(\n            f'Didn't parse JSON for consumer {user_id}: {e}',\n            exc_info=True\n        )\n        return None\n    besides ConnectionError as e:\n        logger.error(\n            f'Community error whereas fetching consumer {user_id}',\n            exc_info=True\n        )\n        return None\n    besides Exception as e:\n        logger.crucial(\n            f'Sudden error in fetch_user_data: {e}',\n            exc_info=True\n        )\n        elevate\n\ndef call_external_api(user_id):\n    # Simulated API response\n    return '{\"id\": ' + str(user_id) + ', \"title\": \"John\"}'\n\nfetch_user_data(123)<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
The important thing right here is the exc_info=True<\/code> parameter. This tells the logger to incorporate the complete exception traceback in your logs. With out it, you solely get the error message, which regularly is just not sufficient to debug the issue.<\/p>\n
Discover how we catch particular exceptions first, then have a normal Exception<\/code> handler. The particular handlers allow us to present context-appropriate error messages. The final handler catches something sudden and re-raises it as a result of we have no idea learn how to deal with it safely.<\/p>\n
Additionally discover we log at ERROR<\/code> for anticipated exceptions (like community errors) however CRITICAL<\/code> for sudden ones. This distinction helps you prioritize when reviewing logs.<\/p>\n
\u00a0<\/p>\n
#\u00a0<\/span>Making a Reusable Logger Configuration<\/h2>\n\u00a0
Copying logger setup code throughout recordsdata is tedious and error-prone. Allow us to create a configuration perform you may import wherever in your mission.
\u00a0<\/p>\n
\n# logger_config.py\n\nimport logging\nimport os\nfrom datetime import datetime\n\n\ndef setup_logger(title, log_dir=\"logs\", stage=logging.INFO):\n    \"\"\"\n    Create a configured logger occasion\n\n    Args:\n        title: Logger title (often __name__ from calling module)\n        log_dir: Listing to retailer log recordsdata\n        stage: Minimal logging stage\n\n    Returns:\n        Configured logger occasion\n    \"\"\"\n    # Create logs listing if it would not exist\n\n    if not os.path.exists(log_dir):\n        os.makedirs(log_dir)\n    logger = logging.getLogger(title)\n\n    # Keep away from including handlers a number of occasions\n\n    if logger.handlers:\n        return logger\n    logger.setLevel(stage)\n\n    # Console handler - INFO and above\n\n    console_handler = logging.StreamHandler()\n    console_handler.setLevel(logging.INFO)\n    console_format = logging.Formatter(\"%(levelname)s - %(title)s - %(message)s\")\n    console_handler.setFormatter(console_format)\n\n    # File handler - all the things\n\n    log_filename = os.path.be part of(\n        log_dir, f\"{title.change('.', '_')}_{datetime.now().strftime('%Ypercentmpercentd')}.log\"\n    )\n    file_handler = logging.FileHandler(log_filename)\n    file_handler.setLevel(logging.DEBUG)\n    file_format = logging.Formatter(\n        \"%(asctime)s - %(title)s - %(levelname)s - %(funcName)s:%(lineno)d - %(message)s\"\n    )\n    file_handler.setFormatter(file_format)\n\n    logger.addHandler(console_handler)\n    logger.addHandler(file_handler)\n\n    return logger<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
Now that you’ve got arrange logger_config<\/code>, you need to use it in your Python script like so:
\u00a0<\/p>\n
\nfrom logger_config import setup_logger\n\nlogger = setup_logger(__name__)\n\ndef calculate_discount(value, discount_percent):\n    logger.debug(f'Calculating low cost: {value} * {discount_percent}%')\n    \n    if discount_percent < 0 or discount_percent > 100:\n        logger.warning(f'Invalid low cost share: {discount_percent}')\n        discount_percent = max(0, min(100, discount_percent))\n    \n    low cost = value * (discount_percent \/ 100)\n    final_price = value - low cost\n    \n    logger.information(f'Utilized {discount_percent}% low cost: ${value} -> ${final_price}')\n    return final_price\n\ncalculate_discount(100, 20)\ncalculate_discount(100, 150)<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
This setup perform handles a number of necessary issues. First, it creates the logs listing if wanted, stopping crashes from lacking directories.<\/p>\n
The perform checks if handlers exist already earlier than including new ones. With out this examine, calling setup_logger<\/code> a number of occasions would create duplicate log entries.<\/p>\n
We generate dated log filenames routinely. This prevents log recordsdata from rising infinitely and makes it straightforward to seek out logs from particular dates.<\/p>\n
The file handler contains extra element than the console handler, together with perform names and line numbers. That is invaluable when debugging however would muddle console output.<\/p>\n
Utilizing __name__<\/code> because the logger title creates a hierarchy that matches your module construction. This allows you to management logging for particular components of your software independently.<\/p>\n
\u00a0<\/p>\n
#\u00a0<\/span>Structuring Logs with Context<\/h2>\n\u00a0
Plain textual content logs are fantastic for easy purposes, however structured logs with context make debugging a lot simpler. Allow us to add contextual info to our logs.
\u00a0<\/p>\n
\nimport json\nfrom datetime import datetime, timezone\n\nclass ContextLogger:\n    \"\"\"Logger wrapper that provides contextual info to all log messages\"\"\"\n\n    def __init__(self, title, context=None):\n        self.logger = logging.getLogger(title)\n        self.context = context or {}\n\n        handler = logging.StreamHandler()\n        formatter = logging.Formatter('%(message)s')\n        handler.setFormatter(formatter)\n        # Examine if handler already exists to keep away from duplicate handlers\n        if not any(isinstance(h, logging.StreamHandler) and h.formatter._fmt == '%(message)s' for h in self.logger.handlers):\n            self.logger.addHandler(handler)\n        self.logger.setLevel(logging.DEBUG)\n\n    def _format_message(self, message, stage, extra_context=None):\n        \"\"\"Format message with context as JSON\"\"\"\n        log_data = {\n            'timestamp': datetime.now(timezone.utc).isoformat(),\n            'stage': stage,\n            'message': message,\n            'context': {**self.context, **(extra_context or {})}\n        }\n        return json.dumps(log_data)\n\n    def debug(self, message, **kwargs):\n        self.logger.debug(self._format_message(message, 'DEBUG', kwargs))\n\n    def information(self, message, **kwargs):\n        self.logger.information(self._format_message(message, 'INFO', kwargs))\n\n    def warning(self, message, **kwargs):\n        self.logger.warning(self._format_message(message, 'WARNING', kwargs))\n\n    def error(self, message, **kwargs):\n        self.logger.error(self._format_message(message, 'ERROR', kwargs))<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
You should use the ContextLogger<\/code> like so:
\u00a0<\/p>\n
\ndef process_order(order_id, user_id):\n    logger = ContextLogger(__name__, context={\n        'order_id': order_id,\n        'user_id': user_id\n    })\n\n    logger.information('Order processing began')\n\n    attempt:\n        gadgets = fetch_order_items(order_id)\n        logger.information('Gadgets fetched', item_count=len(gadgets))\n\n        whole = calculate_total(gadgets)\n        logger.information('Whole calculated', whole=whole)\n\n        if whole > 1000:\n            logger.warning('Excessive worth order', whole=whole, flagged=True)\n\n        return True\n    besides Exception as e:\n        logger.error('Order processing failed', error=str(e))\n        return False\n\ndef fetch_order_items(order_id):\n    return [{'id': 1, 'price': 50}, {'id': 2, 'price': 75}]\n\ndef calculate_total(gadgets):\n    return sum(merchandise['price'] for merchandise in gadgets)\n\nprocess_order('ORD-12345', 'USER-789')<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
This ContextLogger<\/code> wrapper does one thing helpful: it routinely contains context in each log message. The order_id<\/code> and user_id<\/code> get added to all logs with out repeating them in each logging name.<\/p>\n
The JSON<\/a><\/strong> format makes these logs straightforward to parse and search.<\/p>\n
The **kwargs<\/code> in every logging technique allows you to add additional context to particular log messages. This combines international context (order_id<\/code>, user_id<\/code>) with native context (item_count<\/code>, whole<\/code>) routinely.<\/p>\n
This sample is very helpful in internet purposes the place you need request IDs, consumer IDs, or session IDs in each log message from a request.<\/p>\n
\u00a0<\/p>\n
#\u00a0<\/span>Rotating Log Recordsdata to Stop Disk Area Points<\/h2>\n\u00a0
Log recordsdata develop rapidly in manufacturing. With out rotation, they’ll ultimately fill your disk. Right here is learn how to implement computerized log rotation.
\u00a0<\/p>\n\nfrom logging.handlers import RotatingFileHandler, TimedRotatingFileHandler\n\ndef setup_rotating_logger(title):\n    logger = logging.getLogger(title)\n    logger.setLevel(logging.DEBUG)\n\n    # Dimension-based rotation: rotate when file reaches 10MB\n    size_handler = RotatingFileHandler(\n        'app_size_rotation.log',\n        maxBytes=10 * 1024 * 1024,  # 10 MB\n        backupCount=5  # Preserve 5 outdated recordsdata\n    )\n    size_handler.setLevel(logging.DEBUG)\n\n    # Time-based rotation: rotate day by day at midnight\n    time_handler = TimedRotatingFileHandler(\n        'app_time_rotation.log',\n        when='midnight',\n        interval=1,\n        backupCount=7  # Preserve 7 days\n    )\n    time_handler.setLevel(logging.INFO)\n\n    formatter = logging.Formatter(\n        '%(asctime)s - %(title)s - %(levelname)s - %(message)s'\n    )\n    size_handler.setFormatter(formatter)\n    time_handler.setFormatter(formatter)\n\n    logger.addHandler(size_handler)\n    logger.addHandler(time_handler)\n\n    return logger\n\n\nlogger = setup_rotating_logger('rotating_app')<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
Allow us to now attempt to use rotation of log recordsdata:
\u00a0<\/p>\n\nfor i in vary(1000):\n    logger.information(f'Processing report {i}')\n    logger.debug(f'File {i} particulars: accomplished in {i * 0.1}ms')<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
RotatingFileHandler<\/code> manages logs based mostly on file dimension. When the log file reaches 10MB (laid out in bytes), it will get renamed to app_size_rotation.log.1<\/code>, and a brand new app_size_rotation.log<\/code> begins. The backupCount<\/code> of 5 means you’ll hold 5 outdated log recordsdata earlier than the oldest will get deleted.<\/p>\n
TimedRotatingFileHandler<\/code> rotates based mostly on time intervals. The ‘midnight’ parameter means it creates a brand new log file daily at midnight. You may additionally use ‘H’ for hourly, ‘D’ for day by day (at any time), or ‘W0’ for weekly on Monday.<\/p>\n
The interval<\/code> parameter works with the when<\/code> parameter. With when='H'<\/code> and interval=6<\/code>, logs would rotate each 6 hours.<\/p>\n
These handlers are important for manufacturing environments. With out them, your software may crash when the disk fills up with logs.<\/p>\n
\u00a0<\/p>\n#\u00a0<\/span>Logging in Completely different Environments<\/h2>\n\u00a0
Your logging wants differ between growth, staging, and manufacturing. Right here is learn how to configure logging that adapts to every surroundings.
\u00a0<\/p>\n\nimport logging\nimport os\n\ndef configure_environment_logger(app_name):\n    \"\"\"Configure logger based mostly on surroundings\"\"\"\n    surroundings = os.getenv('APP_ENV', 'growth')\n    \n    logger = logging.getLogger(app_name)\n    \n    # Clear present handlers\n    logger.handlers = []\n    \n    if surroundings == 'growth':\n        # Improvement: verbose console output\n        logger.setLevel(logging.DEBUG)\n        handler = logging.StreamHandler()\n        handler.setLevel(logging.DEBUG)\n        formatter = logging.Formatter(\n            '%(levelname)s - %(title)s - %(funcName)s:%(lineno)d - %(message)s'\n        )\n        handler.setFormatter(formatter)\n        logger.addHandler(handler)\n        \n    elif surroundings == 'staging':\n        # Staging: detailed file logs + necessary console messages\n        logger.setLevel(logging.DEBUG)\n        \n        file_handler = logging.FileHandler('staging.log')\n        file_handler.setLevel(logging.DEBUG)\n        file_formatter = logging.Formatter(\n            '%(asctime)s - %(title)s - %(levelname)s - %(funcName)s - %(message)s'\n        )\n        file_handler.setFormatter(file_formatter)\n        \n        console_handler = logging.StreamHandler()\n        console_handler.setLevel(logging.WARNING)\n        console_formatter = logging.Formatter('%(levelname)s: %(message)s')\n        console_handler.setFormatter(console_formatter)\n        \n        logger.addHandler(file_handler)\n        logger.addHandler(console_handler)\n        \n    elif surroundings == 'manufacturing':\n        # Manufacturing: structured logs, errors solely to console\n        logger.setLevel(logging.INFO)\n        \n        file_handler = logging.handlers.RotatingFileHandler(\n            'manufacturing.log',\n            maxBytes=50 * 1024 * 1024,  # 50 MB\n            backupCount=10\n        )\n        file_handler.setLevel(logging.INFO)\n        file_formatter = logging.Formatter(\n            '{\"timestamp\": \"%(asctime)s\", \"stage\": \"%(levelname)s\", '\n            '\"logger\": \"%(title)s\", \"message\": \"%(message)s\"}'\n        )\n        file_handler.setFormatter(file_formatter)\n        \n        console_handler = logging.StreamHandler()\n        console_handler.setLevel(logging.ERROR)\n        console_formatter = logging.Formatter('%(levelname)s: %(message)s')\n        console_handler.setFormatter(console_formatter)\n        \n        logger.addHandler(file_handler)\n        logger.addHandler(console_handler)\n    \n    return logger<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
This environment-based configuration handles every stage otherwise. Improvement exhibits all the things on the console with detailed info, together with perform names and line numbers. This makes debugging quick.<\/p>\n
Staging balances growth and manufacturing. It writes detailed logs to recordsdata for investigation however solely exhibits warnings and errors on the console to keep away from noise.<\/p>\n
Manufacturing focuses on efficiency and construction. It solely logs INFO<\/code> stage and above to recordsdata, makes use of JSON formatting for simple parsing, and implements log rotation to handle disk house. Console output is proscribed to errors solely.
\u00a0<\/p>\n\n# Set surroundings variable (usually carried out by deployment system)\nos.environ['APP_ENV'] = 'manufacturing'\n\nlogger = configure_environment_logger('my_application')\n\nlogger.debug('This debug message will not seem in manufacturing')\nlogger.information('Person logged in efficiently')\nlogger.error('Didn't course of fee')<\/code><\/pre>\n<\/div>\n\u00a0<\/p>\n
The surroundings is decided by the APP_ENV<\/code> surroundings variable. Your deployment system (Docker<\/a><\/strong>, Kubernetes<\/a><\/strong>, or different cloud platforms) units this variable routinely.<\/p>\n
Discover how we clear present handlers earlier than configuration. This prevents duplicate handlers if the perform is known as a number of occasions through the software lifecycle.<\/p>\n
\u00a0<\/p>\n
#\u00a0<\/span>Wrapping Up<\/h2>\n\u00a0
Good logging makes the distinction between rapidly diagnosing points and spending hours guessing what went improper. Begin with primary logging utilizing applicable severity ranges, add structured context to make logs searchable, and configure rotation to forestall disk house issues.<\/p>\n
The patterns proven right here work for purposes of any dimension. Begin easy with primary logging, then add structured logging once you want higher searchability, and implement environment-specific configuration once you deploy to manufacturing.<\/p>\n
Joyful logging!
\u00a0
\u00a0<\/p>\nBala Priya C<\/a><\/strong><\/a><\/b> is a developer and technical author from India. She likes working on the intersection of math, programming, information science, and content material creation. Her areas of curiosity and experience embrace DevOps, information science, and pure language processing. She enjoys studying, writing, coding, and occasional! Presently, she’s engaged on studying and sharing her data with the developer neighborhood by authoring tutorials, how-to guides, opinion items, and extra. Bala additionally creates participating useful resource overviews and coding tutorials.<\/p>\n<\/p><\/div>\n
<\/script>
\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Picture by Creator \u00a0 #\u00a0Introduction \u00a0Most Python builders deal with logging as an afterthought. They throw round print() statements throughout growth, perhaps swap to primary logging later, and assume that’s sufficient. However when points come up in manufacturing, they be taught they’re lacking the context wanted to diagnose issues effectively. Correct logging strategies provide you […]<\/p>\n","protected":false},"author":2,"featured_media":10747,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55],"tags":[419,305,78,907,1258],"class_list":["post-10745","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-machine-learning","tag-complete","tag-developers","tag-guide","tag-logging","tag-python"],"_links":{"self":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10745","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10745"}],"version-history":[{"count":1,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10745\/revisions"}],"predecessor-version":[{"id":10746,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10745\/revisions\/10746"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/media\/10747"}],"wp:attachment":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}