یه خوبی دیگه‌‌ای که بلک داره اینه که اگه می‌خواید پارارمتر‌های تابع رو type annotate کنید، با این روش این کار به زیبایی صورت میگیره، و هر خط نام پارامتر و تایپی که قراره بگیره و نشون میده، اما در روش اول زیادی شلوغ میشه 😬

Answers: 1 • 2 • 3

#M4hdi
〰️〰️〰️〰️〰️
©️@raspberry_python

https://techcrunch.com/2022/04/22/edgedb-wants-to-modernize-databases-for-cutting-edge-apps/

با نسل بعدی دیتا‌بیس‌ها آشنا بشید 😎👌

#M4hdi
〰〰〰〰〰
©@raspberry_python

Organize Python code like a PRO 🐍📦

پروژه‌تون رو مثل یک حرفه‌ای ساختاربندی و مرتب کنید.

از اونجایی که پایتون یک زبان خیلی منعطف هست (مثل جاوا نیست که وقتی یه فایل جاوا درست میکنید باید یه کلاسِ پابلیک به همون اسم داخلش باشه) شما این اجازه رو دارید که کل کد یک پروژه رو توی یک فایل، و یا هر تابع رو توی یک فایل جدا بنویسید 😑🥴

با این مقاله یاد بگیرید که چگونه پروژه‌تون رو درست ساختار بندی کنید.

https://guicommits.com/organize-python-code-like-a-pro/

#M4hdi
〰〰〰〰〰〰
©@raspberry_python

✔️ سوال.

بهترین راه برای فهمیدن اینکه یه آبجکت hashable هست، چیه؟!

جوابتون رو کامنت کنید.

پاسخش رو فردا میگذارم.

#M4hdi
〰️〰️〰️〰️〰️〰️
©@raspberry_python

خب شاید پیش خودتون بگید، آبجکتی که داندر hash داشته باشه حتما hashable عه دیگه، این داندر رو داره و جوابتون این باشه:

o = obj
if hasattr(o, '__hash__'):
print(f"{o} is hashable")

اما خیر 😁

اول یه چیز پایه‌ای بگیم.
کلاس آبجکت object پایه‌ای ترین base class در پایتونه و اینکه میگن همه‌چیز در پایتون آبجکته، یکی از دلیلاش اینه. هر چیزی که فکرش رو بکنید از object ارث می‌بره.

این کلاس کلی داندر متد داره و از قضا دو تا داندر که در این مطلب برای ما مهم هستن رو هم با هم داره

داندر eq -> برای چک کردن تساوی دو تا آبجکت

obj1 == obj2

داندر hash -> برای برگرداندن مقدار hash آبجکت که از تابع hash میگیریم

hash(obj)

وقتی یک کلاسی شما می‌نویسید:

class Spam:
    pass

این کلاس به طور خودکار از کلاس آبجکت ارث می‌بره که تبعا داندر متد‌ها براش resolve میشن، که یعنی، ارث‌‌شون میبره، یا اینکه میگرده توی کلاس object پیدا شون میکنه.

نکته‌ی داندر eq
رفتار پیش‌فرض داندر eq به این صورته که میان آیدی‌های دو آبجکت رو باهم مقایسه میکنه. یعنی اگه اون رو override نکرده باشید و بخواید آبجکت‌هاتون رو با هم مقایسه کنید، وقتی جواب True میگیرید که دو تا آبجکت در واقع یک آبجکت باشن. دقیقا همون کاری که is انجام میده.

s1 = s2 = Spam()
s1 == s2  -> True

اما شاید چنین رفتاری رو نخواید و جور دیگه‌ای بخوایید که آبجکت‌های شما تساوی‌شون چک بشه
خب میاید داندر eq رو جوری که میخواید اورراید میکنید

اما 😁

وقتی این کار رو کردید، اتفاقی که میوفته اینه که مقدار داندر hash شما None میشه و آبجکت شما دیگه hashable نیست
این یعنی دیگه نمی‌تونید توی دیکشنری و ست بذاریدش و ....

