Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pypher behaves strangely in Pycharm Debug mode #47

Open
rock-it-with-asher opened this issue Jul 28, 2021 · 4 comments
Open

Pypher behaves strangely in Pycharm Debug mode #47

rock-it-with-asher opened this issue Jul 28, 2021 · 4 comments

Comments

@rock-it-with-asher
Copy link

ran with python 3.7.0 on both windows and mac versions, here is an output example:

str(tmp)
'MATCH (yo:`label`) shape shape.`len` shape shape.`len`'
str(tmp)
'MATCH (yo:`label`) shape shape.`len` shape shape.`len` shape shape.`len` shape shape.`len`'
str(tmp)
'MATCH (yo:`label`) shape shape.`len` shape shape.`len` shape shape.`len` shape shape.`len` shape shape.`len` shape shape.`len`'```


Each call to `__str__` adds more of the garbage strings. it doesn't happen in a regular run mode
@CisterMoke
Copy link

CisterMoke commented Oct 15, 2021

This issue seems the be a result of the following if statement in Pypher.__getattr__ shown here . Looks like that was added to support the mathematical operations. Adding the definition of __len__ to the Pypher fixes the issue of the len spam. I haven't come across any shape spam though. Maybe that is the result of Pycharm's scientific mode?

@CisterMoke
Copy link

Upon further inspection I was unable to come up with a proper definition of __len__ that wouldn't break the tests. I also don't understand why __getattr__ is defined in such a way that 'p.property' would add a property to the Pypher instance. It feels very hacky and appears to go against the lower level python routines. Perhaps a different syntax could be used to for this functionality?

@emehrkay
Copy link
Owner

The reason why it is p.__property__ or p.property('property') is because p.property takes care of defining a Statement when a Statement is at the bottom of the chain it does double duty -- either being a statement or a function -- it can turn into a function when __call__ is called on the pypher instance

ie

p = Pypher()
p.RETURN # statement

# vs.

p.RETURN(*args) # statement, then __call__

There were a bunch of concessions and trade-offs made to get this magic to work. Maybe the underscore syntax should be dropped all together since it is causing issues with tooling.

A possible fix would be to add a __len__ method to Pypher (it would be O(N) but I we dont care about that really lol). Im guessing it would look something like

def __len__(self):
    len = len(self.next) if self.next is not None else 0
    return 1 + len

@emehrkay
Copy link
Owner

^^^ keeping the double underscore for property syntax, we'd have to define the behavior of every dunder method on the Pypher class. it may make more sense to drop it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants