jinsanity07git / jinsanity07git.github.io

blog

Jinsanity 🔗 https://jinsanity07git.github.io

📄 8

💬 9

🌺 57493

⏰ 2024-05-04 05:38:22

Powered by ❤️ Gmeek

jinsanity07git.github.io's Issues

tricks in conda setup

Widnows

Conda environment using PowerShell

When attempting to activate a Conda environment using PowerShell in Visual Studio Code and noticing it doesn't work as expected, there are a few common issues and solutions to consider. Here’s what you might need to check and how to address each possibility:

1. Conda Initialization in PowerShell

If Conda commands don’t work directly in PowerShell, it could be because Conda hasn’t been properly initialized for use with PowerShell. Conda needs to be initialized in each shell type you want to use it with.

To initialize Conda for PowerShell, you can run the following command in a PowerShell window that has administrative privileges:

conda init powershell

This command sets up the proper hooks for Conda in PowerShell, allowing the conda command and environments to be managed directly from within PowerShell.

2. Conda Executable Not in Path

If initialization doesn’t seem to be the issue, ensure that the path to the Conda executable is correctly included in your system's PATH environment variable. Sometimes, especially if you installed Anaconda or Miniconda for just the current user, it might not have updated the system PATH automatically.

You can check your PATH variable in PowerShell like this:

$env:PATH

Look for a path that includes your Conda installation (typically something like C:\Users\sanity\miniconda3\ or C:\Users\sanity\Anaconda3\). If it’s missing:

• Add it manually via System Properties > Environment Variables, or

• Use PowerShell to add it temporarily:

  $env:PATH += ";C:\Users\sanity\miniconda3\"

  Replace C:\Users\sanity\miniconda3\ with the path to your actual Conda installation.

3. Restart Visual Studio Code

After making changes like initializing Conda for PowerShell or updating environment variables, it’s a good idea to restart Visual Studio Code. This ensures that VS Code and its integrated terminal sessions pick up all the changes.

4. Check Conda Environment Path

Make sure that the Conda environment tdm23_env_1 indeed exists. You can verify this by listing all available Conda environments:

conda env list

This will show all the environments and their paths, confirming whether tdm23_env_1 is correctly installed and recognized.

5. PowerShell Execution Policy

Sometimes, PowerShell’s execution policy can prevent scripts from running, which might include some of Conda’s initialization scripts. To see your current execution policy, use:

Get-ExecutionPolicy

If it’s set to Restricted, you might want to change it to RemoteSigned to allow locally created scripts to run:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

6. Using Conda in PowerShell Script Mode

In some cases, running conda activate directly in the script or command line interface mode in PowerShell might not work due to how Conda manages changes to the shell environment. Using:

conda activate

might require following it with an interactive script or opening a new PowerShell session.

By checking these areas, you should be able to resolve most issues with activating Conda environments in VS Code’s PowerShell terminal.

CMD cheatsheet

Actions

• open the current directory: start .

• use the help command followed by the name of the command: help dir

• Windows command line search for exact extension with dir ¹: dir /s /b *.txt | findstr /v .txt.

Lookup

Commands(windows)	Short description	Equivalent PowerShell	macOS
START	Start a program, command or batch file •	Invoke-Item Start-Process	open
DEL	Delete one or more files •		rm
DIR	Display a list of files and folders •	ls
HELP	Online Help	Get-Help	man

System Environment Variable

Set the Environment Variable:

Open Command Prompt as Administrator: Press Windows + X and select “Command Prompt (Admin)” or “Windows PowerShell (Admin)” to open a terminal with administrator privileges.

$Env:PATH

nicely printed

$Env:PATH -split ';' | ForEach-Object { $_ }

for %G in ("%PATH:;=" "%") do @echo %G

with filter

for %G in ("%PATH:;=" "%") do @echo %G | find "conda"

Set the Environment Variable: You can use the setx command to add the directory containing conda.bat to your system's Path environment variable. The command format is as follows:

setx PATH "%PATH%;C:\ProgramData\anaconda3\condabin"

Remove a PATH

• You can do this through the System Properties dialog (search for "Edit the system environment variables")

  • Press Windows Key + R to open the Run dialog.
    • OR open CMD windown
  • Type sysdm.cpl and press Enter or click OK.
  • This command opens the System Properties dialog directly.
    From there, you can navigate to the Advanced tab
    and click on Environment Variables to edit, add, or delete system and user environment variables.

  Another method to directly reach the Environment Variables window is:

  1. Press Windows Key + R to open the Run dialog.
  2. Type rundll32 sysdm.cpl,EditEnvironmentVariables and press Enter or click OK.