این در حالیه که آبجکت شما همچنان داندر hash داره ولی hashable نیست.

این توضیحات میشن دلیل اینکه چرا اون شرط باگ داره.

اما راه‌حل چیه؟
خب شاید بیاید بگید بجای اینکه چک کنیم هست، چک میکنیم که None نباشه

if o.__hash__ is not None:
    ...

این تا حدی مشکل رو حل میکنه اما از اونجایی که پایتون یه زبان به شدت داینامیک عه:

class Spam:
    def __eq__(self): ...

Spam.hash = "Gotcha, Im neither hashable nor None =)"

پس بهترین راه‌حل چیه؟
It is easier to ask forgiveness than permission

try:
    hash(o)
except TypeError:
    print("unhashable")
else:
    print("hashable")

اما یه سوال بی جواب میمونه!
بالاتر گفتیم اگه داندر eq رو اورراید کنیم آبجکت ما دیگه hashable نیست و توی ست و دیکشنری نمی‌تونیم استفاده کنیم. من میخوام اون ور اورراید کنم و بازم hashable باشه 😒😒

خب جوابش ساده‌ست

شما باید داندر hash رو هم اورراید کنید و یه مقدار int برگردونید

نکته‌ای که هست و باید بهش توجه داشته باشید اینه که باید بتونید یه عددی تولید کنید که تکراری شدنش سخت باشه (اگه تکراری بشه اشکالی نداره) و به ویژگی‌های آبجکت شما وابسته هم باشه (حتما قرار نیست به ویژگی‌هاش وابسته باشه، اما اگه باشه، اون نکته‌ی قبلی راحت‌تر بدست میاد)

برای مثال

class Spam:
    def __init__(self, name):
        self.name = name
    
    def __eq__(self):
        ...
    
    def __hash__(self):
        return hash(self.name)

تبعا شما اسامی مختلفی قراره به هر آبجکت که از Spam درست میکنید بدید، و این باعث میشه که hash هر بار فرق کنه

اما اگه اسم یکسان هم بدید، مشکلی نیست یه قانونی هست توی بحث hash که میگه:
اگر دو آبجکت دقیقا یکسان باشن، (یعنی دو تا رفرنس از یک آبجکت رو داشته باشیم) باید hash یکسانی داشته باشن
اما اگر ما دو تا hash یکسان از دو تا آبجکت داشتیم، الزاما اون دو آبجکت یکی نیستن.

به این حالت که هش یکسانه ولی آبجکتا یکی نیستن، میگن hash collision. که پایتون خودش این رو هندل میکنه
و بحثش در این مقال "دیگر 😮‍💨" نمیگنجد.

موفق باشید 😁✌️

#M4hdi
〰️〰️〰️〰️〰️〰️〰️
©@raspberry_python

✔️ فرض کنیم چنین سوالی داریم

"میخوایم ببینیم، آیا حرف nام letters در کلمه nام words وجود داره یا نه"

دو راه داریم که مشخص شدن.

بدون ران کردن و تست سرعت کد، این خیلی مهمه، بگید کدوم کند‌تره؟

و برای جواب‌تون حتما دلیل بتراشید

[خط سوم (choice) درست هست]
#M4hdi
〰️〰️〰️〰️〰️〰️〰️
©@raspberry_python

✔️ جواب

تا حالا تریس‌بک دیدید؟ خب معلومه! اما این چه ربطی به جواب داره؟

اول بیاید یه تریس‌بک ببینیم:
Traceback (most recent call last):
File "/.../fields.py", line 241, in set
inst.data[self.name] = self.validator.validate(value)
File "/.../fields.py", line 662, in validate
raise ValidationError(messages=error_messages)
typesystem.base.ValidationError: {0: 'Must be a string.', 1: 'Must be a string.'}

