Modifying Python Lists During Iteration

Day 54 of 365 Days of code 1) Capacity to Ship Packages Within D Days Approach: Binary search 1)set low = max(weights) 2) high= low*sum(weights) 3) perform the below steps until low<=high condition fails i) mid=low+(high-low)//2;res=0 ii) set w = mid and initialize day=1 iii) iterate through the loop and perform the stuff i put in screenshot (ahh life hurts :") ) iv) if the day <= days: set res=mid ; set high=mid-1 v) else low=mid+1 4) return res #365daysOfCode #NeetCode  #leetcode  #DSA  #python #LeetCode #ProblemSolving  #Algorithms #365dayschallenge

Today I had problem with #Python which in hindsight looks obvious, but I got too much tunnel vision. See: >>> s = (s1 if isinstance(s1, str) else s2 if isinstance(s2, str) else '') >>> s '' So we got fall-through here. But >>> print(type(s1), type(s2)) <class 'str'> <class 'str'> Well, there was no fall-through, it was a tunnel vision: s1 was empty string, so s got s1 value.

 Why Python remembers things after a function is done (code screenshot below) db_connector has finished execution. Its stack frame is gone. Yet connect still remembers host and port. That preserved state is a closure — created automatically when an inner function captures outer scope. You don’t “use closures” explicitly. You design around them. Why this matters: • avoids globals   • keeps config scoped   • cleaner APIs   • safer state Closures aren’t a trick. They’re how Python naturally models state + behavior. Once you notice this, patterns such as DB clients, API wrappers, and rate limiters become obvious. #Python   #SoftwareEngineering   #BackendDevelopment  

How many NaNs in a #Python #Pandas series? Use isna (returns True/False) then sum/value_counts: s = pd.Series([10, 20, np.nan, 40, 50, np.nan, 70, 80]) s.isna().sum() # returns 2 s.isna().value_counts() # count True/False Hint: Pass normalize=True for the percentage

In this blog post I do a direct comparison between a Lakehouse (Python) and a Warehouse (SQL) to which one is faster and cheaper in #MicrosoftFabric https://lnkd.in/gradjMdQ

#MicrosoftFabric Warehouse has improved its file ingestion capabilities significantly, so naturally users will start asking these kinds of questions 🙂 Fabric Warehouse is a solid engine, built entirely in native code. It is a proper client server database with ACID guarantees and user isolation. If you tried it two years ago, it is absolutely worth taking another look today. It has evolved a lot. Unlike a traditional warehouse, not only the storage is separated from compute, but uses an open table format by default, not as an optional feature, but as the only way. You can basically bypass the engine and read the data directly if you want. The more things change, the more they stay the same. #SQL #warehouse #lakehouse

The below is interesting. Of course, those who have worked with me know that I've been advising over the last 2 years to at least investigate both patterns before just committing to what's the current trend

Unsure how many values you want to unpack in #Python? Use * to get a list of flexible length: x = [10, 20, 30, 40, 50] a,b,c = x # error! a,b,*c = x # c is [30, 40, 50] a,*b,c = x # b is [20, 30, 40] *a,b,c = x # a is [10, 20, 30] Note: You can only have one * variable.

Does your #Python #Pandas column contain repeated strings? Turn it into a 'category' series (like an enum) to save memory: df['c'].memory_usage() # 124,957,472 df['c'] = (df['c'].astype('category')) df['c'].memory_usage() 12,496,555 That's right — 90% less memory!

A file you're loading into #Python #Pandas uses weird strings for missing values? Use the na_values parameter in read_* methods: pd.read_csv(f, na_values='.') pd.read_csv(f, na_values=['.', '*']) # multiple pd.read_csv(f, na_values={'a':'.', 'b':'*'}) # per column