FAQ:

• conda cannot activate env in PowerShell²

References

Footnotes

1. DIR Display a list of files and folders • ↩

2. https://github.com/jinsanity07git/jinsanity07git.github.io/issues/9 ↩

quick CPU benchmark

• https://github.com/alexdedyura/cpu-benchmark

cpu-benchmark>python cpu-benchmark.py

git clone https://github.com/alexdedyura/cpu-benchmark
cd cpu-benchmark

Brand	CPU	Arch	OS	Benchmarking
TC17	Intel(R) Core(TM) i9-14900KF	AMD64	Windows	15.654
Dell Precision 3561	11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz	AMD64	Windows	23.852
WUYING: 8 vCPU / 16 GiB Linux	Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz	x86_64	Linux	33.572
	Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz	x86_64	Linux	38.685
	Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz	AMD64	Windows	39.258
google colab free tier	Intel(R) Xeon(R) CPU @ 2.20GHz	x86_64	Linux	43.078
	Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz	AMD64	Windows	62.969
Oracle 1G-1G-0.5Gbps	AMD EPYC 7551 32-Core Processor	x86_64	Linux	98.732

mainstream CPU architecture

mainstream CPU architecture

Currently, the two dominant architectures are:

1. x86-64 (also known as AMD64)

• Developers: Originally developed by AMD, this architecture is now used by both AMD and Intel.
• Characteristics: It's a 64-bit extension of the original 32-bit x86 architecture. It supports complex instruction set computing (CISC) with a focus on high performance and compatibility with a wide range of software.
• Usage: This architecture is primarily used in personal computers, laptops, and servers. It dominates the desktop and server markets due to its high performance and broad software ecosystem.

2. ARM (including aarch64 or ARM64)

• Developer: ARM Holdings licenses the architecture to various companies, which then design their own processors that comply with the ARM specifications.
• Characteristics: ARM architectures are based on reduced instruction set computing (RISC), focusing on efficiency and low power consumption.
• Usage: ARM is extensively used in mobile devices¹ such as smartphones and tablets due to its power efficiency. It's also increasingly found in other areas such as servers² (due to energy efficiency), embedded systems, IoT devices, and even desktops and laptops, with Apple's transition to its own ARM-based M1 and subsequent chips in the Mac lineup.

The terms AMD64, x86_64, and aarch64 refer to different CPU architectures, each with distinct characteristics and intended uses. Here's a breakdown of each:

AMD64 and x86_64

1. Origin:

   • AMD64 (also known as x86-64) is an architecture developed by AMD. It was originally named "AMD64" because AMD was the first to introduce a 64-bit extension to the x86 architecture.
   • x86_64 is another name for the same architecture, used more generically to avoid emphasizing AMD over Intel, which also uses the architecture.

2. Design:

   • This architecture is a 64-bit extension of the original 32-bit x86 architecture (also known as IA-32) that was developed by Intel. It supports 64-bit computing, which allows for more direct access to a greater amount of memory and enhanced performance for applications capable of utilizing 64-bit code.

3. Compatibility:

   • AMD64/x86_64 processors are backward compatible with 32-bit x86 software. This compatibility has been key to the architecture's widespread adoption, as it allows users to continue using older applications.

aarch64

1. Origin:

   • aarch64 is the 64-bit extension of the ARM architecture, often referred to as ARM64. ARM's architecture is fundamentally different from x86 and is developed by ARM Holdings.

2. Design:

   • ARM architectures are designed for efficiency and low power consumption, making them ideal for mobile and embedded systems. The aarch64 architecture supports 64-bit processing, which enhances performance for high-demand applications and supports larger amounts of memory, beneficial in modern mobile devices and servers.

3. Compatibility:

   • ARM processors are not natively compatible with x86/x86_64 software, requiring either recompilation of software or emulation to run software designed for x86/x86_64.

