-1

i'm working on a game and this error is showing that Turtle object has no attribute dx.

# main game loop
while True:
    wn.update()

    #move the ball
    ball.setx(ball.xcor() +ball.dx)
    ball.sety(ball.ycor() +ball.dy)

Exception has occurred: AttributeError 'Turtle' object has no attribute 'dx' File "C:\Users\Desktop\pong game\Pong.py", line 97, in ball.setx(ball.xcor() +ball.dx) AttributeError: 'Turtle' object has no attribute 'dx'

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153
  • 1
    You have not provided enough code to enable a full answer, but there are some things you can check. I assume from the snippet shown, that your ball is an instance of a Turtle class. You are trying to add dx from ball (ball.dx in ball.setx(ball.xcor() +ball.dx)) So look at the turtle class, and does that class have a dx attribute ? Does it have a getter / setter for dx ? Again, making an assumption from your code, the xcor is probably the current location for the ball, and dx is the distance moved on the x direction. Does your Turtle have some other attribute which indicates speed ? – MarkA Mar 11 '23 at 19:02
  • Turtle object has no attribute 'dx' ... which word in this sentence do you not understand? 'attribute'? if you want ball to have ball.dx give it a value for example: `ball.dx=2; ball.dy=3`. – Claudio Mar 11 '23 at 19:04
  • Please share a bit more context. Adding properties to third-party libraries is not a good idea. You probably want to create your own class and [compose](https://stackoverflow.com/questions/9441331/how-to-create-a-subclass-in-python-that-is-inherited-from-turtle-module/71003069#71003069) the turtle inside of it. You may be using inheritance, in which case it's sort of OK to add properties (still risky! worse than composition!), but it's unclear as the question stands. `while True:` doesn't make for a good update loop--it slams the CPU resulting in inconsistent performance. Prefer `ontimer`. – ggorlen Mar 11 '23 at 20:17

1 Answers1

-1

If you want ball to have ball.dx and ball.dy you need to assign values to this attributes BEFORE you use them in your code.

For example:

# main game loop

ball.dx=2
ball.dy=3

while True:
    wn.update()

    #move the ball
    ball.setx(ball.xcor() +ball.dx)
    ball.sety(ball.ycor() +ball.dy)

Please also read all of what is said about usage of the above solution in the comments to this answer.

Following the suggestion by ggorlen here the requested add-on to the above:

I suggest putting a small caveat like "this isn't generally a good idea" on the post so it's not mistaken as a generally-recommended approach. It would be better to use ball_dx, ball_dy as detached properties:

# main game loop

ball_dx=2
ball_dy=3

while True:
    wn.update()

    #move the ball
    ball.setx(ball.xcor() +ball_dx)
    ball.sety(ball.ycor() +ball_dy)
Claudio
  • 7,474
  • 3
  • 18
  • 48
  • It's not a good idea to attach new properties or monkey-patch third-party libraries. If the API changes, there could be a conflict, it's easy to overwrite existing properties, and it creates unclear ownership boundaries. Better design is to wrap the turtle in a custom `Ball` class alongside the `dx` and `dy` properties, using [composition](https://stackoverflow.com/questions/9441331/how-to-create-a-subclass-in-python-that-is-inherited-from-turtle-module/71003069#71003069). If OP is using inheritance, that's a bit better, but still inappropriate for turtle in my view. – ggorlen Mar 11 '23 at 20:19
  • Turtle programming should be as simple as possible. This is the purpose of Turtle. With an OO approach you destroy the simplicity and over-complicate the code which is then harder to read and debug. Now we know that there is no .dx attribute there - so what? Why not use it along with the ball? – Claudio Mar 11 '23 at 21:49
  • Fair enough, but in my experience, turtle is very finnicky and so cutting corners winds up introducing a lot more complexity and bugs than learning and adhering to typical design principles. You don't have to go OO, you can do it functionally--the important thing is to keep the properties separate. If OP has a simple use case, I can understand your point of wanting to avoid overengineering, so how about simply `ball_dx`/`ball_dy` as detached properties as a compromise? More or less just as simple and with less risk, without the OO complexity. – ggorlen Mar 12 '23 at 02:52
  • At the very least, I suggest putting a small caveat like "this isn't generally a good idea" on the post so it's not mistaken as a generally-recommended approach. – ggorlen Mar 12 '23 at 02:54