find_path() giving me complex output rather than list of tuples

[jamespblloyd-uwa]

Hello, I am trying to use pathfinding but the output I get for the path from the find_path() method is not what I would expect. I would expect a simple list of tuples but instead it is fulled with <GridNode(0:0 0x104760110)> and I am not sure what is wrong with my setup.

My system is: MacOS Sonoma 14.2.1 (M1 Pro chip) and I am running Python 3.12.1 and pathfinding 1.0.9.

The code that I am using as a test is below:

from pathfinding.core.diagonal_movement import DiagonalMovement
from pathfinding.core.grid import Grid
from pathfinding.finder.a_star import AStarFinder
import random

blockpositions = []

def makegrid(x2, y2):
	grid = []
	for x in range(x2):
		grid.append([])
		for y in range(y2):
			if random.randint(1,5)==1:
				blockpositions.append((x, y))
				grid[x].append(0)
			else:
				grid[x].append(1)
	return grid

grid = makegrid(50, 50)
startpos = (0, 0)
endpos = (49, 49)

finder = AStarFinder(diagonal_movement=DiagonalMovement.always)
grid2 = Grid(matrix = grid)

start = grid2.node(startpos[0], startpos[1])
end = grid2.node(endpos[0], endpos[1])

path, runs = finder.find_path(start, end, grid2)
for x in path:
	if x in blockpositions:
		print("block in path!")
print(path)

The output is:
[<GridNode(0:0 0x104760110)>, <GridNode(1:1 0x104b46c90)>, <GridNode(2:1 0x104b46cc0)>, <GridNode(3:2 0x104b47650)>, <GridNode(3:3 0x104b47fb0)>, <GridNode(4:4 0x104b74980)>, <GridNode(5:5 0x104b75310)>, <GridNode(6:6 0x104b75ca0)>, <GridNode(7:7 0x104b76630)>, <GridNode(8:8 0x104b76fc0)>, <GridNode(9:9 0x104b77950)>, <GridNode(10:10 0x104b84320)>, <GridNode(11:10 0x104b84350)>, <GridNode(12:11 0x104b84ce0)>, <GridNode(13:12 0x104b85670)>, <GridNode(14:13 0x104b86000)>, <GridNode(15:14 0x104b86990)>, <GridNode(16:15 0x104b87320)>, <GridNode(17:16 0x104b87cb0)>, <GridNode(18:17 0x104b98680)>, <GridNode(19:18 0x104b99010)>, <GridNode(20:19 0x104b999a0)>, <GridNode(21:20 0x104b9a330)>, <GridNode(22:21 0x104b9acc0)>, <GridNode(23:22 0x104b9b650)>, <GridNode(24:23 0x104b9bfe0)>, <GridNode(25:24 0x104ba89b0)>, <GridNode(26:25 0x104ba9340)>, <GridNode(26:26 0x104ba9ca0)>, <GridNode(27:27 0x104baa630)>, <GridNode(28:28 0x104baafc0)>, <GridNode(29:29 0x104bab950)>, <GridNode(30:30 0x104bb8320)>, <GridNode(30:31 0x104bb8c80)>, <GridNode(31:32 0x104bb9610)>, <GridNode(32:33 0x104bb9fa0)>, <GridNode(33:34 0x104bba930)>, <GridNode(34:34 0x104bba960)>, <GridNode(35:35 0x104bbb2f0)>, <GridNode(36:36 0x104bbbc80)>, <GridNode(37:37 0x104bc8650)>, <GridNode(38:37 0x104bc8680)>, <GridNode(39:38 0x104bc9010)>, <GridNode(40:39 0x104bc99a0)>, <GridNode(41:40 0x104bca330)>, <GridNode(42:41 0x104bcacc0)>, <GridNode(43:41 0x104bcacf0)>, <GridNode(44:42 0x104bcb680)>, <GridNode(45:43 0x104bd8050)>, <GridNode(46:44 0x104bd89e0)>, <GridNode(47:45 0x104bd9370)>, <GridNode(48:46 0x104bd9d00)>, <GridNode(49:47 0x104bda690)>, <GridNode(49:48 0x104bdaff0)>, <GridNode(49:49 0x104bdb950)>]

Please let me figure out what is going wrong.

[catvox]

you can use python fix it

[jamespblloyd-uwa]

you can use python fix it

You mean by parsing out the two numbers in <GridNode(49:48 0x104bdaff0)> so that they would be a tuple (49, 48)? Yes I could but I would rather fix this hot mess and know what is going wrong in my system that is causing it as it is not the intended behavior!

[brean]

actually this is how its supposed to work/how I implemented it, its not your setup, the finder just returns all node-objects.
You can easily create a list of tuples from it:

xy_path = [(p.x, p.y) for p in path]
print(xy_path)

having the instances allows you to also access calculated values during path planning and doing post-planning optimizations so I think for some use cases its useful to have the complex objects instead of just the (x,y)-tuples.

[brean]

I just noticed that the behavior was different in 2018, then you got a list of x,y tuples from the planner, but I only found this mentioned in the old ipython-notebook. So I am reopening as todo to update the notebook (and also look into other documentation as well)

[jamespblloyd-uwa]

actually this is how its supposed to work/how I implemented it, its not your setup, the finder just returns all node-objects. You can easily create a list of tuples from it:

xy_path = [(p.x, p.y) for p in path]
print(xy_path)

having the instances allows you to also access calculated values during path planning and doing post-planning optimizations so I think for some use cases its useful to have the complex objects instead of just the (x,y)-tuples.

Ah interesting. I assumed it was my setup as when I try to run this coding tutorial's code (https://github.com/clear-code-projects/Python-Pathfinder/tree/main/roomba%20project), I get this error message:
TypeError: 'GridNode' object is not subscriptable
And it only works if I change the output to a list of tuples. This project is only from 3 years ago so I am not sure why it has behaviour from 2018.

Many thanks for getting back to me.

[AnRibo]

Running my project today on a fresh install breaks my code due to this issue. Previously I got a list of tuples, now I get a list of GridNode objects. Is this new behaviour really intended and/or will be the case going forward? Was it us who had some sort of bug resulting in the list of tuples?

[brean]

Yes, this "new" behavior is intended, as the behavior is changed for some time, so I would not change it back it now, except you have some good reason to do so.
I will also do some optimization work for memory in python-pathfinding (starting this or next weekend), maybe always having a list makes sense in some cases, but I assume returning the node-objects makes sense most of the time as we don't want to always copy them back to a tuple first, however the user can then decide if they want to use the object or convert it back to tuples themselves.

[AnRibo]

I see. There is no difference for my use case, as long as I use e.g. GridNode.x instead of tuple[0]. Perhaps this "issue" could be mentioned in FAQ or something for others encountering this issue in the future. thanks for swift response!