question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

1000 lines of very verbose code can be easily cleaned up

See original GitHub issue

Most of the objects use getters and setters in a completely unnecessary way, adding literally 1000 lines of noise to the code.

(For an explanation of why they are unnecessary, see http://dirtsimple.org/2004/12/python-is-not-java.html )

Many other methods on the simple data objects have lots of duplication and could be simplified and shortened a lot by using some of Python’s dynamic features, like introspection etc. (Especially AsDict, __eq__ etc.)

Would you merge these kind of changes if I submitted a pull request? Or after the move to API v1.1?

Issue Analytics

  • State:open
  • Created 11 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
bearcommented, Feb 7, 2013

I worked on the same project as PJE that caused him to write that article (and I remember talking to him about it) so yes I’m aware of the pitfalls of this method.

The original author of python-twitter used a code generator to create all of this based on the protobuf description that he created for the twitter api - so that’s why you see lines and lines of code that seem to scream “WTF”.

All that aside, it has always been in the back of my mind to see if most of it could be simplified. I am leery of real heavy use of introspection and “fancy” methods - only from a code maintenance point of view.

So yes, if you want to dig in and start with some of the secondary classes so we can start haggling over some of the details, I would definitely welcome it. I would use it as the starting point for the v1.1 changes since that is a perfect time to break things.

thanks!

0reactions
sebastianwcommented, May 23, 2013

I tried something at sebastianw/python-twitter@c7892489b38867163c69ba16edae38e3394fd97a. Replaced the Status class with a much shorter version. It seems to work but I’m not sure if that is the way to go forward with the other classes. Coments welcome.

Read more comments on GitHub >

github_iconTop Results From Across the Web

ratio of bugs per line of code - Continuously Deployed
My team has been working on refactoring and cleaning up a large older code base. One of the biggest issues now is just...
Read more >
How important is it to reduce the number of lines in code?
I would say that the reason it's important to reduce the number of lines of code is to be able to view more...
Read more >
Coding Style: Terse vs Verbose, Conclusion - Anomaly.org
Verbose code generates more lines of code, so it can't be correct. The bugs per lines of code argument is an interesting one....
Read more >
How many lines of code is too long? - Quora
Something really terse like ML or Haskell would probably get unreadable over 25 lines in most cases, especially if it's a bunch of...
Read more >
Settings — Hypothesis 6.61.0 documentation - Read the Docs
You can set up a @given based test to use this using a settings decorator: ... For very complex code, we have observed...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found