ugly code?

[krismc]

I like writing code. I'm not particularly good at it but refining a program progressively is satisfying. I liken it to rolling a turd in glitter.

At the start of my upython experience I got a bit wary of the return statement. My main.py code would crash with TypeError: 'NoneType' object isn't iterable when fns due to return a bunch of variables had a problem & returned None instead, 'if a_fn() is not None' stmts started to sprout like weeds.

Eventually I got into the habit of putting anything global in a dict & operating on them directly in the functions, return stmt not required. This has worked OK but gives me clumsy variable names like glbl['batt']. On the upside having multiple variables all in a single dict makes it easy to save them in rtc memory before a deepsleep.

Just wondering if I'm using a screwdriver as a can opener & what other options there might be?

[peterhinch]

The pros minimise the use of globals. It is usually best to construct classes and to use instance variables where data must be shared between methods. Where a function or method fails, consider raising an exception rather than returning None.

I suggest you find a book or online course on object oriented programming in Python. Perhaps someone will suggest a good one.

[shariltumin]

There is no ugly code, IMHO. It either works or it doesn't, and "working" has a wider meaning depending on the context: readable, maintainable, etc.

Yes, Python has an implicit return None, which can sometimes cause problems, unlike Pascal (function, procedure) or FORTRAN (FUNCTION, SUBROUTINE).

I tend to use explicit namespaces instead of global. Consider this toy example:

class K(): pass
NS = (K(),K()) # namespaces

def func(i):
    if i == 0: x = 0; y = 1
    else: x = 1; y = 0
    def f(n):
        try:
          NS[x].n += n
          print(f'NS({x}) {NS[x].n}, {NS[y].n}, {NS[x].n+NS[y].n}')
        except:
          NS[x].n = n
    return f

NS[0].proc = func(0)
NS[1].proc = func(1)

del func # now, only 'f' visible in namespaces as 'proc'

NS[0].proc(2)
NS[1].proc(2)
#
NS[0].proc(2)
NS[1].proc(2)

I like this pattern because: 1) loosely-couple, 2) message passing. But, there will be dragons.

Perhaps others will consider this as an anti-pattern.

[Josverl]

I would classify this as job protection code, write-once, read-never 😎

But that style also can serve it's purpose

[GitHubsSilverBullet]

There is no ugly code

r=(lambda _, __: list((___[1] for ___ in __(_))))([[567, 345, 234], [253, 465, 756, 2345], [333, 777, 111, 555]], lambda _: (sorted(_) for _ in _))

[Josverl]

I find that using a static type checker such as an IDE integrated or standalone pyright or mypy very effectively helps to spot these None type errors even before running the code.

For MicroPython just add the MicroPython-stubs

[krismc]

Haven't had any success installing the likes of VScode Jos but something that can spot potential trouble in advance sounds worthwhile. Something functional that gets past the load stage would be nice.

[Josverl]

No vscode, no problem
What OS and editor are you using?

[krismc]

I'm on windows 11 & alternate between Atom & Thonny

[Josverl]

While it is not possible to have nice integration in those Editors you can still run checks from the command line.

one time set-up of tool

uv tool install pyright
# or
pipx install pyright

In your project folder:

• add a pyproject.toml file for configuration
• install a copy of the relevant stubs

After the setup you can run:
pyright --project . to run the type checker