هر یه دونه خطی که نوشته فلان فایل و کجا و یه خطی ازش آورده، چیزیه به اسم frame object.
هر تابعی که صدا زده میشه، توی call stack عه پایتون، یه فریم آبجکت درست میشه که استک مورد نیاز و دیکشنری ()locals عه اون و مقداری که ازش باید return بشه یا exception عی که باید ازش propagate بشه رو مدیریت میکنه، و تابع اون تو ران میشه.

یعنی return کار میکنه چون فریم آبجکت وجود داره و اون این کار رو برامون انجام میده.

وقتی پایتون یه مقداری رو به فریم دیگه ریترن میکنه، اون فریم باید از بین بره و gc و پایتون اینجا درگیرن، بساز خراب کن بساز خراب کن (که این توی توابع recursive اندکی فرق میکنه، هی فریم ساخته میشه روی هم توی استک و بعدش دونه دونه خراب میشن)

از اون طرف صدا زده شدن تابع و همین ساخته شدن فریم و اینا تبعا یه overhead عی داره و اصطلاحا function call، اندکی توی پایتون expensive هست (که البته توی پایتون ۳.۱۱ خیلی بهتر شده و تا ۳.۱۵ خیلی بهتر میشه)

روش اولی که توی صورت سوال هست، اگه گفتید چند تا تابع داره؟
1. list
2. map
+ 500 lambda

یعنی ۵۰۲ تا فانکشن کال رو فقط ما داریم می‌بینیم.

این همهههههههه فانکشن کال اتفاق میوفته

اما روش دوم

ما دو تا تابع می‌بینیم:
1. listcomp
2. zip
(اگه نمی‌دونستید باید بگم که لیست کامپری‌هنشن ها به یه تابع تبدیل میشن.)

توابعی هم که ما نمی‌بینیم، در جفت مثال‌ها داندر contains (اونجایی که l in w داریم) صدا زده میشه که، این تابع C هست:

https://github.com/python/cpython/blob/75a6441718dcbc65d993c9544e67e25bef120e82/Objects/unicodeobject.c#L10627

با یه حساب سر انگشتی:
اولی یه لیست و یه مپ و ۵۰۰ تا لامبدا و ۵۰۰ تا متد contains
و دومی یه لیست کامپری‌هنشن و یه زیپ و ۵۰۰ تا متد contains

و اگه موارد مشترک رو کم کنیم
اولی -> 502
دومی -> 2 تا

و این میشه که روش اول کندتر میشه 😁

#M4hdi
〰〰〰〰〰〰〰〰〰
©@raspberry_python

✔️ What is if __name__ == "__main__":?
اول از همه، همه چیز توی پایتون یه آبجکته، زیاد شنیدیم و کلیشه شده ولی جداً یه سری آبجکتا رو نمی‌شناسیم.

یکی از اون تایپ‌ها ModuleType هست.

هر فایلی که سورس کد پایتون توش باشه، رو بهش میگیم ماژول؛ چرا؟ چون پایتون اون رو میگیره، یه آبجکت براش توی مموری درست میکنه.

چرا؟ خب یکی از دلایل منطقی‌ش اینه که هر ماژول یه namespace باید داشته باشه (هر چند راحت‌تره بگیم هر ماژول یه namespace عه)
خب namespace‌ها توی پایتون چی هستن؟ خیلی ساده‌ست :) همه‌شون دیکشنری‌اند (البته داندر slots قضیه‌اش فرق میکنه)

هر ماژول هم یکی از پایه‌ای‌ ترین نیاز هاش اینه که namespace داشته باشه تا کلاس‌ها و توابع و متغیر‌ها رو در دسترس ما قرار بده.

پس تا اینجا هر ماژول تبدیل به یه آبجکت میشه و یه namespace محسوب میشه. (اگه نمیشد که منتغی میشد 😂)

import types

print(type(types))  -> <class 'module'>
print(isinstance(types, types.ModuleType))  -> True

میدونی سیستم ایمپورت کردن توی پایتون چجوری کار میکنه؟

