Listing all symbols in sympy

[Stephen Learmonth]

How do I list ALL sympy symbols created in a Python script?

[Krishnav Bajoria]

Hi Stephen,

If you want to list all sympy symbols that you have created in a Python script, one straightforward way is to use Python’s built-in globals() to scan the current namespace and check for instances of sympy.Symbol.

Here's a simple example to illustrate:

>>> from sympy import Symbol
>>> from sympy.abc import a, b, c
>>> x = Symbol('x')
>>> y = Symbol('y')
>>> z = 3  # this is not a SymPy symbol
>>> symbols_used = [name for name, obj in globals().items() if isinstance(obj, Symbol)]
>>> print("Symbols used :", symbols_used)

This would output:

Symbols used : ['a', 'b', 'c', 'x', 'y']

But do let me know if you are looking for something more specific. Happy to help further!

Best regards,

Krishnav Bajoria.

On Mon, Jun 23, 2025 at 8:07 PM Stephen Learmonth <stephen.j...@gmail.com> wrote:

How do I list ALL sympy symbols created in a Python script?

--
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/2f682bea-f462-4188-9873-82c9ebafe889n%40googlegroups.com.

[Stephen Learmonth]

Thanks Krishnav,

It would have been really useful if Sympy just had a function like list_symbols() oir something from the start.

It''s such a basic thing to want to be able to do!

Stephen

[Krishnav Bajoria]

Hello Stephen, 

It seems reasonable to me to have such a function given that it is a basic need. Perhaps the best next step would be to open an issue to gather consensus. Once there's an agreement, we can proceed ahead with the PR.

Best Regards,

Krishnav Bajoria.

[Aaron Meurer]

What is your use-case for such a function? In most cases if you are
writing a script you know what symbols are defined because you have
defined them all statically somewhere, so there's no need to
programmatically get a list of them.

Aaron Meurer

On Mon, Jun 23, 2025 at 9:14 AM Stephen Learmonth
<stephen.j...@gmail.com> wrote:
>
> Thanks Krishnav,
>
> It would have been really useful if Sympy just had a function like list_symbols() oir something from the start.
>
> It''s such a basic thing to want to be able to do!
>
> Stephen
>
> On Monday, 23 June 2025 at 16:00:38 UTC+1 bajoria...@gmail.com wrote:
>>
>> Hi Stephen,
>>
>> If you want to list all sympy symbols that you have created in a Python script, one straightforward way is to use Python’s built-in globals() to scan the current namespace and check for instances of sympy.Symbol.
>>
>> Here's a simple example to illustrate:
>>
>> >>> from sympy import Symbol
>> >>> from sympy.abc import a, b, c
>> >>> x = Symbol('x')
>> >>> y = Symbol('y')
>> >>> z = 3 # this is not a SymPy symbol
>> >>> symbols_used = [name for name, obj in globals().items() if isinstance(obj, Symbol)]
>> >>> print("Symbols used :", symbols_used)
>>
>> This would output:
>>
>> Symbols used : ['a', 'b', 'c', 'x', 'y']
>>
>> But do let me know if you are looking for something more specific. Happy to help further!
>>
>> Best regards,
>>
>> Krishnav Bajoria.
>>
>>

>> On Mon, Jun 23, 2025 at 8:07 PM Stephen Learmonth <stephen.j...@gmail.com> wrote:
>>>
>>> How do I list ALL sympy symbols created in a Python script?
>>>
>>> --
>>> 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/2f682bea-f462-4188-9873-82c9ebafe889n%40googlegroups.com.
>
> --
> 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/c41df7a9-b27c-4e81-9fcd-85a52789b4e6n%40googlegroups.com.

[stephen.j...@gmail.com]

My “use case” is that suppose you are executing Python code in the Mac terminal application to test out some code and you lose track of what variables you have created and you want to delete some or all of them to start over.

A function which lists all the created variables would be useful so you can delete them all and start over. A very basic function.

Sent from my iPhone.

> On 25 Jun 2025, at 17:46, Aaron Meurer <asme...@gmail.com> wrote:
>
> What is your use-case for such a function? In most cases if you are

> To view this discussion visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B%2B_feNU%3D1psGQ1H7PapFHO67DtaqHKW8PiR59iZmrRDA%40mail.gmail.com.