• Instruction Set: AMD64 and x86_64 use a complex instruction set computing (CISC) design, which includes a wide range of complex instructions. aarch64 uses a reduced instruction set computing (RISC) design, which uses simpler, less complex instructions intended to offer greater efficiency and lower power consumption.
• Performance vs. Power Efficiency: AMD64/x86_64 architectures typically focus more on performance and are used in high-power computing environments. In contrast, aarch64 architectures prioritize power efficiency, which is crucial for battery-powered devices.
• Market Adoption: x86_64 is dominant in the PC and server market, whereas aarch64 has a stronghold in the mobile and emerging server and desktop markets, especially with the growth of IoT and edge computing.

arm64e

The term arm64e refers to an enhanced version of the arm64 architecture, specifically implemented by Apple to support new security and performance features on its platforms. Here’s a detailed look at what arm64e entails:

1. Origin

   • Developer: arm64e was developed by Apple as an evolution of the standard ARM64 (also known as ARMv8-A) architecture.

   • Purpose: The primary motivation behind arm64e was to increase the security of software running on Apple devices, especially to protect against exploits that manipulate code execution flow.

   • Introduction: Apple introduced arm64e with the release of the A12 Bionic chipset, which first appeared in the iPhone XS, XS Max, and XR in 2018.

2. Design

   • Pointer Authentication: The standout feature of arm64e is Pointer Authentication, which adds a cryptographic signature to pointers, verifying their integrity before use. This mechanism significantly reduces the risk of common security threats such as return-oriented programming (ROP) and jump-oriented programming (JOP) attacks.

   • Architecture Improvements: While maintaining a strong backward compatibility with ARMv8-A, arm64e incorporates changes at the instruction set level to support the generation and verification of pointer signatures.

   • Security Focus: The enhancements in arm64e are geared towards hardening Apple devices against exploits by making unauthorized code execution more challenging and thereby bolstering overall system security.

3. Compatibility

   • Backward Compatibility: arm64e is designed to be backward compatible with the arm64 architecture. Applications compiled for arm64 can run on systems supporting arm64e without modifications, although they won't benefit from the new security features unless recompiled with arm64e support.

   • Development Environment: Developers aiming to utilize arm64e features need to use Apple's Xcode and compile their applications specifically for arm64e. This ensures that the new security enhancements are properly implemented in their applications.

   • Device Support: arm64e is supported on Apple devices with the A12 chipset and later. This includes not only iPhones but also iPads and potentially other future Apple devices as the company continues to deploy this architecture in its new hardware.

Footnotes

1. Apple silicon: Comparison of A series processors ↩

2. Application ARM-based chips ↩

SWOT analysis : job scheduler packages

SWOT

SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for the top four job scheduler¹ packages on PyPI—Apache Airflow, APScheduler, Prefect, and Schedule—I'll highlight their main features and use them to assess each tool across these categories.

1. Apache Airflow

Strengths:

• Complex workflows: Airflow excels in managing complex, dependent workflows and provides extensive monitoring capabilities.
• Community and Ecosystem: As a project under the Apache Software Foundation, Airflow benefits from a robust community, wide adoption, and a rich ecosystem of plugins and integrations.

Weaknesses:

• Learning curve: Airflow can be complex to set up and learn, particularly for users unfamiliar with its programming model.
• Resource-intensive: It requires more significant infrastructure and resources, which might be overkill for simpler needs.

Opportunities:

• Integration with big data tools: Being highly integrated with cloud services and other big data technologies offers opportunities for growth in these sectors.
• Enterprise adoption: Continued focus on enterprise features could increase its adoption among large organizations.

Threats:

• Emerging competitors: Tools like Prefect aim to solve similar problems with a more modern approach and could capture parts of Airflow's market.

2. APScheduler

Strengths:

• Simplicity and flexibility: APScheduler is straightforward to integrate into Python applications and supports various types of jobs, making it versatile.
• Lightweight: Unlike Airflow, it's more lightweight and less resource-intensive, suitable for simpler applications.

Weaknesses:

• Limited by Python environment: As it runs within a Python environment, its operation is limited by Python's performance and concurrency limitations.

Opportunities:

• Extension into more complex scheduling: Could potentially add features to manage more complex workflows to broaden its applicability.

Threats:

• Overlap with more comprehensive tools: Might be overshadowed by tools like Airflow or Prefect when users need more advanced features and scaling.

3. Prefect

Strengths:

• Modern and developer-friendly: Prefect is designed with a modern interface and emphasizes a smoother developer experience.
• Hybrid execution model: Offers a hybrid model where workflows can run in the cloud or on-premise, providing flexibility.

