Just a quick comment--looking over the source, do you think it'd be a good idea to update to Python 3, e.g. using type annotations and Python 3 syntax?

I really loved the idea and the collection so decided to contribute a bit ;)

https://travis-ci.org/yarikoptic/python-patterns/builds/130877280 should eventually reflect current state of things -- either tests pass as is or more things to be done

Please enable travis for your project @faif -- it is easy, just go to http://travis-ci.org, authenticate through github, click toggle for this repository

I have already complained in #143 about necessity to have clear copyright/license statement(s) so this code could e.g. be actually used/redistributed etc. Ideally the most permissive license (BSD-2 or -3 or MIT) would be the best fit.

Also would be nice to make all code PEP8 compliant. I have added call to flake8 in travis.yml but ignoring its failure atm. Didn't want to introduce big "stylistic" changes without "go ahead"

update on idea of testing outputs as docstrings (e.g. with python -m doctest): I couldn't find easy way to generate docstrings for def main()

By "testing outputs" I mean to compare script output with ### OUTPUT ### section at the bottom of the file. Structuring scripts like that:

def main():
    ...

if __name__ == "__main__":
   main()

allows imports of main in tests to evaluate and compare outputs.

It would also be more convenient to have ### OUTPUT ### section as variable or docstring, so we do not need to parse file for such comparisons

When flyweight.py is run as skript the following output is generated:

<Card: 9h> <Card: 9h>
True True
50022776 50022776
True
False
Traceback (most recent call last):
  File "D:\Users\Florian\Documents\GitHub\python-patterns\flyweight.py", line 92, in <module>
    instances_pool = getattr(Card2, 'pool')
AttributeError: type object 'Card2' has no attribute 'pool'

Good morning how are you? This is Arnold! Nice to meet you. I like your project, but your code looks gurly and lacks discipline! Here is a pull request to pump it up. You must apply it, do it now!

This follows the motto "a class with only one method that actually does anything should be a function", with the result that using the director function requires one line of code instead of 5.

Hi @faif, what do you think about to creating a GitHub organization for a central place of python pattern related stuff? I have a lot of python pattern example references to books here (paste "python" in the search field) which make more sense in a more "python oriented" context. But I think these book references would "waste" your repository. But they would be quite suitable in an organization beside your repository...

I thought that the point of Borg was to allow subclassing. However, the implementation doesn't match expectations in this case:

class Borg:
    __shared_state = {}

    def __init__(self):
        self.__dict__ = self.__shared_state
        self.state = 'Running'

    def __str__(self):
        return self.state

instance0 = Borg()
instance1 = Borg()

instance0.state = 'Idle'

print instance1  # prints 'Idle', instead of 'Running', as expected

borg = Borg()
borg.state = 'Idle'


class YourBorg(Borg):
    pass

borg = YourBorg()
print borg  # prints 'Running' instead of 'Idle', **not** as expected

Are you sure that Borg supports setting attributes in the constructor ?

It looks like it defeats the purpose of Borg...

It would be useful to have some more detailed descriptions for each pattern. I would put them in the comments above the code. The main questions would be:

• What the pattern is?
• What the current example does?
• Where can the pattern be used practically (or is used in known open-source projects)?

Some of the patterns have comments or are obvious, but not all of them. Also, I think, that people with different computer science knowledge will check them, so it would be valuable to describe the patterns to them.

Hello, I found this repository very useful. For improve readability it would be nice to structure this repository in modules/ folder (creational, structural).

What do you think about it?

I'd hate to think that I'm the only one of the thousands of people who have starred this project, but I would greatly benefit from a list of the purposes of each pattern in the README document. It would keep me/us/others from having to peruse each individual module to determine their use when there are so many other interesting things that that equally demand attention.

Thoughts?

Some files have type hints and others do not. I think writing type hints make it easier to understand the patterns. I suggest to write type hints and if its okay, I will work some.

And there are two typing style now in python, so I would ask which is good, >=3.9 style or <3.9 style. (mypy started to support for >=3.9 style just two days ago. https://mypy-lang.blogspot.com/2021/01/mypy-0800-released.html)

The way this repo is structured can be hard to read at times. Have you considered creating a jupyter notebook version of this repo?

Pros

• Better formatting of texts
• Code output can be easily shown
• The illustration images can be added on the same notebook

Overall it would be a nicer learning experience. I have created one example here.

I think listing anti-patterns with some basic reasoning about "why not" is a good idea.

Example - singleton. Although #256 has "won't fix" label

• it is in PRs section, and people (if searching history at all) are searching issues first.
• it was misspelled, Singelton instead of Singleton, therefore impossible to find

Listing most popular anti-patterns (without actual implementation) should allow people to find the name from readme

• immediately assume it was'n just missed by mistake
• see why it is not welcome for python projects

As far as I know almost always coverage is used to see "test coverage". For unused branches/variables etc there are linters, dead-code finders (such as vulture or dead).

So I don't think code coverage is important to extent of running run_all.sh script.

I would like to

• remove run_all.sh
• collect coverage
  • only for tests
  • only for one python branch (e.g. 3.7) (although it is possible to do coverage run -p and then coverage combine)

Would you accept PRs about functional programming patterns @faif ? Would probably imply some project restructuring (e.g. putting dirs "behavioral" and "structural" into "oop").