[Sangyub Lee]

I don't think we should add such functionality to the library. I would not use locals() or globals() introspection in library because it lead to issues with garbage collection, introduce security vulnerabilities, and create thread safety concerns.

I think you would need to move beyond Python and use a different domain-specific language or user interface to implement such functionality in a secure way. I suggest consulting with experienced software engineers or IT agencies to implement that approach.

[stephen.j...@gmail.com]

What does “…locals() or globals() introspection…” mean?

Please prove to me that “… it lead to issues with garbage collection, introduce security vulnerabilities and create thread safety concerns”.

I won’t be moving beyond Python.

What do you mean by “…domain-specific…”!

Sent from my iPhone.

On 28 Jun 2025, at 07:26, Sangyub Lee <syle...@gmail.com> wrote:

I don't think we should add such functionality to the library. I would not use locals() or globals() introspection in library because it lead to issues with garbage collection, introduce security vulnerabilities, and create thread safety concerns.

To view this discussion visit https://groups.google.com/d/msgid/sympy/f0234176-abe1-4451-a6bd-9c58bb35bb06n%40googlegroups.com.

[Sangyub Lee]

I don't understand `locals()` or `globals()` very well, but it's always good that we don't implement something directly based on functionality that we don't feel safe using. Or will you put in the effort to address those concerns anyway

Regardless, it is primarily your responsibility to prove a strong reason why we need such functionality in SymPy. We don't have a responsibility to implement something general to solve the trivial terminal problems that you face.

[peter.st...@gmail.com]

I have been following this discussion as I use a library of sympy (sympy.physics.mechanics) quite a bit.

Would Krishnav’s one line code not do what Stephen wants, or am I missing something?

 

Thanks!

To view this discussion visit https://groups.google.com/d/msgid/sympy/9f2e3377-26ce-4894-8f14-2b15c4869812n%40googlegroups.com.

[stephen.j...@gmail.com]

I don’t think you understand my questions.

Please review my previous email.

Thank you.

Sent from my iPhone.

On 28 Jun 2025, at 10:14, peter.st...@gmail.com wrote:



To view this discussion visit https://groups.google.com/d/msgid/sympy/0c0901dbe80d%2414fff820%243effe860%24%40gmail.com.

[stephen.j...@gmail.com]

Yes, that single line of code works but it’s simpler and faster to be able to just type a short command like “list_symbols()” to list all the symbols created in terminal.

Sent from my iPhone.

On 28 Jun 2025, at 10:14, peter.st...@gmail.com wrote:



To view this discussion visit https://groups.google.com/d/msgid/sympy/0c0901dbe80d%2414fff820%243effe860%24%40gmail.com.

[Sangyub Lee]

Honestly, that's absurd to have a one-liner working function in a library. If a function can be written in one line, it gives twice as strong a reason that it should not belong to the library.

And furthermore, I don't agree with having list_symbols because I don't even want to encourage people to program in Python in such a fragile manner. Why should we help someone who forgets where they defined their variables?

[peter.st...@gmail.com]

So why don’t you define you own function:

 

def list_symbols():

       return Krishnaw’s list

 

Would that not work?

To view this discussion visit https://groups.google.com/d/msgid/sympy/126633FB-0907-496F-BE65-EADA8192C5FF%40gmail.com.

[Aasim]

I agree with Sangyub here, it is problematic when we work with globals() and locals() (have suffered before). 

And to Peter, yes, Krishnav's one liner code works, at least it lists all the Symbol objects created 

globally, not locally though(like inside a function or inside a class defined in the terminal application) .

We don't really need such typical methods for a very trivial use case in the library(any contributor can 

stumble upon a maintainer mentioning this exact same thing very often). 

Using globals() and locals(), again, is concerning. The concern that stands out the most for me here is 

thread safety.  For example, let us assume that for once we indeed start working on adding the list_symbols() 

method that Stephen mentioned, then I will use Krishnav's one liner, something like:

In [1]: from sympy import Symbol

In [2]: def generate_symbols():

  ...:     for i in range(10):

  ...:         globals()[f"s{i}"] = Symbol(f"s{i}")

  ...:

In [3]: def list_symbols():

  ...:     return [name for name, obj in globals().items() if isinstance(obj, Symbol)] # Krishnav's one liner

  ...:

In [4]: import threading

In [5]: thread1 = threading.Thread(target=generate_symbols)

  ...: thread2 = threading.Thread(target=list_symbols)

In [6]: thread1.start()

  ...: thread2.start()

thread1 might still be mutating the global namespace while thread2 tries accessing it,

which is unsafe (a very simple example of a race condition here). 

Similarly, when you use globals() or locals(), you're creating references to objects that 

might otherwise be eligible for garbage collection. Because the globals() dictionary often

keeps references alive for longer than we might intend it to. 

Another example could be, in pretty simple web applications the dev might add a secret 

API key to the application's code before hosting it and if in the python backend they are 

using SymPy which in turn uses something like list_symbols() proposed here, can introduce 

a vulnerability that publicly exposes the secret API key (hypothesizing here but very much possible).

I would suggest the same thing as Peter in conclusion: 
Stephen, you can just create a simple startup script for yourself that defines such trivial functionality(ies).

I use IPython myself and I have a startup script written for it, if I had a similar use case as yours I would just 

add something like this to my startup_ipython.py:

def list_symbols():

    return [name for name, obj in globals().items() if isinstance(obj, Symbol)] # Krishnav's one liner

and then use the shell by calling `ipython -i startup_ipython.py`.

To view this discussion visit https://groups.google.com/d/msgid/sympy/0c3801dbe813%2450a8bd20%24f1fa3760%24%40gmail.com.

[peter.st...@gmail.com]

Dear Aasim,

 

thanks!

Just learned something new.

 

Peter

To view this discussion visit https://groups.google.com/d/msgid/sympy/CAO0%2BxCUyzFy-x1i5P2_u%2BjA%3DBLHnH35LE98p3kDCQBwYKSkt4A%40mail.gmail.com.

[Sangyub Lee]

I think you sent me a message to my personal email rather than the mailing list, but I would like to give you some friendly advice.

I think you should reconsider your position when you see me or someone else disagreeing with your points. I have worked on SymPy longer, and if I wanted to push every complaint I have, it would be 100 times longer, but I don't do it for good reason. The expectation that I should agree with your personal complaints doesn't sound fair in this case.

I don't think that 'list_symbols' is useful for everyone. At least I haven't found such an inconvenience personally, and I haven't needed it. That's not because I have better memory or such, but because I already know how to navigate such situations.

The problem that things get confusing after global variables are overwritten does not only exist with respect to SymPy, but for all Python variables. And that is especially problematic if the definition is recursive, such as:

x = x + 1
or
api_key = requests.get(... + api_key)
because running the same script can break things

If we implement something that is too specific to SymPy, like SymPy symbols, I would also find that too restrictive to be useful anyway.

The reason that I (and some others) don't complain about such issues is that we understand these are user workflow issues, not library issues.

I generally suggest that:

• You should not keep the terminal open too long before you forget too many stateful changes. You should exit and restart the terminal often when you complete a task.
• You should be careful about copy-pasting any code to the terminal and check the inputs, because running the same script twice or running it in the wrong position can break things.
• You should take notes of the code in case you need to rerun the terminal. For example, Jupyter notebook is good for this purpose, or any Python file or function can work.

Anyway, the point is that if you are wise, you would realize it's definitely better to improve your own skills and terminal usage practices than attempting to fix the library.

[Aaron Meurer]

Something like

sorted([i for i in globals() if isinstance(globals()[i], Symbol)])

will give you what you are looking for.

In general, I'd say if you want to start over it's better to just
reset the session. Also you may prefer using a Jupyter notebook to a
terminal session, as it makes it easier to follow what code you have
already executed, and it also supports nicer math output with SymPy.

Aaron Meurer

> To view this discussion visit https://groups.google.com/d/msgid/sympy/09F2477A-68C5-4D47-B87C-E127DF867DF9%40gmail.com.

[Donaldson Tan]

 A python script is its own namespace, so u can evaluate the __dict__ attribute to identify every Sympy symbol.

[Stephen Learmonth]

How do I list all symbols created from the Python shell in Mac Terminal?

[Donaldson Tan]

check the output of the globals() functio in the python shell.

--
You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/Z8XPIGE8J0Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sympy/602ca057-1d3c-4a24-bf85-2ea45645a2f2n%40googlegroups.com.