🔒 Just a small question about how short people's solutions are

[pale relic]

Hey so I'm solving on codewars, and it really annoyes me how I right 14 lines of code and I see others just type down 1 line of code
I mean , good for them, but is it correct to do such a thing? am I not a good programmer because I can't solve solutions with 1 line

I mean last one I wrote so much code that i got a timeout error ( but I'm not sure if someone have solved it using 1 line or not, cuz I didn't get access to the solutions)

[velvet moth]

@pale relic

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[modest mirage]

Amount of lines in code is not a great way to decide "correctness". For some problems, smaller solutions more explicit. But others its the opposite.

I wouldn't really worry about that stuff unless you really want to, most of those solutions are going to be using esoteric things or code golfing techniques

[pale relic]

ohh, thanks for clearing that, I thought it was a big deal 🙏🙏🙏

[white field]

More lines can actually be better.
While your 14 line version was (probably) very easy to read and understand, the one line version may be so complicated that it takes longer to understand than your solution.

[waxen oracle]

Excessively large solutions can suggest an unfamiliarity with tools of the language and well-known algorithms, but a large solution isn't itself a problem. The readability and performance of the solution are more important.

[pale relic]

yes, lists comprehensions and lambda functions that I forgot the second I studied it really takes alot of time for me to understand

[white field]

The readability and performance of the solution are more important.
@pale relic I second this.
Readability implies maintainability and extensibility.
Complex one liners will typically make everyone try to avoid that piece of code like a plague (developers are damn lazy), leading to slower/stagnant development.

[pale relic]

thanks so much, I really appreciate your help guys

[tender warren]

being able to make one line solutions is a testament to ones familiarity but its not something you should actually try to emulate for practicality

[white field]

But. Few characters. Much wow. Monke like:

def flatten(*xss) -> list:
    return [x for xs in xss for x in (flatten(*xs) if isinstance(xs, (list, tuple, set)) else (xs,))]

[tender warren]

but thats not even few characters its just few linebreaks >:(

[white field]

linebreaks?

[pale relic]

at this point I'm not sure if I'm reading python anymore

[tender warren]

newlines

codegolf doesnt use type hinting

or ternary statements

or isinstance

[white field]

What it does is pretty simple.
Take a list/set/tuple like e.g.:

my_list = [[0, False], [("",)]]
```and if you do:
```py
print(f"{flatten(my_list) = }")
```then it'll print:
```py
flatten(my_list) = [0, False, '']

[pale relic]

should I think about those, or maybe learn them?
ternary statements, or isinstance, never heard of them

[white field]

This is not code golfing good sir. This is simply being in awe of a genius oneliner

[tender warren]

type hints are (mainly) just for stylization, readability. ternary statements are just "sugar"/shorthand for something youve probably already done, and isinstance is just a single function that you can learn when the need arises

[white field]

isinstance is something you'll probably NEVER need, especially ever since match ... case is a thing.
Ternaries are cool, but you don't necessarily need them, however you should look at them sooner or later. They're really not that difficult to understand

type hints are (mainly) just for stylization, readability
Another important aspect imo is the auto-suggestions/auto-complete. If you do:

def f(var: str):
    ...
```then when you use `var` inside the function your IDE immediately knows (assuming you're using an IDE ofc) that the `str` functions are available on it, but if you don't put that, then it can't know what type it'll be

[pale relic]

yeah, just like pre setting what is the type of a var, used it before

[tender warren]

behold my genius one liner ```py
def f(*z):return[x for y in z for x in((y,),f(*y))[type(y) in(list,tuple,set)]]

[white field]

You should be aware that type-hints in Python are not enforced. I.e. if you do:

var: str = 3
```then Python will still run that, and the type of `var` is actually `int`, not `str`.
However, if you try to do that, then any good/sane IDE will give you a warning, preventing you from accidently mixing datatypes

[pale relic]

and I think that has bad effects on the memory of the running file??

[tender warren]

no

[pale relic]

oh

[tender warren]

typehints have no "functional" use

so it all looks the same once its compiled into bytecode

typehint or no

[white field]

You can easily save 3 4 5 6 more characters... smh

f=lambda*z:[x for y in z for x in((y,),f(*y))[type(y)in(list,tuple,set)]]

[tender warren]

was bouta comment on that extra space lol

beat me to it

[white field]

I found a few more optimizations to squeeze out characters. I'm not at 6 under yours :P

However, I don't think there's any more left to squeeze

[tender warren]

can turn the code into a string, encode it with utf 16 and then exec that with str.decode

[pale relic]

i too think so,
another squeeze and the universe will collapse

[white field]

We ufortunately also can't just check if the type is an iterable and flatten based on that, because stuff like strings are also iterable, and we don't want that flatten(["abc", 3]) produces ['a', 'b', 'c', 3]

[tender warren]

.

[white field]

Does that save text overall?

Probably not, considering you also need the import

[tender warren]

im pretty sure for like 52 chars and over it does

you dont need import anything

[pale relic]

would you mind explaining what is "flatten" never heard about it too
does it mean like it's non iterable

[white field]

oh yeah, str.decode, you're right

[tender warren]

if you have a list of lists

[white field]

#1402786062811664435 message

[tender warren]

and you want just a single list but with everything in it

[[1,2], [3,4]] -> [1, 2, 3, 4]

this is flattening

[pale relic]

ohhhh

this is actually handy

[tender warren]

yeah but dont do it like this lol

[pale relic]

lol, don't worry I'll search an easy way to do it (if I had to do it someday)

[white field]

Yeah, this one's just a fun thing for us to play around with, nothing actually serious

[velvet moth]

Python help channel closed for inactivity

This help channel has been closed. Feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.