Skip to content
This repository has been archived by the owner on Jan 13, 2023. It is now read-only.

Pep8 #147

Closed
wants to merge 16 commits into from
Closed

Pep8 #147

wants to merge 16 commits into from

Conversation

HerrMuellerluedenscheid
Copy link
Contributor

Continuing #146


from typing import Dict, Iterable, Optional, Text
Copy link
Contributor Author

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.

Copy link

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.

https://docs.python.org/3/library/typing.html

Copy link
Contributor

@todofixthis todofixthis Jan 24, 2018

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.

Copy link

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.

Copy link
Contributor

@todofixthis todofixthis Jan 26, 2018

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.

Copy link
Contributor

@todofixthis todofixthis Feb 17, 2018

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?

@scottbelden
Copy link
Contributor

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.

@rpitonak
Copy link
Contributor

rpitonak commented Feb 1, 2018

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.
@HerrMuellerluedenscheid @miili

@miili
Copy link

miili commented Feb 2, 2018

@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.

@todofixthis
Copy link
Contributor

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.

@miili
Copy link

miili commented Feb 16, 2018

Yessir! We can merge what is done so far.
We will continue with leftovers on this PR, if you leave if open.

@todofixthis
Copy link
Contributor

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.

Copy link
Contributor

@todofixthis todofixthis left a 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
Copy link
Contributor

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
Copy link
Contributor

@todofixthis todofixthis Feb 17, 2018

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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)):
Copy link
Contributor

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
Copy link
Contributor

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]
Copy link
Contributor

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.

@HerrMuellerluedenscheid
Copy link
Contributor Author

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 😃

@miili
Copy link

miili commented Feb 20, 2018

Hi Phonix, thanks for the thorough review. However I would rather promote IDE agnostic code. Less is more!
Particularly libraries which realize standards and are hopefully mentioned for broader adoption.

Moreover Pycharm can extract type hints from docstrings:

https://www.jetbrains.com/help/pycharm/using-docstrings-to-specify-types.html

@todofixthis
Copy link
Contributor

todofixthis commented Feb 20, 2018

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.

@scottbelden
Copy link
Contributor

scottbelden commented Feb 20, 2018

I would like to add a vote for PEP484 type hints (not docstring hints). I would also recommend using something like mypy to have the type hint checks as part of the test suite rather than relying on IDEs because 1) not everyone uses an IDE 2) even if they use an IDE, it might not have hint support and 3) the IDE doesn't enforce it like a failure in the CI would.

Typically I like to have a "test" script that invokes flake8, mypy, the actual tests, etc and any failures in any of those would cause a CI failure. Basically something like this:

#!/bin/bash
set -e

echo "running flake8"
flake8 PROJECT

echo "running mypy"
mypy --ignore-missing-imports --strict PROJECT

echo "running pytest"
python -m coverage run --source PROJECT -m pytest -v $@

python -m coverage report -m

This has treated me well and catches problems faster than relying on users to have the right IDE set up.

@todofixthis
Copy link
Contributor

todofixthis commented Feb 21, 2018

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.

@todofixthis
Copy link
Contributor

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 .travis.yml and cleaning up any outstanding formatting issues, and then we can finally close #145 😺

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).

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

Successfully merging this pull request may close these issues.

5 participants