Traceback (most recent call last):
File "me.py", line 1, in <module>
AttributeError: 'Dave_Elec' object has no attribute 'social'

>Running modular program
>One module fails to run
module.start(module.ALL_FAILED)
>Traceback ends with:
>"Your Opus executable is x64, your Python version is x86"
*looks at Raspberry Pi*
"Uh... no?"
>recompiles Opus codec for good measure
>error persists
"Alright, what kinda bullshit..."
>skims file
try:
codecProcessor.load("Opus","libopus-0.dll")
except osError:
errorHandler("processorMismatch")

so, uh... i'm on Linux, so, uh... no. This'll also show this error on Windows if this is missing, too. A simple repoint fixed it, though.

We use celery at work, and one of the issues we face is that we use Django logging.
I'm not sure how it happened, however we only get 1 level of tracebacks from it now.

This has made debugging painstakingly difficult, since we have to manually traverse the code every time.

(we're in the process of moving to sentry, and we'll get our full logs back soon)

So, I just (few hours ago)made a new variable that's either brilliant or innately flawed... not sure yet. It's an oddly unique var...

__bs__

So far I only made it in python and windows env (i script like the methodology of css).

I bet you're wondering how I've defined __bs__ and the practicality of it.
__bs__ is derived from a calculated level of bullshit that annoys me to tolerate, maintain, etc. as well as things that tend to throw nonsensical errors, py crap like changing my strings to ints at seemingly random times/events/cosmic alignments/etc or other things that have a history of pulling some bs, for known or unknown reasons.

How/why did this come about now?

Well I was updating some symlinks and scripts(ps1 and bat) cuz my hdd is so close to death I'm wondering if hdd ghosts exist as it's somehow still working (even ostream could tell it should be dead, by the sound alone).

A nonsense bug with powershell allowing itself to start/run custom ps1scripts with the originating command coming from a specific batch script, which worked fine before and nothing directly connected to it has changed.

I got annoyed so took an ironic break from it to work on python crap. Python has an innately high level of bs so i did need to add some extra calculations when defining if a py script or function is actually __bs__ or just py.

The current flavour of py bs was the datetime* module... making all of my scripts using datetime have matching import statements to avoid more bs.

I've kept a log of general bs per project/use case. It's more like a warning list... like when ive spent hours debugging something by it's traceback, meticulous... to eventually find out it had absolutely nothing to do with the exception listed. Also logged aliases i created, things that break or go boom if used in certain ways, packages that ive edited, etc.

The issue with my previous logging is that it's a log... id need to read it before doing anything, no matter how quick/simple it should be, or im bound to get annoyed with... bs.

So far i have it set to alert if __bs__ is above a certain int when i open something to edit. I can also check __bs__ fot what's causing the bs. I plan to turn it into a warning and recording system for how much bs i deal with and have historical data of personal performance vs bs tolerance. There's a few other applications i think ill want to use it for, assume it's not bs itself.

*in case you prefer sanity and haven't dealt with py and datetime enough, here's the jist:
If you were to search any major forum like StackOverflow for datetime use in py, youd find things like datetime.datetime.now() and datetime.now() both used, to get the same returned value. You'll also find tons of posts for help and trying to report 'bugs', way more than average. This is because the datetime package has a name conflict... with itself. It may have been a bug several years ago, but it beeb explicitly defined as intentional since.