اول دنبال فایل میگرده
بعدش لودش میکنه (آبجکتش رو درست میکنه)
بعد کاملا رانش میکنه تا چیزای داخلش رو توی مموری بسازه (همون دیکشنری یا namespaceاش رو populate کنه.)

حالا چون رانش میکنه، ممکنه مثلا پرینتی، صدا زدن تابعی، یک عمل زمان‌بری چیزی اون داخل وجود داشته باشه که موقع ایمپورت ما نمیخوایم چنین اتفاقی بیوفته. چون واقعا ران میشه.

باید چه کار کنیم؟

هر ModuleType یه اسمی داره، فایلی اصلی که پایتون اول رو ران میکنه اسمش میشه main، اسم هم توی خود namespace عه ماژول ذخیره میشه توی name

اما دیگر ماژول‌هایی که ایمپورت میشن اسمشون میشه اسم همون فایل‌شون

hola.py
hello.py

# inside hola.py
print(name)

# inside hello.py
import hola

# run hello.py
output:  hola

پایتون یه شرط معروفی داره که صورت سوال ماست:
الان میدونیم معنیش چیه

if __name__ == "__main__":

داره میگه اگه ماژولی که ران میکنی اسمش main هست کدای زیرش رو اجرا کن

که الان میدونیم که وقتی ماژول ایمپورت میشه اسمش اسم فایلشه و داندر مین نیست و این شرط غلط میشه و کدای زیرش اجرا نمیشن

حالا میگیم اجرا نمیشن، اما کامپایل که میشن، پس اگه توی بلوک کد این if تو SyntaxError داشته باشی ارورش رو موقع ایمپورت کردنش می‌بینی.

ایمپورت کردن چیزی نیست که «ما» بخوایم روی بهینه‌کردنش وقت بذاریم چون جدا نمیتونیم، اما اگه خود پایتون بهینه‌اش کنه تاثیری خوبی رو می‌بینیم. البته نه توی چیزای کوچیک، یه اپلیکیشنی که خیلی ایمپورت زیادی داره توش مشخص میشه و حتی بهتر اگه یه اپلیکیشنی به بزرگی اینستاگرام اون جاست که این بهینه‌سازی میتونه ساعت‌‌ها کار رو سریع‌تر کنه، چجوری؟
یه سیستمی دارن توی پایتون ۳.۱۲ روش کار میکنن به اسم Lazy Imports، چطوری کار میکنه؟ وقتی ایمپورت‌‌ها تنبل بشن، دیگه همون اول اول همه‌شون evaluate نمیشن، کداشون execute نمیشه و ... و وقتی که نیاز شد، اون ماژول کداش execute میشه. خب چقدر تاثیر میذاره؟‌
همه میدونیم که اینستاگرام از پایتون و جنگو استفاده میکنه، شرکت متا (فیس‌بوک) یه پیاده‌سازی پایتون داره به اسم Cinder این برای اینستاگرام بهینه شده مثلا garbage collector اش خاموشه و جدیدا مقاله‌ای منتشر کردن که گفتن ما ایمپورت‌هارو کاملا lazy کردیم.

قبلنا که تنبل نبودن اگه توسعه‌دهنده‌ای حتی یه فایل رو عوض میکرد، اون سروری که اون فایل رو ران میکرد باید reload ‌میشد و طبق گفته خودشون تا چند دقیقه طول میکشیده این قضیه. اما الان که ایمپورت‌ها تنبل شدن بسیار بسیار سرعت کارشون زیاد شده چون دیگه وقت سر ایمپورت کردن و .... اول کار تلف نمیشه.
پایتون به اندازه‌ کافی سریعه، اما optimization باعث میشه که سریع‌تر بشه به این چیزا میگن بهینه‌سازی

#M4hdi
〰️〰️〰️〰️〰️〰️〰️〰️〰️
©@raspberry_python

✔️ سوال‌ها:

➖ چرا CPython رو با assembly نمینویسن؟

➖ چرا CPython رو مثل PyPy نمیکنن؟ یا چرا از PyPy بجای CPython استفاده نمیکنیم؟