Weaknesses:

• Newer on the scene: As a relatively newer player, it may lack the extensive community and ecosystem that tools like Airflow enjoy.

Opportunities:

• Growth in cloud orchestration: Could capitalize on trends towards cloud-based data pipelines and orchestration.
• Community building: Focusing on community engagement and development can enhance its adoption and support.

Threats:

• Competitive market: Faces stiff competition from established tools like Airflow and emerging open-source projects.

4. Schedule

Strengths:

• Ease of use: Very simple to use for basic scheduling tasks, making it ideal for beginners or small projects.
• Minimalistic approach: It keeps scheduling straightforward, with a minimalistic interface and setup.

Weaknesses:

• Limited features: Not suitable for complex job scheduling needs or dependencies between tasks.
• Scalability: It does not inherently support large-scale job scheduling or distributed tasks.

Opportunities:

• Potential for integration: Could be integrated into other tools as a simple scheduler component.

Threats:

• Simplicity as a limitation: Its simplicity and lack of advanced features might limit its use cases, pushing users to more comprehensive tools as their needs grow.

This SWOT analysis provides an overview of where each scheduler stands in terms of its strengths and weaknesses and how it can navigate its opportunities and threats in the competitive landscape of job scheduling tools.

References

Footnotes

1. [piptrends: Job Scheduler](https://piptrends.com/python-toolbox/job-scheduler) ↩

search tips in Everything

Everything

Q:

• To search for all Markdown files (typically having the .md extension) recursively in a directory using "Everything," a desktop search utility for Windows that can instantly locate files and folders by name,

A:

1. Specify the Directory: To search within a specific directory, you'll need to use the path of the directory as part of your search query. For your example directory (J:\My Drive), you would start your query with the path, ensuring to use double quotes if your path contains spaces.

2. Use Wildcards for Recursive Search: To find all Markdown files recursively, use a wildcard pattern that matches .md files.

3. Combine Path and Pattern: Your search query in Everything should look like this:

"J:\My Drive" *.md

---

Q:

• search for a path that contains a specific keyword, such as "github"

A:

1. Modifiers: Functions and regular search terms can be prefixed with a modifier.

2. childcount: | Search for folders that contain the specified number of subfolders and files. -- | -- folder:folders:nofolderonly: | Match folders only.

count:5 path: github\tdm23 

Q:

• To search for all markdown files under a partial path (e.g., "oracle", "docs\productivity" )

A:

path:*orac* *.md
or
path: *docs\prod* .md

This query does the following:

path:orac: Searches for paths that contain the string "orac" anywhere in the path. The asterisks (*) are wildcards that match any sequence of characters, allowing "orac" to appear anywhere within the directory name. *.md: Filters the results to only show files with the .md extension, which are Markdown files.

References

[1]  everything search Syntax

## Everything

Q:

• To search for all Markdown files (typically having the .md extension) recursively in a directory using "Everything," a desktop search utility for Windows that can instantly locate files and folders by name,

A:

1. Specify the Directory: To search within a specific directory, you'll need to use the path of the directory as part of your search query. For your example directory (J:\My Drive), you would start your query with the path, ensuring to use double quotes if your path contains spaces.
2. Use Wildcards for Recursive Search: To find all Markdown files recursively, use a wildcard pattern that matches .md files.
3. Combine Path and Pattern: Your search query in Everything should look like this:

"J:\My Drive" *.md

---

Q:

• search for a path that contains a specific keyword, such as "github"

A:

1. Modifiers: Functions and regular search terms can be prefixed with a modifier.

2. childcount:<count>	Search for folders that contain the specified number of subfolders and files.
   folder:folders:nofolderonly:	Match folders only.

count:5 path: github\tdm23 

Q:

• To search for all markdown files under a partial path (e.g., "oracle", "docs\productivity" )

A:

path:*orac* *.md
or
path: *docs\prod* .md

This query does the following:

path:orac: Searches for paths that contain the string "orac" anywhere in the path. The asterisks (*) are wildcards that match any sequence of characters, allowing "orac" to appear anywhere within the directory name.
*.md: Filters the results to only show files with the .md extension, which are Markdown files.

References

About Me

❤️感谢第小伙伴的次访问关于页面。

[Webserver backend] pros & cons : WSGI vs ASGI

pros & cons : WSGI vs ASGI

WSGI (Web Server Gateway Interface) and ASGI (Asynchronous Server Gateway Interface) are both specifications in Python for connecting web servers with web applications. WSGI has been the standard for Python web application development for many years, while ASGI is relatively newer and designed to extend WSGI to support asynchronous applications.

WSGI (Web Server Gateway Interface)

Pros:

• Stability and Maturity: WSGI has been around for much longer, making it a mature and stable choice for deploying Python web applications.
• Wide Support: Most Python web frameworks (e.g., Flask, Django up to a certain version) and servers (e.g., Gunicorn, uWSGI) support WSGI, ensuring compatibility and ease of deployment.
• Synchronous Processing: Ideal for traditional, synchronous web applications, where each request is processed sequentially.

Cons:

• Limited Concurrency: WSGI applications run in a synchronous manner, which can limit concurrency and make it harder to handle long-lived connections like WebSockets or HTTP/2 efficiently.
• No Native Asynchronous Support: WSGI does not natively support asynchronous request handling, making it less suitable for IO-bound and high-concurrency applications.

ASGI (Asynchronous Server Gateway Interface)

Pros:

• Asynchronous Support: ASGI natively supports asynchronous request handling, making it ideal for IO-bound and high-concurrency applications, as well as for handling long-lived connections such as WebSockets, HTTP/2, and long polling.
• Increased Performance: For applications that benefit from asynchronous IO operations, ASGI can offer improved performance and efficiency.
• Flexibility: ASGI supports both asynchronous and synchronous applications, providing more flexibility in how applications are developed and deployed.

Cons:

• Complexity: Writing asynchronous code can be more complex than synchronous code, potentially leading to harder-to-maintain codebases.
• Younger Ecosystem: While growing quickly, the ASGI ecosystem is newer than WSGI's. This means there might be fewer resources, middleware, and integrations available for ASGI applications.
• Server Support: The choice of servers for ASGI applications (e.g., Daphne, Uvicorn) is more limited compared to WSGI, although this is rapidly changing as asynchronous programming gains popularity.

Conclusion

The choice between WSGI and ASGI depends on the specific needs of your application:

• Use WSGI if you are building a traditional synchronous web application that doesn't require handling many simultaneous connections or real-time features like WebSockets.
• Use ASGI if you are building an application that requires high concurrency, asynchronous processing, or real-time features.

It's also worth noting that some frameworks, such as Django (since version 3.0), have started to offer support for both WSGI and ASGI, allowing developers to choose the most appropriate option based on their application's requirements.

FASTapi / Django / Flask

is FASTapi / Django / Flask ASGI or WSGI

FastAPI, Django, and Flask are popular web frameworks in the Python ecosystem, each with its design philosophies, use cases, and support for WSGI or ASGI.

FastAPI

• Type: ASGI
• Description: FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.7+ based on standard Python type hints. It is designed to be asynchronous from the ground up and is built on top of Starlette for the web parts and Pydantic for the data parts. It provides automatic OpenAPI and JSON Schema documentation and is designed for building asynchronous applications.
• Pros: Great performance, automatic API documentation, built-in data validation, and serialization. It is ideal for asynchronous applications and long-lived connections like WebSockets.
• Cons: Relatively newer and might have a smaller ecosystem compared to Flask and Django. Asynchronous programming can introduce complexity for those unfamiliar with it.

Django

• Type: Both WSGI and ASGI (as of Django 3.0)
• Description: Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel.
• Pros: Includes an ORM, admin panel, forms, authentication, and more out-of-the-box. Very mature and has a large ecosystem.
• Cons: Can be perceived as bulky for small projects due to its "batteries-included" approach. Asynchronous support is available but was added later in its lifecycle, so some parts of the ecosystem may not fully support asynchronous operation yet.

Flask

• Type: WSGI
• Description: Flask is a lightweight WSGI web application framework. It is designed to make getting started quick and easy, with the ability to scale up to complex applications. It began as a simple wrapper around Werkzeug and Jinja and has become one of the most popular Python web application frameworks.
• Pros: Lightweight and modular, making it very flexible and easy to adapt for small projects as well as complex applications. Large ecosystem of extensions.
• Cons: Doesn't include as many features out-of-the-box as Django (e.g., ORM, form handling, authentication), which means you often need to add third-party packages or build these components yourself. Synchronous by nature, which might not be ideal for highly concurrent, IO-bound applications.

In summary:

• FastAPI is designed as an ASGI framework, focusing on asynchronous programming, speed, and quick API development with automatic documentation.
• Django supports both WSGI (synchronous) and ASGI (asynchronous) as of version 3.0, allowing developers to choose based on their application's needs. It's a full-stack framework that comes with many built-in features.
• Flask is a WSGI framework that is lightweight and flexible, making it suitable for both small and large applications with a synchronous model.

Tornado

how about the Tornado Web Server that Jupyter Notebook uses as backend, what is its relation to WSGI/ASGI

Tornado is a Python web framework and asynchronous networking library that differs significantly from traditional WSGI/ASGI frameworks. It was designed to handle asynchronous I/O, which makes it well-suited for long-lived network connections and high-concurrency applications, such as long polling, WebSockets, and other applications where a lot of connections need to be open simultaneously. Tornado is particularly known for its high performance and scalability.

Relationship to WSGI/ASGI:

• WSGI Compatibility: Tornado can serve WSGI applications, making it compatible with WSGI-based frameworks like Flask or Django in a limited fashion. This is facilitated through Tornado’s WSGIAdapter. However, when run in this mode, Tornado operates synchronously, which means it loses the benefits of its asynchronous capabilities. It's not the most common use case for Tornado but provides a way to integrate or migrate existing WSGI applications.
• ASGI Compatibility: Tornado does not natively implement the ASGI specification. Its approach to asynchronous programming predates ASGI and is built into the framework at a fundamental level, utilizing Python's asyncio library where appropriate. For projects that are specifically designed around ASGI's interface, frameworks like Starlette, FastAPI, or channels (for Django) are more directly compatible.

Use in Jupyter Notebook:

Jupyter Notebook uses Tornado as its web server primarily because of its ability to handle multiple simultaneous connections efficiently, which is crucial for a web application like Jupyter that maintains long-lived connections to support interactive computing sessions. Tornado's support for WebSockets is also beneficial for the real-time, bidirectional communication between the client (browser) and the server that Jupyter requires.

Conclusion:

Tornado stands somewhat apart from the WSGI/ASGI dichotomy, offering its own approach to asynchronous web serving and application development. It's especially suitable for applications requiring a lot of open connections and real-time data exchange, making it an excellent choice for Jupyter Notebook's backend. While it can work with WSGI applications, doing so is generally not leveraging Tornado's strengths in asynchronous operation.

Gradio / Streamlit

what kind of backend does gradio/streamlit use

Gradio and Streamlit are both Python libraries designed to make it easier for data scientists and developers to create interactive web applications for machine learning models, data visualization, and analysis with minimal web development experience required. Each takes a different approach to how they serve content and manage the backend.

Gradio

Gradio typically uses Flask as its web server backend. Flask is a lightweight WSGI web application framework that provides the necessary tools to build web applications quickly and with minimal boilerplate code. Gradio leverages Flask to create a simple web server that can host the interfaces for machine learning models or any Python function. Gradio's use of Flask makes it easy to integrate with existing Python data science and machine learning ecosystems.

Streamlit

Streamlit, on the other hand, has its own custom server mechanism built on top of Tornado, which is an asynchronous networking library and web server framework. Tornado allows Streamlit to handle web sockets and manage real-time updates to the user interface, which is essential for creating interactive applications that respond to user input without requiring a page reload. Streamlit's server architecture is designed to streamline the process of deploying data applications by abstracting away much of the complexity involved in web app development.

Summary

• Gradio simplifies the creation of machine learning model demos and Python function interfaces, using Flask as its backend. This choice benefits from Flask's simplicity and ease of integration with Python's wider ecosystem.
• Streamlit focuses on creating interactive data applications with a custom server built on Tornado, emphasizing real-time interactivity and state management without the need for callbacks or frontend development.

Both Gradio and Streamlit abstract much of the web development process, allowing developers and data scientists to focus on Python code rather than the intricacies of web frameworks, HTTP, or frontend technologies. Their different backend choices reflect their distinct approaches to simplifying web application development for data-driven projects.

Backslash vs Forward slash

| \ or / ?

Backslash is the one next to the backspace on keyboard

The backslash key () is typically located just above the Enter key or just to the left of the Enter key, which is near the Backspace key on a standard QWERTY keyboard.