-
Notifications
You must be signed in to change notification settings - Fork 125
Conversation
|
||
from typing import Dict, Iterable, Optional, Text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have to add these again as they provide extra functionality for some smart IDEs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we leverage typing
all the way through? But honestly I am not that keen on this. With a proper documentation one should know what he is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type hints are amazing 😺
IDEs use them for autocompletion and inspections — they're a great way to boost developer efficiency, and to catch typos and other issues that would otherwise go undetected.
I agree that documentation is also important, but they serve different purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @todofixthis,
which IDE are you using?
Hope this syntactic excess of ours is not too intrusive. Once this is finished and in dev
, we tackle the C pearl_diver
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I use PyCharm, but this is actually a standard practise (PEP-484), so I would be surprised if the major IDEs don't support this.
The syntax is a bit verbose, because we are supporting Python 2 and Python 3. If we were only supporting Python 3, we could integrate the type hints directly into the method signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put these back in, so that IDE type hints work correctly again?
I personally think 4 spaces is better, but making the change now is going to completely destroy the history. Also, because the change is being made with other changes it's extremely hard to see what all is being changed. If the 4 space change is going to be applied, it might be cleaner to do that specific change in it's own PR for readability sake. |
Hey, in #151 I changed iota/transaction/creation.py to conforms with PEP8. Can you take a look at it and check if everything is in order, so we can merge? Thank you. |
@todofixthis which PR are we pursuing, this one or #148? We haven't put any more work in, since it seemed obsolete. Yet I disagree with 120 characters per line as allowed by #148. |
Hey guys. Is the PR at a point where we could merge it, even if it's not "complete" yet? Maybe we can merge what we've got so far, and then take a progressive approach with the remaining files. |
Yessir! We can merge what is done so far. |
Okiedoke! I'll do a quick once-over to make sure everything looks OK, and if all's well, I'll go ahead and merge it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! I've requested some changes, and then let's get this merged, so that we can be on our way to PEP-8 compliance!
elif response.status_code == codes['internal_server_error']: | ||
error = decoded['exception'] | ||
except KeyError as e: | ||
# TODO: shouldn't pass silently |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentional, actually; if the response from the node is so badly malformed that we can't extract the error message, then we just assume that the entire response is an error message (see line 444 below).
Maybe we should add a comment to that effect here, so that other developers aren't confused.
|
||
from typing import Dict, Iterable, Optional, Text |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put these back in, so that IDE type hints work correctly again?
|
||
import sys | ||
from abc import ABCMeta, abstractmethod as abstract_method | ||
from argparse import ArgumentParser | ||
from getpass import getpass as secure_input | ||
from io import StringIO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put this back in, so that IDE type hints work correctly?
|
||
from argparse import ArgumentParser |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put this back in, so that type hints work correctly?
|
||
import filters as f | ||
from six import string_types, with_metaclass | ||
|
||
from iota.adapter import BaseAdapter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put this back in, so that type hints work correctly?
|
||
from codecs import decode, encode | ||
from itertools import chain | ||
from math import ceil | ||
from random import SystemRandom | ||
from typing import Any, AnyStr, Generator, Iterable, Iterator, List, \ | ||
MutableSequence, Optional, Text, Type, TypeVar, Union |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put this back in, so that type hints work correctly?
codec=AsciiTrytesCodec.name, # Text | ||
*args, # *Any | ||
**kwargs # **Any | ||
): # -> T |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type hints should start with # type:
, and the final one should take the form # type: (...) -> T
(see PEP-484 for more info).
|
||
if isinstance(trytes, TryteString): | ||
if type(trytes) is TryteString or issubclass( | ||
type(trytes), type(self)): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we restore incoming_type
? It might be unnecessary technically, but we don't need to refactor it for PEP-8 compliance.
This is already a huge PR that touches virtually every file in the codebase; I'd prefer it if we limited the scope of functional changes as much as possible.
balance=None, # Optional[int] | ||
key_index=None, # Optional[int] | ||
security_level=None | ||
): # -> None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type hints need fixing.
super(Address, self).__init__(trytes, pad=self.LEN) | ||
|
||
self.checksum = None | ||
# type: Optional[AddressChecksum] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type hints have to be on the same line as the symbol they are documenting.
Hey @todofixthis thanks for the thorough review! We will finish this until the end of the week. We are a little busy due to a hackathon this week. Taking chances to promote IOTA and this lib a little 😃 |
Hi Phonix, thanks for the thorough review. However I would rather promote IDE agnostic code. Less is more! Moreover Pycharm can extract type hints from docstrings: https://www.jetbrains.com/help/pycharm/using-docstrings-to-specify-types.html |
Thanks guys! Really appreciate this. WRT type hints, I'm a bit confused because I thought we were following a Python standard — PEP-484. Is the issue here that other IDEs don't understand those type hints? The docstring-style type hints are supported in PyCharm, but it's labelled as a legacy feature. If it turns out that most IDEs do not support PEP-484 but do support docstring type hints (and I really do want to verify that this is the case first), then I agree we should change the code to be more compatible (and no, don't worry; I won't insist on having BOTH docstring and PEP-484 type hints 😹) — but if we go down this route, I'd prefer it if we do that in a separate PR, just to limit the scope of changes. |
I would like to add a vote for PEP484 type hints (not docstring hints). I would also recommend using something like Typically I like to have a "test" script that invokes
This has treated me well and catches problems faster than relying on users to have the right IDE set up. |
I ❤️ the idea of adding style/standards checks to the build+test process. I added one a little while ago to check for problems in the setuptools project metadata, and I'd be totes keen to expand on that. That said, I think we should put those enhancements into a separate PR, to keep this one focused. |
Hey guys. Really appreciate your hard work on this! This branch has drifted quite a bit, so I'd like to close this PR and propose a new course of action. I've also started working on progressively migrating everything over to PEP-8; I should have that wrapped up by the end of the week. Once that is wrapped up, let's switch focus to adding flake8 (and maybe mypy?) checks to I hate to discard all the hard work you've put into reformatting the code for PEP-8, but I think that the sheer scope of that undertaking was making the process take a lot longer than anybody wanted it to. So, I'll tackle the boring stuff (reformatting the code), and if you're up for it, you can take on the interesting stuff (setting up automatic checks during the build process and addressing tricky warnings). |
Continuing #146