✅ پاسخ سوال اول:
سوال اول: کد سی سریع‌تره یا کد اسمبلی؟

همه به من بگید ببینم، کامپایلرهای زبان سی از سورس‌کد C، چی تولید میکنن؟ خب حالت خییییلی پایه‌ اینه‌که از سورس C، کد اسمبلی تولید میکنن بعد با یه اسمبلر کد ماشین‌شون رو تحویل میدن.

اما حالت، هیچ‌وقت حالت پایه نیست 😁
کاری که یه کامپایلر سی انجام میده اینه که یه خروجی خیلی efficient و کد اسمبلی خیلی سریع‌ از اون سورس‌کد بیرون میکشه

این اصل ماجراست.
اینه که جواب سوال میشه کد سی در اکثر مواقع از کد اسمبلی hand written که دقیقا همون کار رو انجام میده سریع‌تره. این همه مغز و وقت صرف نوشتن کامپایلر کردن تا این بشه
تا این شده

این از این

سوال دوم: نوشتن کد سی آسون‌تره یا کد اسمبلی؟

سوال سوم: برای نوشتن یه برنامه خیلی ساده، کی سریع‌تر مینویسه یه C کار یا یه Assembly کار؟

سوال چهارم که جوابش هم میدونیم، کد کی سریع‌تره؟

تماما C برنده‌‌ی ماجراست
پس فکر اینکه CPython رو با اسمبلی بنویسن سریع‌تر میشه رو بندازید بیرون.

به چند دلیل: سری دلایل اول -> همین دلایل بالا
سری دلایل دوم: بابا پایتون توی یه سری کارا کنده به هزار تا دلیل دیگه 😕 گیر ندید به سی یا اسمبلی

الان سورس PyPy که سرعت خیلی بیشتری از CPython توی خیلی جاها داره ببینید، پایتونه به ولله تقریبا بالای ۹۸ ۹۹ درصد پایتونه
پس مشکل جای دیگه‌ست.

✅ پاسخ سوال دوم:

پیاده‌سازی CPython یک پیاده‌سازی general هست.
این خیلی معنی‌ها داره
مثال: ببینید یه چیزی وجود داره به اسم numba
(برای مطالعه در مورد نامبا این مقاله‌ام‌ رو بخونید)
این یه JIT Compiler هست برای کارای عددی و محاسباتی دارای حلقه‌های زیاد

یکی از کارای jit ها همینه، چنین کدهایی رو سریع کنن اما آیا همه چنین کدهایی دارن؟ خیر
آیا تحمل اورهد و سنگینی JIT رو دارن؟ قطعا خیر
میدونید چقدر رم مصرف میکنن؟
برای یه راه‌حل مشابه بین پایتون و NodeJS، اون نسخه‌ی NodeJS حدود ۴.۵ برابر بیشتر از پایتون رم مصرف کرده، صرفا بخاطر داشتن JIT.
جیت‌ها start up رو هم کندتر میکنن

از اون طرف پایتون بعضی جاها از pypy سریع‌تره
مثلا یکی‌ش وب
آقای Anthony shaw یه چند تا بنچ‌مارک گرفتن با FastAPI و Uviloop و این دم و دستگاه‌ها
توی همه‌شون pypy بسیار از CPython کند‌تر بوده و رم مصرفی خیلی بیشتری داشته

یه مشکل دیگه هم هست
پای‌پای به طور صد درصد با C extension moduleها اوکی نیست
فرض کن نتونی numpy استفاده کنی 🙂

پس هر چیزی رو بهرکاری ساختن

#M4hdi
〰〰〰〰〰〰〰〰
©@raspberry_python

نظرسنجی!

Python Software Foundation و
Packaging Working Group و
Python Packaging Authority

یک نظرسنجی رو ترتیب دادن و از جامعه پایتون خواستن که نظرشون رو راجع به package کردن نرم‌افزارهای پایتونی ارائه کنن

اگه میخواید این مسئله بهتر و ساده‌تر بشه این نظرسنجی رو پر کنید (با فیلترشکن باید برید)

https://www.surveymonkey.co.uk/r/NMG6NJM

#M4hdi
〰〰〰〰〰〰〰〰
©@raspberry_python

هر دم از این باغ بری می‌رسد 😍🤟

یک #رشتو از آقای آنتونی شاو (twitter) @anthonypjshaw در مورد یکی از ایده‌‌های سرعت بخشیدن به پایتون 3.12

ایشون کمی در مورد تغییر نحوه‌ی ذخیره‌ی instructions از stack به cpu registers صحبت میکنن =)

https://telegra.ph/a-Twitter-thread-from-anthonypjshaw-11-03

#M4hdi
@raspberry_python

Codon: A high-performance Python compiler using LLVM

https://github.com/exaloop/codon

🔗 Python Hub (@PythonHub)

چی از اینا بهتر 😋😁

#M4hdi
#performance
#compiler
@raspberry_python

دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ performance
دنبال کردن هشتگ compiler

The @StackOverflow developer survey results came out. 📊

https://survey.stackoverflow.co/2022/

I found some reasons why someone would want to learn or work using @FastAPI in the next months/year. 😅🤓👇

🔗 Sebastián Ramírez (@tiangolo)

چرا FastAPI یاد بگیریم 😁

#M4hdi
#survey
@raspberry_python

دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ survey

وبالاخره، f string ها در پایتون پدر مادر دار شدن، و یک Syntactic formalization of f-strings براشون در PEP عه شماره 701 نوشته شد و *اگر* تایید بشه در پایتون 3.12 شاهد آن خواهیم بود.

"در کل" و "به صورت خیلی خلاصه" این PEP در این تصویر خلاصه میشه.

🔗 Pablo Galindo Salgado (@pyblogsal)
Finally, "PEP 701 - Syntactic formalization of f-strings" is ready 🚀🔥✨

We think this will make f-strings even more awesome but it will also help a lot with the maintenance of CPython 🤘

Thanks to my awesome co-authors @isidentical and @isidentical ♥️

https://peps.python.org/pep-0701/

#m4hdi
#PEP
#py312
#improvement


دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ pep
دنبال کردن هشتگ py312
دنبال کردن هشتگ improvement

@raspberry_python

✔️https://sourcery.ai/blog/dependency-rules/

یک معماری تمیز رو با قوانین مشخصی در مورد وابستگی‌ها حفظ کنید


#m4hdi
#dependency
#rule
〰〰〰〰〰
@raspberry_python

دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ dependency
دنبال کردن هشتگ rule

✔️ شاید با شنیدن کلمه‌ی ORM همه‌‌مون یاد SQLAlchamy یا Django ORM بیوفتیم، باشه اینا خیلی خوبن ولی لایبرری‌های جدیدی که نوشته میشن دارن از تمام language feature‌های نایس عه پایتون ۳ خصوصا 3.6 به بعد (Type Hints, F strings and async/await)
با قدرت استفاده میکنن و زیبایی خلق میکنن.

پیکولو، یکی از همین کتابخونه‌هاست.
نویسنده‌ی پیکولو چون از اوایل روزهای کاریش غرق در دنیای async بوده این ORM رو به صورت async first مینویسه :))
ولی میشه ازش به صورت sync هم استفاده کرد.

✔️ از دیگر ویژگی‌هاش
• A builtin playground, which makes learning a breeze.

• Tab completion support - works great with iPython and VSCode.

• Batteries included - a User model, authentication, migrations, an admin GUI, and more.

• Modern Python - fully type annotated.

• Make your codebase modular and scalable with Piccolo apps (similar to Django apps) 👌


میتونید ازش به عنوان یه کوئری بیلدر استفاده کنید:
# Select:
await Band.select(
Band.name
).where(
Band.popularity > 100
)

یا مثل یه ORM عادی باهاش رفتار کنید:
# To fetch an object from the database, and update it:

b = await Band.objects().get(Band.name == 'Pythonistas')
b.popularity = 10000
await b.save()


