Sympy Symbol(...) and Sympy symbols(...)

[Stephen Learmonth]

Why-oh-why are there these two functions for creating a single Sympy symbol or mutliple Sympy symbols.

This is so stupid and confusing!

Why not just have ONE function called symbols(...) and let the function definition figure out how many symbols you want to create!

This is soooo confusing!!!

[Aaron Meurer]

You're right that it can be confusing. The function symbols() does do
basically what you said, and it's the function we generally recommend
using.

The reason there is also Symbol() is because Symbol is the class for
symbol objects, and you can create symbol objects directly with the
class constructor. But you only ever need to use the class name Symbol
if you're doing something that requires the class, like isinstance().

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sympy/cd6d1ad8-4a21-4024-8f3f-86f480757e26n%40googlegroups.com.

[Sangyub Lee]

I wouldn't call it 'stupid.'

There is nothing sublime about 'symbols', it just involve string parsing and array handling compared to Symbol.

Some programmers would rather argue that such stuff are adding unnecessary overheads.

[Chris Smith]

"Unnecessary overheads" or "necessary batteries"? Figuring out what the "batteries" are is important for the user experience. I'm not making a claim either way for `symbols` but I think the principle is important.

If you look at what symbols can do (and its ability to do so for classes other than Symbol) you might see an argument for its utility.

/c

[Peter Stahlecker]

I play around with sympy.physics.mechanics quite a bit and I find sm.symbols really good: with one line of code I can create one symbol, or a list of 1000 symbols.

Now, with Aaron's post, I finally understood the difference between Symbol and symbols.

[Sangyub Lee]

The same could be said for list comprehensions or any functional programming idioms and design patterns that some people fall in love with.
However, a lot of senior programmers often advise 'Don't fall in love with your code.'
Sometimes such things can make it difficult to communicate with others, and it's mostly best to keep your preferences back at home.