✔️ این ORM بهترین عملکرد رو با postgresql داره ولی از sqlite هم پشتیبانی میکنه و همچنین قسمت زیبای ماجرا اینه که از:
Starlette, FastAPI, BlackSheep, Xpresso and Starlite are currently supported.
هم برای ساختن web app های نایس پشتیبانی میکنه :))

🐙 https://github.com/piccolo-orm/piccolo

#m4hdi
#ORM
#library
#async
〰〰〰〰〰〰
©raspberry_python

دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ orm
دنبال کردن هشتگ library
دنبال کردن هشتگ async

آزاد از تحریم‌های آنلاین
با سرویس رفع تحریم 403

سرویس‌های زیادی برای ما توسعه‌دهنده‌ها تحریم هستن، مثل:
• Android Developers
• Visual Studio Installer
• Team Speak
• Google Developers
• Google Cloud
• Firebase
• CloudEra
• CoursEra
• Simple Note
• Chat GPT
• Spotify
• Google Lens
• Adobe
• Docker
• Nvidia experience
• GitLab
• Data Camp
• MongoDB
• Unity
• Trello
• Slack
• Apple Developers
• Unsplash
• AWS Amazon
• Gradle
• Android Studio
• Kaggle
• Math Works
• Jetbrains
و....
صرفا اونایی که توی کار ما بودن رو اسم آوردم
که خب یه راه برای دور زدن این تحاریم (جمع مکسرِ خودساخته‌یِ تحریم 😂) استفاده از فیلترشکن هست که این روزا می‌بینید به چه روزی افتادیم...

اما خب یه سرویس جدیدی به اسم 403 معرفی شده که میخواد چنین تحاریمی رو حل و فصل کنه 😃

403 چیست؟

۴۰۳ پلتفرمی برای برنامه‌نویسان و توسعه‌دهندگان عزیز کشورمان هست که امروزه با انواع تحریم و اختلال در توسعه پروژه‌های مورد نظرشان مواجهه هستند. این پروژه با پشتیبانی از پروتکل‌های مختلف به کاربران این امکان این را می‌دهد که حذف مشکلات موجود به کتابخانه‌ها و وبسایت‌هایی که برای توسعه نیاز دارد دسترسی داشته باشند. این سایت به مرور زمان توسط خود بازخورد کاربران تکمیل می‌شود تا تمام مشکلات این جامعه گرانقدر را رفع کند.

https://403.online/
https://403.online/how-to-use

استفاده کنید و لذت ببرید :)))

#m4hdi
#sanctions
#service



دنبال کردن هشتگ m4hdi
دنبال کردن هشتگ sanctions
دنبال کردن هشتگ service

کدوم زبون رو دیدید که سه دهه زندگی کنه و هر سال بیشتر رشد کنه و محبوبیتش بیشتر بشه 😁

ولی خب چرا:
https://github.blog/2023-03-02-why-python-keeps-growing-explained/

#m4hdi
@raspberry_python

دنبال کردن هشتگ m4hdi

✅ شرکت آناکوندا وبسایت
https://pyscript.com/
رو لانچ کرد 😁🎉

یک SaaS رایگان برای استفاده از pyscript تا بتونید اپلیکیشن‌های پایتونی رو توی مرورگر براحتی اجرا کنید 😁

#m4hdi

✔️ بررسی موشکافانه‌ی منطقه‌ی کد‌های C زبان پایتون، اینبار متد append از تایپ list

این مقاله چگونگی انجام عمل ساده‌ی append در لیست‌ها رو با بررسی کد‌های مفسر CPython بهتون نشون میده و همچنین بررسی میکنه که این عمل از چه الگوریتمی به چه الگوریتمی رفته و چه اتفاقاتی افتاده 😁

📄 https://virgool.io/@liewpl/how-append-works-gp4apwtpr0bt

#m4hdi
#cpython

✒️ @pyeafp
〰〰〰〰〰〰〰
©@raspberry_python